Password generation uses special characters and can cause issues for users trying to connect

[binury]

After looking over https://github.com/supabase/supabase/issues/21690 I tested every node pg driver I know of:

• postgres-js
• node-postgres
• neon

and ALL of these - every single one has the same issue : any (username or) password which contains disallowed symbols (e.g. #) causes an exception to be thrown and none of them have a strategy implemented to accommodate this. (Not to whether say they should or should not)

They are also basically implemented the same way and call URL to parse the parts into credentials and a connection address

https://github.com/porsager/postgres/issues/735

node-postres even has an entire submodule repository for their connection string parser… it can't receive these either.

Notably, these exceptions are not straight-forward and are usually part of deep stack traces about certificate issues and 'authentication failure - wrong password' messages. probably not very encouraging.

SO. Considering that Supabase insists on having the password generator use 10 symbols and has chosen to include these well known unsafe symbols -in particular #- would it be beneficial for /dashboard/project/ to be updated to mention the encoding…?

Worst case scenario, I think it is really worth considering whether supabase might exempt the 3 characters and # from the pw symbol pool when generating random creds, as to avoid friction. Just an idea… Small, low-hanging changes with tangible benefits.

Apologies for not being too succinct- bedtime here :)

[binury]

RFC 1738 Uniform Resource Locators (URL) December 1994

Unsafe: … The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text; the quote mark (""") is used to delimit URLs in some systems. The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. The character "%" is unsafe because it is used for encodings of other characters. Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`".

All unsafe characters must always be encoded within a URL. For example, the character "#" must be encoded within URLs even in systems that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another system that does use them, it will not be necessary to change the URL encoding.

[encima]

The encoding is mentioned in the docs here. You are also welcome to use your own password (or a password generated by your password manager).

I would close this but, as a few people have had issues, let's leave it open to find a resolution. How would you like to see this improved or raising the visibility of the existing documentation?

[binury]

I didn't mean for the PR to have a documentation tag— I think the template automatically applied it; sorry.

use your own password

Well, as of Nov '22, the superuser role is not accessible for hosted sb which prevents this… does it not? One can -and some users do- generate passwords over and over through the 'studio' UI until they receive one without the disallowed characters so that they don't have to selectively[^2] encode and decode the URI string, in lieu of being able to set their own password.

I totally get that it's a silly problem- I do; it just seems like there is a very simple/easy change that can mitigate a lot of negative UX regardless of PEBKAC or not. I think would be a smart choice to forego one[^1] bit of entropy to exclude # from possible_password_characters and prevent this from happening. If it would help justify it, just add another character (20+1) to the length to compensate.

[^1]: Well, 1n so… 20 [^2]: This is the annoyance I see- depending on where it is used we might need to encode or might not which means it cannot simply be stored as encoded

[encima]

Not a silly problem at all and it's clear from the number of comments that this is an issue for many others.

You are able to use your own password when creating a new project though, clicking "generate password" is an option but it is possible to provide your own password without special characters.

As the documentation suggests, encoding the password does resolve the majority of issues encountered but you might be right that restricting the range of special characters could help a lot here.

[binury]

I just checked again and… I might be misremembering only being allowed to reset to pre-generated passwords 😕 (Is this ever the case? Do any non-owner admin roles allow changing it but only regeneration?)

I am able to set the password and the generated ones don't contain any symbols… at all.

https://github.com/supabase/supabase/blob/b74e84d05f6e1710d530e901d07a5fc85d44d35a/apps/studio/components/interfaces/Settings/Database/DatabaseSettings/ResetDbPassword.tsx#L84-L88

The default password gen looks fine! The symbols must be getting inserted by external password managers/extensions, or something…