Activities of "alexander.nikonov"

When I am doing a logout in our project from ANY page - at some point I promptly see a HOME page, but there is no more navigation menu at the left (the menu obviously has been hidden, because the user is not authenticated anymore) and at the same very moment the API requests which are connected to that ANY page are invoked. Afterwards I am redirected to LOGIN BOX as expected.

I have absolutely no idea why the redirect to LOGIN BOX does not happen immediately after pressing the logout button and this HOME page is shown. I have looked through the code as much as I can. I can only attach again the Auth Server Module code and its log - what is happening at the moment of logout. I compared the log with the test project log, but by and large everything is about the same.

Perhaps one of your colleagues can tell me something - maybe there is a wrong setup in the module. But there are so many settings that it's hard to make sense of it. I can create another ticket, but it will contain the same question.

I cannot do screensharing or send our project. Just reminding it.

I really don't know how to match a test solution and our solution where the issue happens. I've tried to find who initiates these extra API calls between connect/revocat and openid-configuration looking at the initiator chain: Just in case: port 44337 is the port of Ocelot Gateway solution - I emphasize that the last endpoint is correct. Is the request initiator chain looking wrong here? Because so far I am out of clues, what is wrong and why. Maybe I am missing some settings relevant for authentication or they are incorrect? There are just too many of them, plus custom code, so I try to move from inside analyzing those requests.

IMPORTANT: this is not related to our custom pages only. The identical situation take place at ABP pages, e.g. Language Management. So it is not related to the components or guards.

I understand that active tab is not supposed to trigger this code, I just make a note that this:

is happening during logout on active tab too - in any component (which i want prevent somehow with a general approach for all components).

Hi,

you can redirect instead of reload

Whereas it might work for a passive tab - it won't work for an active tab, where I click "Logout": because this code is not triggered for an active tab. However the API requests (mentioned in the screenshot) are invoked on both tabs.

Hmm, it actually works - I checked the first tab, but the breakpoint is triggered for the "passive" tab. Thank you very much. Using this approach, I was able to get to the login page on both tabs. But it still does not solve the problem with sending API requests in my case - they still get sent at some point before the logout is complete:

I've tried it on our solution, then on the generated ABP test solution. Still does not work. The invocation was only several times while creating tokens, etc. Not when logging out. Please find the attached.

Never triggered, thus - no any kind of 'storage' event...

I've placed it in the ngOnInit() of my app.component.ts, but this.window.location.reload(); block has not been invoked during a logout...

What is a reliable way to prevent triggering API requests after I click logout on the site globally (without introducing many changes)? I am getting API requests from my page sent after clicking "Logout" link, but before being redirected to "Login" page. Of course such requests end up with error 401. But I do not want them to be triggered at all (i.e. I'd like to cancel the subscription of all of them in some centralized way). Is it tracking event type 'logout' inside HttpInterceptor? I've tried it and still see the same requests...

It helped and I opened two tabs in the same browser of the test app. When I do logout in one tab (and being taken to the Login page) - another tab remains intact, until I try to navigate somewhere from it: then it redirects me to the Login page too.

In our case, when I do logout on one tab - another tab is being affected too (so the navigation menu is being disappeared for the unauthorized user as expected, however the common layout remains). I was unable to determine what might trigger this. I can't send the code or do a screenshare. But probably you may give me some hints? Could it be an established SignalR connection, for instance? Or some guards?