-
Notifications
You must be signed in to change notification settings - Fork 1
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
Errors when trying to log in #81
Comments
@therealjeffg as always, thanks for reporting!
|
Answers:
I tried creating an additional user account and also verified my email and things eventually worked on that account. The other difference: usernames were:
I assume there's no significance to dashes vs underscores, just trying to be thorough. |
...if the root cause is that the email hasn't been verified we should try to catch that and tell the user to do so, right? |
Verified email is not currently used for anything. Sets a flag so we can prompt user. It could be underscores, I thought we fixed that. Underscores are “technically” allowed in subdomains but in practice cause issues. This currently 404s https://jeff_test4.files.fission.name/ — indicating subdomain not created. https://jeff-test3.files.fission.name/p throws an error / missing link, WNFS not created? I’ll do a run through of new accounts. |
Both |
Yeah, we should probably be much more defensive about user names then. The test3 account definitely claimed to be created but never actually worked. |
Dashes definitely work; I create them all the time, and did so again just now without issue. Given that the CID did actually get set, my best guess is that it's being initialized without a tree?
These look fine in my test (in Brave), so not related to the underscores per se: |
This is … something else. yeah dashes are fine, I meant the underscore. Pouring one out for good old boris_mann ;) The test3 error shows a v1 style hash @expede |
Oh yeah, what the heck?
|
Yeah, underscores also fine! (See screenshot above) |
Okay, this is what happened: the server uses For some reason, the FE missed the bit where it creates encryption keys and puts together the WNFS instance. We could set a common public WNFS instead, but that still doesn't solve setting up an private FS, which must be done client side. Ideally the lobby would be able to detect and fix anomalies like this. Even better: we could wait for the local WNFS to be set up before we register the user at all (which leads nicely into progressive onboarding). That would still have failed in this case, but there would be no user able to be set up in DNS the first place. |
...Logged #82 to capture the form validation issue. Seems like the only two characters we let past are '@' and '_'. |
Not entirely sure what I have to solve here, but it sounds like the problem is that when creating a new account and immediately after that linking another device and/or authenticating an app, causes problems, because the DNSLink with the user's DID isn't created yet (ie. DNS lag). So I have to make sure that DID DNS lookup never fails, and if it does show the appropriate message to the user. Does that sound about right? |
I set up a brand new user 'jeff-test3' with the email address 'jeff+test3@fission.codes'
Trying to log into Brian's gallery app I get some interesting errors from the two browsers involved:
If I refresh a few more times the error goes away and I get the typical
Open this website on your other device to authenticate this one.
message.Waiting to hear from your other device. If you have this page open on more than two devices, close this one.
The text was updated successfully, but these errors were encountered: