Fix usernames restriction #4100
Conversation
ghost
added
the
|
@whit537 : do we need something else to be added to this PR? |
|
Let's see ... |
chadwhitacre
force-pushed
the
fix-user-restriction
branch
from
6f054cc
to
cecb6ce
Compare
|
Rebased on master, previous head was 6f054cc. |
|
I want to go over this to make sure our logic precisely matches what Aspen does ... |
|
Sure! |
| # file existing on the web_root folder. | ||
| for ext in ['', '.spt', '.ico', '.txt', '.osdd']: | ||
| if (lowercased + ext) in gratipay.RESTRICTED_USERNAMES: | ||
| raise UsernameIsRestricted(suggested) |
There was a problem hiding this comment.
What if we took a different approach entirely, and actually ran /newusername through the Aspen request processor? That would match the condition more exactly, and would be more future proof.
There was a problem hiding this comment.
A redirect (to either /username/ or /~username) would indicate that the username is available. A 200 would indicate that it is not.
There was a problem hiding this comment.
That's basically an internal redirect, though, which we don't have good facilities for in Aspen. The test harness is the closest we have, and we don't want to import all that machinery into production. Hmm ...
There was a problem hiding this comment.
Actually, all we care about is dispatch. Maybe we can isolate that?
There was a problem hiding this comment.
Hrm, not easily. Dispatch is embedded in Gratipay's algorithm, and it seems that we'd want to test the real algorithm.
|
I'm trying out an approach based on an internal redirect ... |
|
Now I'm giving up on that approach and suggesting 5592272. Why do we need to check |
|
I completely agree with all of your remarks, my change was somehow clumsy. I need to try to improve my PRs in the future! (wow, great reactivity of Github concerning the link issue!) |
chadwhitacre
force-pushed
the
fix-user-restriction
branch
from
d2a25a3
to
63988a9
Compare
|
Rebased on master. Previous head was d2a25a3. |
|
@Nashe Cool, no worries. PRs are better than no PRs! :) I'm ready to merge when Travis is green ... |
|
"PR early, PR often!" 💃 |
This aims to fix H1-128121.
We're currently listing all the existing files inside
www_rootand comparing the username to each file/folder to ensure an user won't try to use it. However, there is a mapping between the files and the website route (lookup.json.sptis served aslookup.json), so the comparison is little bit more complicated.I'm just adding a list of forbidden extensions, and it will to to match the list of files with
username,username.txt, ... It won't really affect performances since it's only called when creating an account or changing the username. I would really know if somebody has a more elegant way to do it 🐱