fission-codes / auth-lobby

The authentication service that Fission services run.
https://auth.fission.codes
GNU Affero General Public License v3.0
12 stars 1 forks source link

Errors when trying to log in #81

Closed jeffgca closed 1 year ago

jeffgca commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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:

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

jeffgca commented 3 years ago

...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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Oh yeah, what the heck?

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

expede commented 3 years ago

yeah dashes are fine, I meant the underscore

Yeah, underscores also fine! (See screenshot above)

expede commented 3 years ago

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 commented 3 years ago

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

icidasset commented 3 years ago

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?