Hi Brian

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.


Brian Demers wrote
> 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!
> https://shiro.apache.org/integration.html
> On Wed, Aug 9, 2017 at 3:53 AM, vpcoder <

> m.rellstab@

> > wrote:
>> Hi all,
>> 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.
>> Michi
>> --
>> View this message in context: http://shiro-user.582556.n2.
>> nabble.com/Multiple-subjects-in-one-session-tp7581737.html
>> Sent from the Shiro User mailing list archive at Nabble.com.

View this message in context: 
Sent from the Shiro User mailing list archive at Nabble.com.

Reply via email to