Closed ngeojiajun closed 2 years ago
Hey there! Thanks for creating an issue, couple questions:
The thing i can observe is the server rejected all newly created UCANs while accepting the ones which the currently logged in one have
Update: after testing with the currently logged in devices, I founded out that the authorization from the devices which are already logged in before is success. The issue only appear on the newly linked device.
Invalid UCAN got transfered during linking ? idk
We found the problem, we've got an issue in our CLI. It creates a UCAN where the expire time is greater than that of the UCAN it is a proof of, which shouldn't happen.
We'll release a fix soon and from then on we'll validate incoming UCANs as well.
Couple of options for you where to go from here:
is the recovery key works here?
is the recovery key works here?
Yeah. That's an option.
I recommend linking web -> CLI at least once, too. However, keep in mind linking CLI -> web might create invalid UCANs.
We'll let you know when we've got a fix.
@matheus23 i dont think the web->cli works in my case because server reject the ucans in both both situation. moreover the effected browser are the one that i used to create the account.
i dont think the web->cli works in my case because server reject the ucans in both both situation
Even after recovering your account using the recovery kit? I expect it to work after you've gone through the three steps I've posted above, but not before.
@matheus23 it succeeded. will this will make all existing UCANs invalidated?
Yes
So for now, whatever i do just dont link from the cli because of the bug then i am safe already?
Yep, we think so. Remember to log out of devices on which you were still logged in with the UCAN that is now invalid and re-link them with the device that now has the valid UCAN.
Noted with thanks
Recently I have run into a very weird problem in which prevented me from logging in to any app.
What happened:
Failed to update data root 😰
Additional Information Console log revealed the HTTP error 400 is thrown by the
https://runfission.com/v2/api/user/data/<cid>
endpoint for the step 3 and HTTP error 422 is thrown by the similar endpoint for the step 5