Thanks for the feedback, indeed I can reproduce the issue with dfx 0.14.2 and .wasm.gz as well.
However cannot confirm if it works with 2023-04-12 release or not because I get another error which should probably be ignored in this debugging.
We’ve released (not yet promoted) dfx 0.14.3-beta.0 to address this issue.
It incorporates release candidate replica at commit 0ab9178c6684f122ae713928b3664c33a697e9c4. One relevant change is the removal of openssl as a dependency from signature verification.
DFX_VERSION=0.14.3-beta.0 sh -ci "$(curl -fsSL https://internetcomputer.org/install.sh)"
2 Likes
1 Like
Do I understand correctly that this problem is also fixed in dfx 0.15.0?
I’ve used different versions of the internet_identity_dev.wasm, but when I re-authenticate, my requests are returned with an error.
Frontend and II are on different ports. Any ideas?
@rabbithole: Which version of II are you using specifically?
If it is older than release-2023-08-28, it might be affected by this bug.
@rabbithole: Is your code opensource? What are the reproduction steps? Which browser are you using?
I’d like to reproduce the issue on my machine in order to debug it.
My code is open source, I’m working on this branch. I’m not sure if you should waste your time on this, but if you decide to do it, then:
- you need to deploy the project using the script
./scripts/deploy.sh - run
yarn startand open localhost:4200 - register by creating a user canister and profile. After creating an invoice copy account id and
dfx ledger transfer --amount 0.05 <ACCOUNT_ID> --memo 0 --fee 0
- Sign in
- Sign out (click on the avatar in the upper right corner and select the Sign out menu item)
- Open dev tools and sign in again without reloading the page
I’m sure I made a mistake somewhere, so again, you don’t have to waste your time on this. After all, I did not create the minimum code to reproduce the error outside of my project.
P.S. the error occurs when calling actor methods. Although Actor contains the correct identity.
Are you using the same authClient object after signing out or are you destroying it or re-creating a new AuthClient on next login?
If you don’t, that might be the issue.
In my dapps, like in Juno, I generally let this comment for my future self:
// This fix a "sign in -> sign out -> sign in again" flow without window reload.
authClient = null;
This is required I think because the authClient keeps stuff in memory or so.
Side notes: two days ago we discovered a bug in Agent-js when signing out in Safari. At least in the dapps I’ve tested, Safari seems to block the next sign-in (sign-in → sign-out → sign-in → Safari blocks popup). The team will have a look at the issue but meanwhile it’s also safe to reload the window after sign-out.
1 Like
I create the authClient once in the main thread before loading the application here, but in the worker I just read the IndexDB store. Thanks for the tip!
1 Like
Gotcha, yeah then it is not the same issue. Have you try, just for debugging purpose, to add a window.location.reload() after the sign-out? do you still face the same issue or it solves it?
Reloading the page solves any problems, but I was interested in solving the problem without reloading 
The fact is that I also could not make a full-fledged PWA due to a conflict between service workers (angular and IC), so I have to rely on caching in the browser.
I’ll try resetting authClient and if that doesn’t help, I’ll add a page reload on sign out.
That’s good to know. It means that something is in cache and that clearing it resolves the issue.
So yeah try to reset authClient, it it is not enough, double check if there is not another store that should be cleaned and maybe even “manually” reset some indexeddb collections.
But yeah if reloading resolve the issue it means something remains in cache after sign-out.
Makes sense?
1 Like
I recreated authClient when signed out and that solved the problem. It seems to me that this point needs to be described somewhere in the @dfinity/auth-client documentation, because I read that authClient is created for the entire application once (unfortunately I can’t find the link).
Great to hear it solved it!!!
Not sure if and where it is documented. If I reckon correctly somewhere on the forum in another thread I raised the same question / observation but, was answered it was a design choice. @kpeacock can probably provides more context.
1 Like
It’s not a rule per se - more of a design goal that it is intended to work that way. If the logout method isn’t working, I’d say there’s a bug here worth investigating
For what it’s worth, I have repeatable login and logout flows for several frontend frameworks working in my GitHub - krpeacock/auth-client-demo: Example demo of how to use https://www.npmjs.com/package/@dfinity/auth-client to make authenticated calls to an IC app project. I don’t know specifically what’s causing your problem, but perhaps you can compare how your approach differs
I debugged the issue further as I can also reproduce the problem on my side. I found one race condition due to the my web worker accessing the identity imperatively. I made the mistake to assume that the agent identity was either null or not null where in reality the agent identity is either anonymous or authenticated.
That said, once I added extra guards for this, I still managed to reproduce the issue by sign-in with Anchor 10001, signout without setting the auth client to null and sign in with 10000. It might be another race condition though as I cannot reproduce the issue with a sample repo.