Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Account signup user name validation issues #119

Open
jeffgca opened this issue Jul 1, 2021 · 11 comments
Open

Account signup user name validation issues #119

jeffgca opened this issue Jul 1, 2021 · 11 comments

Comments

@jeffgca
Copy link

jeffgca commented Jul 1, 2021

We're not catching some invalid username on signup. This was caught investigating #81

Usernames like this:

  • jeff--

...get an error like

Sorry, jeff-- is not a valid username. You can use letters, numbers and hyphens in between.

After some testing, it looks like the code involved doesn't catch the '_' and '@' characters, leading to the creation of an invalid personal address for the account.

@expede
Copy link
Member

expede commented Jul 2, 2021

Yes, dashes or underscores at the beginning or end of names are not valid URLs, and thus fail server validation since it gets used as a subdomain. We should definitely make the message clearer about that.

@expede
Copy link
Member

expede commented Jul 2, 2021

it looks like the code involved doesn't catch the '_' and '@' characters

Do you have an example of one with @? I'm not able to reproduce that case:

Screen Shot 2021-07-01 at 22 34 59

Screen Shot 2021-07-01 at 22 35 58

Screen Shot 2021-07-01 at 22 36 04

I wonder if the lobby doesn't wait to check if it actually got created before trying to continue, because the server will reject those with a HTTP 422 (validation code here).

-- Convention: Right for "success", and Left for "error"

> mkUsername "je-ff"
Right (Username "je-ff") -- Valid!

> mkUsername "je_ff"
Right (Username "je_ff") -- Valid!

> mkUsername "hey@there"
Left Invalid -- Fails validation

> mkUsername "jeff--"
Left Invalid -- Fails validation

> mkUsername "_jeff"
Left Invalid -- Fails validation

@jeffgca
Copy link
Author

jeffgca commented Jul 2, 2021

Yeah I can't repro the @ issue on mobile. Underscores are definitely a problem.

I'll check macOS / Firefox again tomorrow

image

@icidasset
Copy link
Contributor

Moving this to the webnative repo, since the username validation happens there.

@icidasset icidasset transferred this issue from fission-codes/auth-lobby Jul 14, 2021
@matheus23
Copy link
Member

This is the logic in the fission server:

-- | Confirm that a raw is valid
isValid :: Text -> Bool
isValid txt =
  all (== True) preds
  where
    preds :: [Bool]
    preds = [ okChars
            , not blank
            , not startsWithHyphen
            , not endsWithHyphen
            , not startsWithUnderscore
            , not inBlocklist
            ]

    blank = Text.null txt

    inBlocklist = elem txt Security.blocklist
    okChars     = Text.all isURLChar txt

    startsWithHyphen = Text.isPrefixOf "-" txt
    endsWithHyphen   = Text.isSuffixOf "-" txt

    startsWithUnderscore = Text.isPrefixOf "_" txt

isURLChar :: Char -> Bool
isURLChar c =
     Char.isAsciiLower c
  || Char.isDigit      c
  || c == '-'
  || c == '_'

And this is the logic in webnative:

/**
 * Check if a username is valid.
 */
export function isUsernameValid(username: string): boolean {
  return !username.startsWith("-") &&
         !username.endsWith("-") &&
         !username.startsWith("_") &&
         /^[a-zA-Z0-9_-]+$/.test(username) &&
         !USERNAME_BLOCKLIST.includes(username.toLowerCase())
}

Yes, dashes or underscores at the beginning or end of names are not valid URLs

If underscores at the end of names are invalid, then we're not checking that both in the server and webnative.
Easy enough to fix though :)

I'll create another issue for the web-api repo

matheus23 referenced this issue in oddsdk/ts-odd Jul 20, 2021
@expede
Copy link
Member

expede commented Jul 27, 2021

If underscores at the end of names are invalid, then we're not checking that both in the server and webnative.
Easy enough to fix though :)

I misspoke for underscores. Underscores are actually valid at the beginning and end. We used to disallow beginning and end underscores to avoid confusion around things like _dnslink, which is also on the blocklist, but starting with _ often signifies a special/internal subdomain. We had someone complain that they use a name that ends in an underscore elsewhere on the internet, so we lifted the restriction for the end specifically. No change required on the server unless we want to lift the restriction on the front as well.

@expede
Copy link
Member

expede commented Aug 11, 2021

@therealjeffg just following up; are you able to find a case with the @? I think we've determined that the _ is working as expected, unless we want to change those rules.

@jeffgca
Copy link
Author

jeffgca commented Aug 17, 2021

Sorry for the delay in getting back to this. The thing that needs to be addressed a still is the messages that the user sees:

Sorry, _jg is not a valid username. You can use letters, numbers and hyphens in between.

If underscores are valid, we should change this message ti say something like:

You can use letters, numbers, and underscores, with hyphens in between.

Screen Shot 2021-08-16 at 6 11 04 PM

Screen Shot 2021-08-16 at 6 11 13 PM

@expede
Copy link
Member

expede commented Aug 17, 2021

Sorry for the delay in getting back to this

No worries!

If underscores are valid, we should change this message ti say something like:

Agreed — better message here for sure. Do you think it's worth using a "proper" parser here to give detailed error messages (e.g. "you can't have an underscore at the front and $ is not an allowed character") or is the single standard message sufficient?

@jeffgca
Copy link
Author

jeffgca commented Aug 17, 2021

Agreed — better message here for sure. Do you think it's worth using a "proper" parser here to give detailed error messages (e.g. "you can't have an underscore at the front and $ is not an allowed character") or is the single standard message sufficient?

I think a single message that completely describes what is always allowed and not allowed is the best experience especially as it reduces frustrations cycles if the user understands what the limits are up-front.

Aside: turns out designing systems that allow people to name things ( eg themselves ) is also hard.

@icidasset
Copy link
Contributor

No issue, need to improve message in lobby: #119

@icidasset icidasset transferred this issue from oddsdk/ts-odd Nov 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants