I was investigating a frontend issue and I observed some strange behavior specifically in the esm-login-app. I understand OpenMRS recommends use of Chrome but for purposes of demonstrating the behavior I’m observing, you have to use Firefox or Safari and try to logout of OpenMRS when the oauth2login module is in use. It appears to me like there could be multiple un-coordinated navigations and redirects that happen during login and/or post logout and I think the redirect-logout resource, login component hook and openmrs-fetch compete with each other during the logout dance with the identity provider.
The undesired behavior that I’m seeing is that when a user logs out, there are about 2-3 navigation calls that are made from the above 3 files which forces the browser to abort the earlier one(s) and proceed with a single one. With the oauth2login module in use, 2 issues below could arise,
The user fails to logout because the redirect to the identity provider is aborted which is the bug manifested in Firefox and Safari, this can be reproduced consistently.
You notice page flickering, basically the user momentarily sees the standard logout page that comes with O3 before the browser actually takes them to the identity provider’s login page, this behavior is sporadic.
It would be nice if the frontend Gurus could take a closer look at this and chime in.
Does this mean that all i need is to simply install the oauth2login module into an O3 instance and then try to logout? Or are there any other steps that i need to take?
@dkayiwa you can reproduce associated issues in Firefox or Safari on this Ozone Dev you will notice you can’t get logged out. Some Chrome users do experience a different issue though, they end up seeing the skip logout confirmation in the IDP which should not be happening.
When you reproduce any of the above issues on Ozone Dev, please take a look in your browser developer tools and pay attention to the XHR requests (be sure to check the preserve logs option in developer tools), you will notice some calls are getting aborted/cancelled by the browser.
This looks to me like the oauth2 login stuff fighting the logout stuff. So we see:
DELETE request to logout
Two navigation requests fired off, one from the DELETE request (to the IDP) and one from here (to /oauth2login)
A request to get the /session endpoint is aborted (due to the navigation requests)
The request to go to the IDP is aborted (because of the second navigation request which appears to overrule the first)
The browser hits the /oauth2login endpoint, which redirects to the IDP
The IDP session hasn’t ended, so it logs the user back in
Presumably, some kind of modification of performLogout() is necessary, but I’m not entirely sure what. The second navigation request shouldn’t be firing.
I think another issue is that the frontend is a little tightly coupled with the backend, the backend is built assuming the frontend doesn’t know its internal implementation details however, the frontend is built while it is sort of aware of the oauth2 login mechanism, this sort of makes it brittle and sensitive to changes in the backend. E.g. currently, the oauth2login module no longer processes logout via the /oauth2logout endpoint but rather via the standard REST end session endpoint implying that the provider logout config option in the UI is now redundant and is misused given how the frontend code is currently written, it is very likely that the login url config option is also redundant.
In my opinion we possibly should not have made oauth2 a login provider type in the frontend. But yeah, this and this navigations should not be fired for oauth2 provider because they are one ones that cause the browser to abort the post logout redirects to the IDP. I will be issuing a PR to skip them for the oauth2 provider.
