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

Errors when trying to log in #81

Closed
jeffgca opened this issue Jun 30, 2021 · 13 comments
Closed

Errors when trying to log in #81

jeffgca opened this issue Jun 30, 2021 · 13 comments

Comments

@jeffgca
Copy link

jeffgca commented Jun 30, 2021

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:

  1. Firefox initially claims "Couldn't find that user":
Error: Could not locate user DID in DNS.
    ig https://auth.fission.codes/web_modules/webnative.js:54
    u https://auth.fission.codes/web_modules/webnative.js:15
    u https://auth.fission.codes/web_modules/webnative.js:15
    s https://auth.fission.codes/web_modules/webnative.js:15
    promise callback*a https://auth.fission.codes/web_modules/webnative.js:15
    o https://auth.fission.codes/web_modules/webnative.js:15
    o https://auth.fission.codes/web_modules/webnative.js:15
    ig https://auth.fission.codes/web_modules/webnative.js:54
    lookupRootDid https://auth.fission.codes/index.js:1
    publishOnChannel https://auth.fission.codes/index.js:1
    ports https://auth.fission.codes/index.js:1
    c https://auth.fission.codes/elm.js:1
    s https://auth.fission.codes/elm.js:1
    b https://auth.fission.codes/elm.js:1
    Mn https://auth.fission.codes/elm.js:1
    Kn https://auth.fission.codes/elm.js:1
    Hn https://auth.fission.codes/elm.js:1
    ur https://auth.fission.codes/elm.js:1
    er https://auth.fission.codes/elm.js:1
    d https://auth.fission.codes/elm.js:1
    t https://auth.fission.codes/elm.js:1
    Or https://auth.fission.codes/elm.js:1
    Tr https://auth.fission.codes/elm.js:1
    Ur https://auth.fission.codes/elm.js:1
    Wr https://auth.fission.codes/elm.js:1
    Wr https://auth.fission.codes/elm.js:1
    Vr https://auth.fission.codes/elm.js:1
    Jr https://auth.fission.codes/elm.js:1
    Xr https://auth.fission.codes/elm.js:1
    e https://auth.fission.codes/elm.js:1
    rt https://auth.fission.codes/elm.js:1
    d https://auth.fission.codes/elm.js:1
    t https://auth.fission.codes/elm.js:1
    Or https://auth.fission.codes/elm.js:1
    Tr https://auth.fission.codes/elm.js:1
    Ur https://auth.fission.codes/elm.js:1
    Ur https://auth.fission.codes/elm.js:1
    Ur https://auth.fission.codes/elm.js:1
    Ur https://auth.fission.codes/elm.js:1
    Ur https://auth.fission.codes/elm.js:1
    Wr https://auth.fission.codes/elm.js:1
    Wr https://auth.fission.codes/elm.js:1
    Vr https://auth.fission.codes/elm.js:1
    Jr https://auth.fission.codes/elm.js:1
    Xr https://auth.fission.codes/elm.js:1
    rt https://auth.fission.codes/elm.js:1
    Xr https://auth.fission.codes/elm.js:1
    Yn https://auth.fission.codes/elm.js:1
    Xr https://auth.fission.codes/elm.js:1
    u https://auth.fission.codes/elm.js:1
    bootElm https://auth.fission.codes/index.js:1
    async* https://auth.fission.codes/index.js:1
    async* https://auth.fission.codes/index.js:1

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.

  1. Meanwhile, in Chrome on my tab open to Auth Lobby, the page initially switched to this message:

Waiting to hear from your other device. If you have this page open on more than two devices, close this one.

  1. Chrome next displays an error message in the page:
Got an error during the exchange:

Got an error during the exchange:
Problem with the given value:
{
        "msg": "did:key:z13V3Sog2YaUKhdGCmgx9UZuW1o1ShFJYc6DvGYe7NTt689NoL2UskWD8qVoqqa9E7bxXiXhxCBo6aiHZr9mYxkh6UN9RHxrWi5QsG6hUCmZtk8wuiFRYPFr2pSbaKxRVPeGMVMbfABEh4pMCbmUWReL8kWYz1rHmtf7QVoZHcgnSpipVpcJKvkMNXbQajqMu5q9sp6vKjc72rDux2Q1Ck7EpfwKR8gwXykpjk3cuoSrZmLwJc5zzueKpk3qqpTjb7emm5tkif58Y8pxUB9bXbsSXQGWXPVS1PSxf7N3SrHUsCopjQQZyC5rqskUp76HNvM7MM7zFCeJeFMoXMFa2cquhmHxULbgFbziGHgxuaB7MdTQnCCHrLWMkuKHLh7tXEZ2FFtAZKhSyFJNohqXshz",
        "timestamp": 1625088292264
    }
Expecting an OBJECT with a field named `did`
  1. In chrome's console, I got another error:
Error: Could not locate user DID in DNS.
    at Object.<anonymous> (webnative.js:54)
    at webnative.js:15
    at Object.next (webnative.js:15)
    at s (webnative.js:15)
Promise.catch (async)
(anonymous) @ index.js:1
(anonymous) @ elm.js:1
s @ elm.js:1
b @ elm.js:1
Mn @ elm.js:1
Kn @ elm.js:1
Hn @ elm.js:1
ur @ elm.js:1
er @ elm.js:1
d @ elm.js:1
send @ elm.js:1
(anonymous) @ index.js:1
async function (async)
(anonymous) @ index.js:1
@expede
Copy link
Member

expede commented Jun 30, 2021

@therealjeffg as always, thanks for reporting!

  1. It sounds like one of them goes away after a few seconds. Roughly how long did it take to resolve itself?
  2. Did the others eventually go away, or are they still showing these errors?

@jeffgca
Copy link
Author

jeffgca commented Jul 1, 2021

Answers:

  1. It takes under a minute
  2. The other errors are persistent

I tried creating an additional user account and also verified my email and things eventually worked on that account. The other difference: usernames were:

  • jeff-test3
  • jeff_test4

I assume there's no significance to dashes vs underscores, just trying to be thorough.

@jeffgca
Copy link
Author

jeffgca commented Jul 1, 2021

...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?

@bmann
Copy link
Member

bmann commented Jul 1, 2021

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.

@expede
Copy link
Member

expede commented Jul 1, 2021

This currently 404s https://jeff_test4.files.fission.name/ — indicating subdomain not created.

Both jeff-test3 and jeff_test4 have DIDs and DNSLink records associated with them. The subdomain exists, has a CID, and is pointed at the gateway. However, the CID contains no data; it's just blank.

@jeffgca
Copy link
Author

jeffgca commented Jul 1, 2021

Yeah, we should probably be much more defensive about user names then.

The test3 account definitely claimed to be created but never actually worked.

@expede
Copy link
Member

expede commented Jul 1, 2021

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?

It could be underscores, I thought we fixed that. Underscores are “technically” allowed in subdomains but in practice cause issues.

These look fine in my test (in Brave), so not related to the underscores per se:

Screen Shot 2021-06-30 at 21 51 25

@bmann
Copy link
Member

bmann commented Jul 1, 2021

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

@expede
Copy link
Member

expede commented Jul 1, 2021

Oh yeah, what the heck?

_dnslink.jeff-test3.files.fission.name text = "dnslink=/ipfs/Qmc5m94Gu7z62RC8waSKkZUrCCBJPyHbkpmGzEePxy2oXJ"

@expede
Copy link
Member

expede commented Jul 1, 2021

yeah dashes are fine, I meant the underscore

Yeah, underscores also fine! (See screenshot above)

@expede
Copy link
Member

expede commented Jul 1, 2021

Okay, this is what happened: the server uses Qmc5m94Gu7z62RC8waSKkZUrCCBJPyHbkpmGzEePxy2oXJ (which is "") when registering the account, before the user creates a WNFS.

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.

@jeffgca
Copy link
Author

jeffgca commented Jul 1, 2021

...Logged #82 to capture the form validation issue. Seems like the only two characters we let past are '@' and '_'.

@icidasset
Copy link
Contributor

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?

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