User-based login detailed #1115
Conversation
|
Does this describe how it works on the currently deployed installation, how you wish that it would work or how it works with the sources in the current develop, i.e something close to version 1.20x ? |
marcus-oscarsson
force-pushed
the
user-based-details
branch
from
e260a69 to
65af48b
Compare
|
How Max IV staff wish that it would work. So we want to discuss here what's possible and what's not in the future mxcube |
|
I see, I would suggest that you create an issue instead and that it could be discussed as a specific topic on user based authentication/authorization using ISPyB at MAXIV. Because this documentation should describe how things works in the current code base. |
I was the one to suggest Dominika to start this as a pull request so that we can discuss and make changes to the Markdown document, that should act as some kind of a specification/requirements, even if we end up never merging this pull request (very likely scenario). With a GitHub issue we do not have Markdown document we can collaborate on. But whatever process gets the best discussion. :) |
Yes, the idea is that on one hand we have the "wish list" from MaxIV (this document in the pull request), and on the other hand we have the reality of what is already implemented in MXCuBE and/or can/will be implemented in the near future. And we should try to find a compromise in agreement with the other facilities. What can be done in common MXCuBE-Web code, what can be done in facility-specific hardware objects and what can only be done in a fork of MXCuBE-Web? |
|
I think it would be good to initiate this discussion with a meeting. The beginning of next week will be a bit tight and we also have the general dev meeting on Tuesday. Id propose to meet either Thursday or Friday next week or sometime the week after. The general developers meeting has already a quite loaded agenda but we can start to discuss this on |
|
Oh, I did not realize that we are on mxcubecore. Maybe this should have been on mxcubeweb, no? |
|
Its a functionality that is shared between the applications so I think its fine. |
|
Converting to draft, its easier to see what is pending to be merged like this. |
| ## Multiple users: | ||
|
|
||
| Any number of users can be logged in at the same time if: | ||
| * they belong to the same proposal, |
There was a problem hiding this comment.
ESRF: listed are actually experimental sessions, not proposals
proposal remains the same for several years, session is related to planned beam time (experiments)
users can belong to many sessions
MAXI IV: uses proposal in similar meaning
|
|
||
| The first logged in user automatically becomes an **active user**. The **active user** is **in control** and the other users are **observers**. | ||
|
|
||
| The **active user** should be able to force logout **observers**, except **staff**. |
There was a problem hiding this comment.
ESRF: active user can logout anybody - no distinction between staff and common users
For additional rules it is possible to overwrite relevant UserManager method, but it is not really recommended, since it's better to keep as common solutions as possible.
There was a problem hiding this comment.
May I suggest sticking with the term "user in control" rather than "active user"?
In a way, an "active user" would fit more closely with the concept of front-end sessions (or "active user session"): a user session is active as long as it has a valid token — it becomes inactive once this token is lost or expires. So this could be the term used in the last section in my opinion.
There was a problem hiding this comment.
ok, I will change that :)
|
|
||
| There is a timeout so an **observer** does not stay waiting for the control forever. After the timeout the user will get control (if there was no deny signal from **active user**). This feature is enabled by default, but can be disabled. | ||
|
|
||
| **Staff** can always “take control” or “ask for control”, even if the “get control after time out” feature is disabled. |
There was a problem hiding this comment.
anybody can take control whether is staff or not
|
|
||
| **Observers** can ”ask for control”, **active user** can give or deny control. | ||
|
|
||
| There is a timeout so an **observer** does not stay waiting for the control forever. After the timeout the user will get control (if there was no deny signal from **active user**). This feature is enabled by default, but can be disabled. |
There was a problem hiding this comment.
There is some parameter called: timeout_gives_control = 30 seconds that might be used after "take control", but it's not used anymore (it was in the previous version of mxcube, 5-6 years ago)
There was a problem hiding this comment.
yes, and we can if there are no objections and you are happy with give/take control remove the feature "time out gives control"
|
|
||
| The **active user** should be able to give control to any specific user (**observer** or **staff**). | ||
|
|
||
| If the **active user** logs out, any of the **observers** can ”ask for control”, and this user will immediately become the **active user**. |
There was a problem hiding this comment.
”ask for control” --> "take control"
if nobody took a control in the meantime,
- after log back in, the user is still in control or
- 1st newly logged in user automatically gets control
There was a problem hiding this comment.
or put slightly differently: "user in control" is not passed to another user on logout. The "user-in-control" becomes unassigned at logout and the next user that logs in becomes the "user in control"
| * Change proposal without logging out. | ||
| * Restart the server | ||
|
|
||
| ## Sessions: |
There was a problem hiding this comment.
Lims Sessions - Proposal time - meaning experimental time on the beamline,
this section is specific to MAX IV, remove it since it does not need to be specified in this document, in case of specific implementation document it with something like "Max IV extends this to ..."
|
|
||
| **Observers** can remain logged in even if the **active user** logs out. | ||
|
|
||
| The **active user** can change proposal without signing out. This automatically log out any **observers** that are not part of the new proposal, except **staff**. Users can only choose proposals they belong to. |
There was a problem hiding this comment.
The active user can change proposal / session without signing out. Active user can only choose proposals that all of the logged in users belong to (intersection).
List of sessions displayed is the same everywhere - for every user
Example:
- user 1 has access to sessions A B C
- user 2 has access to sessions A B
- user 3 has access to session A
All of them are logged in and see only session A. If user 3 logs out, user 1 and 2 see sessions A and B. If only user 1stays logged in all the sessions are visible.
Staff can move experimental session timewise - reschedule user
Staff can move experimental session beamline-wise
|
|
||
| It should be clear who is **in control** (hostname of the machine should be included to know if its remote or on the beamline) and who are the **observers**. | ||
|
|
||
| **Observers** can ”ask for control”, **active user** can give or deny control. |
There was a problem hiding this comment.
There is also a "take control" option
There was a problem hiding this comment.
"can give or deny control" => "can accept or deny the request"
... to distinguish this behaviour from the "give control" feature (i.e. observers can "take control", but the user in control can also decide to "give control" to any observer).
There was a problem hiding this comment.
ok, thanks
| ## User with **staff** privileges | ||
|
|
||
| They can always: | ||
| * Login - they do not need to be part of any proposal (it does not need to be checked to let them login). After login they see the `Select session` modal with the list of proposals they belong to. They could choose any proposal from it. If they type in a number or keyword they search through full list of proposals (even the ones they do not belong to) and they can select each one. |
There was a problem hiding this comment.
agreed, proposal / session
|
|
||
| ## Improper logout (without sign out button): | ||
|
|
||
| Closing or crashing browser of last logged in user activates an “idle timeout” (15 minutes for example as default value). If there is any **active user** or **observer** still logged in, the timeout will not be activated. |
There was a problem hiding this comment.
There is a timeout in meaning web session expiration time.
After closing window, losing internet connection the queue will not be removed or cleared. There might be also an automatic data collection f.e. during the night so only http part is cleared, after login back the queue points etc. need to be back also
TODO: re-discuss at MAX IV site,
Optionally: prompt the user to logout when closing the browser window to avoid improper logout
ESRF Policy: It has to be an explicit action from users "I'm finished with experiments". It is not allowed to switch users without local interventions. Local intervention means logout user and activate incoming session.
Below points are not meaningful
There was a problem hiding this comment.
Added an issue: #1139
|
Thanks for taking notes and providing comments, looks good as far as I can see |
At Max IV we had a meeting with beamline staff and discussed in details user-based login which is used on our site.
This MR is recap of the meeting and starting point for discussion of desired behavior of MXCuBE when user logs in.