It does not work, because in my case, this code is triggered only when I am being logged out, not when I am being logged-in.
In other words, visually the behavior of login process is the same as i have already described:
const tokenRemoved = event.newValue === null; line is invoked. The location.assign part is executed and I am logged out in both Tab 1 and Tab 2 and landed on the Login page of my OpenID server in both tabs;const tokenRemoved = event.newValue === null; is not invoked. I get error 400 as previously mentioned;Hi.
I wish I knew how to properly refresh an Antiforgery token in ABP solution.
By this moment, i have only noticed that this token is present as a hidden field in OpenID server login page.
But my guess is that it's too late to affect it there unless i am going to modify an OpenID login page directly with some js injection...
This time, I have run the code you suggested in ABP test solution. Suprisingly, I have found the discrepancy between the way your code behaves in ABP test solution and our solution:
Why your code behaves differently for both solutions - I have no idea. However, I am not allowed to share our project - I can only base on your suggestions if any.
I have tried this approach and it does not work: I am still getting error 400 in the second tab when trying to log in after the user has been logged in the first tab. So I'd better wait for the consistent and tested solution from your side.
I cannot find where should I reference LocalStorageListenerService from... Expected @abp/ng.core, but it is not there.
The point is that I do not know how to use this service to resolve the current issue with AntiForgery token. Sorry.
It might be allright to replace the service... But for the start, I would like to understand the issue better. I was trying to figure out the issue here...
If this is the question for me - i don't know what to say. I was trying to make some local fix, but for this, i need some assistance from your team side. However your team member from Angular division writes above that they are working on the fix now... So should I better wait?
Any updates?
Thank you. So I have tried to figure out what can I do to hastily solve this problem till a solid solution is implemented in ABP framework. However, I might need your input / explanation here.
From what I can see, 'XSRF-TOKEN' is stored in OpenID server's cookies. And it is 'reused' later in the hidden field of a Login form of Angular app. So when I silently reload the second tab on logging out in the first tab (this is done via this.window.addEventListener('storage', event => { if (event.key === 'access_token' && event.newValue === null) { this.window.location.reload(); } }) and this is exactly how i want it to behave) - this hash seems to remain the same. Though, when I log in from the active tab - it works fine, when I try to do the same from the second tab - it does not. I do not understand the logic under it: the same user, the same hash, but
Antiforgery token validation failed. The provided antiforgery token was meant for a different claims-based user than the current user. Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException: The provided antiforgery token was meant for a different claims-based user than the current user
? A new session - that's why? How to deal with that then? If a custom antiforgery token implementation omits the timestamp and session information, it obviously has a negative security side effect (and the antiforgery protection loses its point). So I expected that a user on the second tab would join the existing session (from the first tab) instead of creating a new one.
