This likely happens mostly in demo scenarios but I’d still like to see this fixed:
login as demo/demo
open any application, for example “admin”
open another browser window/tab
open the login for a different application, for example camunda/app/tasklist/default/#/login as user who doesn’t have the right to run the given application, for example “john”
change to the other window/tab, you see nothing changed there (which can be considered “ok”)
click anywhere
Expected result: a window showing “Login Failed :
Wrong credentials or missing access rights to application”
You can browse the admin application and the upper right corner with the user doesn’t change (it stays on Demo Demo).
You can now see other users (only these in your group) and when you click on a link, for example to create a group you see the appropriate window (the creation ends with “Failed to create … Check if it already exists.”).
Summary:
user is not reloaded when browsing within the application (relevant if the user name changed, for example via “edit profile” or administrative changes during a session and for re-login)
application rights are not rechecked when browsing within the application (relevant for removed application rights during a session and for re-login)
Is there an issue created for this already? If not: Where can I do so?
thank you for the reply. I’m aware of the “to simulate use different browser sessions” part.
This can be seen as “by design”.
The problem here is: even after a re-login (= a new cookie) the application rights are not rechecked against this cookie.
Additional the actual pages (like the user profile) should get its data from the server, not from the cookie - at least the cookie should be updated when the user name was changed in the same session.
Is there a way (and relevance) to create an issue for this?
after the user is logged in, subsequent requests are done asynchronously using the Cookie the user got from the login until the user logs out or refreshes the page. Could you describe your scenario where you need to have two different user accounts sharing the same browser without logging out?
the issue was not a scenario where I need two different sessions in one browser (as pointed out before you can use two browsers and/or private mode to do this).
The original problem was: even when I do a new login (=logout missing) the browsing in all tabs from the “old” session is still possible and I the user can see more than he could when original logging in. It looks like either the cookie is not replaced or the opened tabs don’t re-read the cookie.
This seems to be the same issue when the user profile was changed within the current session - the data shown for the user in the page header doesn’t update until re-login.
Just to make sure I understand your scenario correctly: You first log in with a user that has limited access rights. Then, using a second tab, without logging out, you log in again with a different user that has more access rights. Then, using the first tab, you can perform actions that the first user was not authorized to do, but the second user is.
If that is the case, then this is expected behavior. In this scenario the user displayed in the header might not be the user that actually performs the operations. If you reload the page of the first tab, you can see that the user name is also updated. Could you verify that?
Thanks for the detailed description! I was able to reproduce everything. Let’s go over the different scenarios:
This is a bug. Do you want to open a bug report in the JIRA?
The other scenarios you describe are not supported, but I can give you some technical insight.
This is expected behavior. The name of the user is fetched when the user is logged in or the page is loaded. Even when the user interacts with the page, we only load the information that is relevant for the interaction. E.g. if the user loads the list of process definitions, the request returns only the process definitions, and not the user information again.
This is expected behavior. The application authorizations are only checked for the login. In this scenario, the user is already logged in to Cockpit and only switches to another application that he was originally authorized to access. Note that the access is only restricted to the application itself. Information that is loaded is still displayed according to the new user. So if the new user does not have the authorization to see process definitions, the list of process definitions will be empty, even if he can access Cockpit.
Please do it yourself, I’m coming back to JIRA later…
This is ok, at most I’d consider this a minor “glitch”, not a real issue.
Hm, is checking the application authorizations a load-consuming issue?
As “in theory” a user’s authorizations can be changed at any time it would be good to verify it, at least on application switch. To reduce the needed load it may be possible to store “the authorization database was last read on timestamp x” when resolving the user’s authorization during login and on each incoming user action poll the database for the last change timestamp (and resolve it again only when the timestamp is changed - or maybe attach a change listener, or…).
Do you think the “check the authorization after user logged in” could be added as feature request?
