Thank you for the input. I will keep this in mind.
Both in the current ABP test solution I use for the demo (version 8.1.3) and in your latest link the same layout is used and thus there is an intermediate step, using "Login" link in the main app. It might look a very subtle nuance, but it makes a big difference, i.e. if AFTER logout but BEFORE logging in, you will go to the login form in BOTH tab - you will get the same error as me (click "Login" button in both tabs to try to login from Login form of OpenID server):
As I mentioned, we do not have this very "Login" button in our application: after a user clicks logout, he needs to be redirected straight to the Login form of OpenID server.
The corresponding exception for ABP test solution is different in this case, but still relates to AntiForgery too:
Antiforgery token validation failed. The antiforgery cookie token and request token do not match. Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException: The antiforgery cookie token and request token do not match. at Microsoft.AspNetCore.Antiforgery.DefaultAntiforgery.ValidateTokens(HttpContext httpContext, AntiforgeryTokenSet antiforgeryTokenSet) at Microsoft.AspNetCore.Antiforgery.DefaultAntiforgery.ValidateRequestAsync(HttpContext httpContext) at Microsoft.AspNetCore.Mvc.ViewFeatures.Filters.ValidateAntiforgeryTokenAuthorizationFilter.OnAuthorizationAsync(AuthorizationFilterContext context)
@sumeyye.kurtulus today I easily reproduced the problem on the ABP test project. Essenially, unlike ABP test project, we do not have a login form or link as a part of the application. So after clicking logout link, a user is redirected straight to the common Login page offered by OpenID server. I think the issue with 'storage' event subscription is now explained easily, because Login page is no longer a part of the application, it is a part of OpenID server. But we need the solution for this very same scenario. https://drive.google.com/file/d/11j-ruM0et75fN27etFdo-igstWO8lHup/view?usp=sharing
Yes - that's what I am planning to do. But I do not control Antiforgery token in any way: all the job is done automatically by ABP framework, including the name, the way it is stored, etc. The only relevant code we are now using is:
Configure<AbpAntiForgeryOptions>(options =>
{
options.TokenCookie.Expiration = TimeSpan.FromDays(365);
// options.AutoValidateIgnoredHttpMethods.Add("POST");
options.AutoValidate = false;
})
So my question is how to make Antiforgery token be stored in a session storage of a browser in the first place?
Thank you for sharing more details. However, I did not see anything that would cause this cyclical re-login problem in these files. That is why, I suspected whether you have implemented another guard on the home route.
I cannot reproduce the cyclic reload scenario now. Probably I just forgot to remove a Model.Filters.Add(new IgnoreAntiforgeryTokenAttribute()); last time and "cyclic reloading" on login is what happens next when the AntiForgery thing is resolved.
Anyway, I would prefer to leave the AntiForgery protection as it is.
So now the question is: why is the event handler you suggested - this.window.addEventListener('storage', (event) => { ... }) is not fired for the passive tab. As we found out, Permission Guards does not affect this. Do you have any idea what else I could check?
FYI: there are no other addEventListener in our code.
Logout is standard: calling ABP method this.authService.logout()
Thank you very much.
UPDATE. Trying to figure out the problem per se. From what I can see, XSRF-TOKEN is stored in Cookies (and Cookies are identical for both tabs - Angular app in tab #1 and OpenID server login page in tab #2). When I log-in in the tab #1 - the new AntiForgery token is generated and written to Cookies. Tab #2 tries to reuse it (?) and fails, because this token is already "in use". So if I for instance switch to storing AntiForgery token in Session Storage (which is different for both tabs) - it might resolve my problem?
Hi @sumeyye.kurtulus.
I have removed our custom code in the app.component.ts trying to isolate the problem.
Below are the references to this version of app.component.ts and route.provider.ts.
The behavior is a bit different now: there is no Antiforgery token exception. But the passive second tab remains intact while a user is being logged-in in the first tab. And after I try to log in manually from there, there is a cyclical re-login process in BOTH tabs being started.
I would like to drill down to find the root cause. But so far I have no clue - as you can see this is not a permissions issue, I have removed our custom permission guards. Should I share some other files, e.g. HTTP interceptors?
https://drive.google.com/file/d/11YMuPWKR2Cpl5hILjp729QnwsEmJee_3/view?usp=sharing https://drive.google.com/file/d/11Z0YjrwSvSHsypdHfEF7j84-SzC3CiMM/view?usp=sharing
I've tried your approach. The behaviour has now changed. And when I try to log in from the second tab after I have already logged in from the first, I now see a cyclical process of re-logging in both tabs that never ends.
Also, I do not think it is a good idea to turn off Antiforgery.
So I'd prefer to wait until this multitab login problem is fixed in ABP, as your colleagues have already mentioned.
@maliming sorry - for some reason the log really did not contain the exceptions. I made a fresh test and prepared the logs of both OpenID server and AppServer. The latter one might be non-relevant, it just shows how requests try to access the back-end even after the logout (and getting non-authorized exception) - I did not manage to find the way to unsubscribe properly: https://drive.google.com/file/d/11InoAogKz83idmrKcEdvbp9Eciw6VE2u/view?usp=sharing https://drive.google.com/file/d/11JSdq3tG2jq8RizV0_MTdwiwVXz5Hc8_/view?usp=sharing
You can consider disabling the anti-forgery check for the logout endpoint Can you share the logs.txt file? I will check and share the code to disable it.
https://drive.google.com/file/d/11InoAogKz83idmrKcEdvbp9Eciw6VE2u/view?usp=sharing
I do not know what exactly could cause such a discrepant behavior in our solution (i.e. why "tab-2 is not notified about the token update" if it expected to do so). We do not have any specific code handling AntiForgery token - neither on front-end, nor on back-end side.
For this reason, I have no idea which part of code I should share (I am not allowed to share the solution). I am sharing a couple of files which might be relevant:
Also, I want to inform you the OpenID server log does not contain any errors or exceptions. https://drive.google.com/file/d/11GlNoSNzpZ-DPH8Wa_i2PSN-EASfRIp4/view?usp=sharing https://drive.google.com/file/d/11I0kgnxmXnlfYm7Ojh8nf3zIKBQKFTMU/view?usp=sharing
Maybe there is the way to track down the mentioned issue in some way?
