following situation in short: I'm using Shiro together with Vaadin. As Vaadin supports multiple tabs (each tab is a separate UI instance, independent from each other) in one browser session, I must to reproduce the same behaviour in Shiro too. That means, I must manage a separate subject for each browser tab (different users logged into each tab).
From Vaadin's UI instance (and of course from the http request paramters) , I get a unique embedId to distinguish each tab. So, theoretical it should not be a problem to hold multiple independent subjects in one session.
What I've done so far is extending SecurityManager, SubjectContext, SubjectDAO, Subject/-Factory. The idea at the end is, to not only handle two keys DefaultSubjectContext.PRINCIPALS_SESSION_KEY and DefaultSubjectContext.AUTHENTICATED_SESSION_KEY for storing the subject's state in the session. Instead of this, I will create for each browser tab a new pair of these keys and adding the Vaadin's embedId to the key name. So I have a separate principal key and authenticated key for each tab stored in the session.
All this seems to work quite well when I debug, but the only thing I struggle a bit is the static SecurityUtils.getSubject(). This method always returns the Subject of the ThreadContext if it is already stored there. But exactly here, it should return a tab dependent Subject. Unfortunately, I can't extend the SecurityUtils, because it is static. Of course, I can write my own util class for the tab related Subject. But the SecurityUtils.getSubject() is also used inside the Shiro framework and also in the Shiro extension package Pac4j which I use (SAML - stuff).
Now I thought about extending my MultiTabSubject in such a way, that it holds the state of all Subjects of it's session and then decides which state it should return when asking for principal and authenticated state. All the other Subject's properties should share the same states. That means, my own MultiTabSubject works like a decorator. But I'm not really sure, if this works without any problems together with the SecurityManager and all it's features.
Does anyone of you has a better idea, how to do this? Or is this a dangerous approach at all? Thank you very much for any input.
I haven't used Vaadin in a long time, cool project though!
Couple things that stick out at me:
1.) There are a couple community Vaadin plugins, i'm not sure if any of them solve this problem though
2.) I'd be hesitant to allow multiple users to log in with different tabs on the same browser. Unless your goal is do allow the same user access to multiple account (i.e. what google does, I have multiple gmail windows open right now, one is mail/u/0 the other is mail/u/1)
Assuming this is just for a single person with multiple accounts, you might be able to get away with this with less code.
Possible just with a SessionManager. You would still need to pull out the Vaadin ID from the request and munch it with the exiting browser session (possible sessionCookieId:VaadinId).
As for SecurityUtils.getSubject(), that _should_ be handled for you, if your SessionManager is working correctly the incoming request will be bound with the current subject at the start of the request, and cleaned up at the end.
(the normal http session model goes out the window with async servlets, so if that is your bag, you would also need to wrap the async bits in a callable: https://shiro.apache.org/subject.html#thread-association (I have some example code for this somewhere, but cannot find it at a glance)
Anyway, let us know if we can point you in more specific direction!
On Wed, Aug 9, 2017 at 3:53 AM, vpcoder <[hidden email]> wrote:
Thank you for the fast response!
1.) Although I already did some research in the internet, I did not found explicit plugins or hints for 'Shiro' 'Vaadin' and 'Tab'. Perhaps I have to search again with different keywords. I will do this today once again.
2.) This user (person) is always the same one, but his account could (not must) be different. For example, the user edits a template in the application as an Admin and wants to see the result as a 'normal' user that has restricted access. Its much easier to open two tabs with different user accounts than just use one tab and always logout one user and then login with the other one. Another example is when changing some settings in the application and immediately wants to monitor the result. Opening two tabs (under the same account) showing two different UIs is much easier than always switching between the different UI's inside one tab. There are much more examples that simplify the workflow when a user can independently login into multiple tabs, like multi-client capability, where a user can select his actual processing client. And so on...
I always thought about holding different subjects (principal, authenticated flag) inside the session by SubjectDAO and then picking the right one by my extended SubjectContext. Your hint with the SessionManager is indeed a different approach than mine, but it sounds really interesting and also easier at the end. I want to follow your approach, but could you please explain me your idea a bit more in detail. Is your idea about creating a new session in the SessionManager for each tab? I'm not so deep into the whole session management of Shiro's SessionManager. To be honest, until shortly before I never thought about extending Shiro's functionality by myself at all...I was just a simple user who wrotes his own Realm classes for Shiro :-)
I would be really glad to get some more details about your idea.
In the meantime I will read once again the Shiro documentation about the SessionManager, to get a bit more into that.
Hi Brian and those who are interested in Shiro with browser's multi tab
I was a bit busy over the last weeks, so I was not able to go further on
this problem. Anyway, I'm back here on 'multiple Subjects in one Session'
and want to give a short feedback, because I have solved my 'multi tab
First I followed the idea from Brian to only extend the SessionManager. I
controlled the Cookie generation and created a new SessionId Cookie (and
therefore a new Session) for every new tab. I did it by appending the
Vaadin's embedId in the Cookie's name. As conclusion each ServletRequest had
multiple sessionIdCookies, one for each tab. Everything worked fine, except
that sometimes I got a ServletRequest without an embedId, which resulted in
a not authenticated Subject. I did not find out, why sometimes a request
came in without embedId. Anyway, I don't know Vaadin so much in detail when
it comes to network communication, so in my opinion, it was a bit too risky
to get this working.
That was the reason I came back to my initial idea, because that only
affects the Shiro mechanism itself, but not the VaadinSessions and
communication too (except the reading of the embedId). For storing and
reading the Sesssion's attributes 'Authenticated' and 'Principals' I added a
separate pair of them for each browser tab by appending the embedId to the
attributes name. After some bug fixing of my code, I got it to work without
any unexpected Vaadin behaviours. For realizing this, I had to extend
SubjectDAO and SubjectContext. For teaching Shiro to use those classes I had
also to extend classes like SecurityManager, SubjectFactory and Subject. The
changes are minimal and easy to understand. For the special case, where I
have to login with SSO (this is configurable by the customer), I don't want
to have a separate Subject for each tab. For this case, I added a special
Session attribute 'FORCE_SESSION_AUTH'. Using this flag I can dynamically
decide, if I need one Subject for the whole Session or for every tab.
I hope this explanation together with my initial post gives you an idea of
my solution. Please forgive me that I can not deliver all those code changes
here in the forum, because of our company's policy. But if you need some
more pointers I'm glad to give you advice.
Sent from: http://shiro-user.582556.n2.nabble.com/
|Free forum by Nabble||Edit this page|