You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Razvan Dragut <ra...@gmail.com> on 2009/02/10 16:27:58 UTC
Subject-Session relationship
Hi everyone,
I am new to JSecurity, I am using it, I have a scenario to implement, I have
some problems with it and I thought you could help :)
scenario :
A website that uses JSecurity to manage user's access to different parts of
the site. Different parts of the site are subject to different terms and
conditions. Also, the download of different products are also subject
different terms and conditions. These terms and conditions may change while
the users are still logged in ( rememberMe or active connection). What we
need is that once the terms and conditions for a particular product/part of
the site is changing, some users must be kicked before doing any action and
forced to re-login to accept the new terms and conditions. Having this
scenario, we need to access a list of all logged in subjects, check their
principals against our particular set of users and kick those who match.
problem :
I've got the JSecurity sources and tried to follow code paths, debug etc etc
and went to the point where I have all the active sessions. Unfortunately I
haven't found a way to reach the subject associated with that session and I
can't get the subject's principals and check them against my separate list.
questions :
What is the way to reach the subject via a session, in my case ?
Is there another way/s to get all the logged in subjects ?
Do you think is a good idea to keep a list of authenticated subjects in my
Realm implementation ? Does it affect clustering or anything else ( mainly
distributed stuff ) ?
still digging :
If you will point me to some listeners, none of the listeners
(AuthenticatingListener or SessionListener) does not know about the subject
but only auth token, auth info, and session so I cannot really handle my
problem (storing the subject somewhere at login time or session initiation
time) only by using listeners and without extending some JSecurity classes
like SecurityManager impls which is not necessary a big effort but it looks
like it (not very nice to maintain) for such a basic thing.
Kind Regards,
Thanks in advance
Razvan
Re: Subject-Session relationship
Posted by Razvan Dragut <ra...@gmail.com>.
Hi Les,
Thanks for the details, things are much clearer now.
P.S: My bad with the SecurityManager logout method.
Best Regards,
Razvan
On Wed, Feb 11, 2009 at 7:48 PM, Les Hazlewood <lh...@apache.org>wrote:
> On Wed, Feb 11, 2009 at 11:51 AM, Razvan <ra...@gmail.com>wrote:
>
>>
>> Hi Les,
>>
>> Thanks for your answer and the effort to write it in such details.
>
>
> My pleasure! I did so because I think this thread can benefit many people
> looking for similar capabilities, especially when it comes to dynamic
> changes to the authorization model at runtime.
>
>
>
>> 2. Regarding the access to the active subjects, I personally do not find
>> it
>> as a performance problem from the following reasons :
>>
>> a) Subjects are already there, we would just need access to them ... For
>> example, a SubjectStore and a SubjectListener or so, that updates the
>> store
>> on : login/logout etc. At the moment i have a similar solution implemented
>> for my problem (store the subjects in Realm implementation) and am writing
>> some test cases to see if it breaks somewhere.
>
>
> This starts to go down JSecurity implementation details, and I didn't cover
> this initially because most end-users should never really know about the
> 'guts' of how Subjects function, and I didn't want to confuse the issue.
> But, in case you're curious:
>
> With the SecurityManager default implementations, Subjects are not 'already
> there'. It creates Subject instances that are extremely lightweight and
> intended to be constructed and thrown away at the beginning and end of a
> request/transaction respectively[1].
>
> The Session however, is long lived - as it needs to be because of temporal
> requirements. So, JSecurity's default Subject creation logic works as
> follows:
>
> (Note this is _very_ implementation specific and developers should _not_
> code with these assumptions. They might change.)
>
> 1. Acquire a session ID based on the incoming request - either a method
> invocation AOP proxy or Http Servlet Request or other means.
> 2. Acquire the Session corresponding to the incoming ID
> 3. From the Session, get the stored PrincipalCollection, authentication
> state, and anything else needed to construct the Subject instance.
> 4. Instantiate a Subject instance based on #3, which wraps the Session
> acquired from #2 (so subject.getSession() returns the same Session).
> 5. 'Bind' the Subject to the application. In most cases this means
> binding the Subject to the currenctly executing Thread and/or
> ServletRequest.
> 6. Process the method invocation or servlet request
> 7. Unbind the Subject instance from the executing thread and/or
> ServletRequest.
>
> This might seem a little confusing since you might would assume that the
> Subject instance itself 'lives' longer than the Session. But that's not the
> case here. However, this is purely an implementation-specific technique and
> can change - one day the Subject instance itself might persist somewhere
> else - who knows. As of right now, it is very lightweight and can be
> instantiated or garbage collected based on thread/request usage.
>
>
>>
>>
>> b) You said it wouldn't be a good idea to allow access to this big number
>> of
>> objects but there is already access to all active sessions via
>> DefaultSecurityManager -> DefaultSessionManager ->
>> SessionDAO.getActiveSessions(). Is this path meant to be used in sessions'
>> mgt/access ? Is it for JSecurity users or is it meant for JSecurity
>> developers ?
>
>
> It is meant for JSecurity developers only. The current implementation
> pulls all Session instances in to memory as a default/simple technique to
> ensure they are still valid. It isn't scalable for environments with
> thousands of concurrent sessions, and exists only as a default fallback
> mechanism - other implementations would do validation in some other way,
> e.g. RDBMS query: "update sessions set stop_timestamp = ?, expired=true
> where last_access_timestamp <= ?", where ? = 'now', i.e. new Date();
>
> This might very well be faster than iterating over instances in memory if
> there are many instances. Or not if 2nd level caching is being used. The
> point is that it is an implementation-specific detail to be overridden in
> these large-scale environments if necessary, strictly for session timestamp
> validation.
>
>
>> I will add a jira feature request because I think, first ... it might be
>> useful in some conditions and may help avoiding workarounds and second ...
>> it is a decent feature even if problems can be sorted in other ways as
>> well.
>
>
> You're more than welcome, but again, because of the implications in highly
> concurrent environments (above), it might not be a good idea. If you see a
> better approach to keeping things performant, we're all ears of course ;)
>
> 3. This is more a semantic question :
>>
>> Why method logout(Subject s) in DefaultSecurityManager behaves different
>> from logout() in DelegatingSubject ?
>
>
> There is no SecurityManager.logout(Subject) method call. There is a
> SecurityManager.logout(PrincipalCollection) method though - the semantics
> are different. End-users should rarely, if ever, interact with a
> SecurityManager. The should however interact with
> SecurityUtils.getSubject(), the Subject(), and the Session interfaces (and
> any Annotations or JSP taglibs that exist).
>
> Cheers,
>
> Les
>
> [1] JSecurity 1.0 will have SubjectBinder and SubjectFactory interfaces to
> abstract the details of how Subjects are bound and acquired even more
> loosely coupled in case an application wants to control exactly how Subject
> instances are made available to the application. However, developers for
> any server-based application should think really hard before changing the
> default request/transaction-based behavior.
>
Re: Subject-Session relationship
Posted by Les Hazlewood <lh...@apache.org>.
On Wed, Feb 11, 2009 at 11:51 AM, Razvan <ra...@gmail.com> wrote:
>
> Hi Les,
>
> Thanks for your answer and the effort to write it in such details.
My pleasure! I did so because I think this thread can benefit many people
looking for similar capabilities, especially when it comes to dynamic
changes to the authorization model at runtime.
> 2. Regarding the access to the active subjects, I personally do not find it
> as a performance problem from the following reasons :
>
> a) Subjects are already there, we would just need access to them ... For
> example, a SubjectStore and a SubjectListener or so, that updates the store
> on : login/logout etc. At the moment i have a similar solution implemented
> for my problem (store the subjects in Realm implementation) and am writing
> some test cases to see if it breaks somewhere.
This starts to go down JSecurity implementation details, and I didn't cover
this initially because most end-users should never really know about the
'guts' of how Subjects function, and I didn't want to confuse the issue.
But, in case you're curious:
With the SecurityManager default implementations, Subjects are not 'already
there'. It creates Subject instances that are extremely lightweight and
intended to be constructed and thrown away at the beginning and end of a
request/transaction respectively[1].
The Session however, is long lived - as it needs to be because of temporal
requirements. So, JSecurity's default Subject creation logic works as
follows:
(Note this is _very_ implementation specific and developers should _not_
code with these assumptions. They might change.)
1. Acquire a session ID based on the incoming request - either a method
invocation AOP proxy or Http Servlet Request or other means.
2. Acquire the Session corresponding to the incoming ID
3. From the Session, get the stored PrincipalCollection, authentication
state, and anything else needed to construct the Subject instance.
4. Instantiate a Subject instance based on #3, which wraps the Session
acquired from #2 (so subject.getSession() returns the same Session).
5. 'Bind' the Subject to the application. In most cases this means binding
the Subject to the currenctly executing Thread and/or ServletRequest.
6. Process the method invocation or servlet request
7. Unbind the Subject instance from the executing thread and/or
ServletRequest.
This might seem a little confusing since you might would assume that the
Subject instance itself 'lives' longer than the Session. But that's not the
case here. However, this is purely an implementation-specific technique and
can change - one day the Subject instance itself might persist somewhere
else - who knows. As of right now, it is very lightweight and can be
instantiated or garbage collected based on thread/request usage.
>
>
> b) You said it wouldn't be a good idea to allow access to this big number
> of
> objects but there is already access to all active sessions via
> DefaultSecurityManager -> DefaultSessionManager ->
> SessionDAO.getActiveSessions(). Is this path meant to be used in sessions'
> mgt/access ? Is it for JSecurity users or is it meant for JSecurity
> developers ?
It is meant for JSecurity developers only. The current implementation pulls
all Session instances in to memory as a default/simple technique to ensure
they are still valid. It isn't scalable for environments with thousands of
concurrent sessions, and exists only as a default fallback mechanism - other
implementations would do validation in some other way, e.g. RDBMS query:
"update sessions set stop_timestamp = ?, expired=true where
last_access_timestamp <= ?", where ? = 'now', i.e. new Date();
This might very well be faster than iterating over instances in memory if
there are many instances. Or not if 2nd level caching is being used. The
point is that it is an implementation-specific detail to be overridden in
these large-scale environments if necessary, strictly for session timestamp
validation.
> I will add a jira feature request because I think, first ... it might be
> useful in some conditions and may help avoiding workarounds and second ...
> it is a decent feature even if problems can be sorted in other ways as
> well.
You're more than welcome, but again, because of the implications in highly
concurrent environments (above), it might not be a good idea. If you see a
better approach to keeping things performant, we're all ears of course ;)
3. This is more a semantic question :
>
> Why method logout(Subject s) in DefaultSecurityManager behaves different
> from logout() in DelegatingSubject ?
There is no SecurityManager.logout(Subject) method call. There is a
SecurityManager.logout(PrincipalCollection) method though - the semantics
are different. End-users should rarely, if ever, interact with a
SecurityManager. The should however interact with
SecurityUtils.getSubject(), the Subject(), and the Session interfaces (and
any Annotations or JSP taglibs that exist).
Cheers,
Les
[1] JSecurity 1.0 will have SubjectBinder and SubjectFactory interfaces to
abstract the details of how Subjects are bound and acquired even more
loosely coupled in case an application wants to control exactly how Subject
instances are made available to the application. However, developers for
any server-based application should think really hard before changing the
default request/transaction-based behavior.
Re: Subject-Session relationship
Posted by Razvan <ra...@gmail.com>.
Hi Les,
Thanks for your answer and the effort to write it in such details.
1. Your approach with permissions is also considered and I am evaluating
strong points and weak points in all available ideas. Having your approach
_written_ , I also found a strong point in it. That is, that in this case we
would not have to worry about bookmarked links or some weird flows as the
check for permission is performed with every request. The weak point (not so
weak -- i am just moaning here :) ) is that I have to play with permissions
at runtime in a wide usage scenario which might be error prone in some
cases. However, this would not be a big problem ... good thing is that my
security domain model fully matches the one you mentioned.
2. Regarding the access to the active subjects, I personally do not find it
as a performance problem from the following reasons :
a) Subjects are already there, we would just need access to them ... For
example, a SubjectStore and a SubjectListener or so, that updates the store
on : login/logout etc. At the moment i have a similar solution implemented
for my problem (store the subjects in Realm implementation) and am writing
some test cases to see if it breaks somewhere.
b) You said it wouldn't be a good idea to allow access to this big number of
objects but there is already access to all active sessions via
DefaultSecurityManager -> DefaultSessionManager ->
SessionDAO.getActiveSessions(). Is this path meant to be used in sessions'
mgt/access ? Is it for JSecurity users or is it meant for JSecurity
developers ?
I will add a jira feature request because I think, first ... it might be
useful in some conditions and may help avoiding workarounds and second ...
it is a decent feature even if problems can be sorted in other ways as well.
3. This is more a semantic question :
Why method logout(Subject s) in DefaultSecurityManager behaves different
from logout() in DelegatingSubject ?
if you do :
DefaultSecurityManager dsm = .......
DelegatingSubject subject = ........
dsm.logout(subject);
subject.isAuthenticated() will return true
whereas if you do :
subject.logout();
subject.isAuthenticated() will return false;
This is because the logout method in DelegatingSubject sets the
authenticated flag to false (along with cleaning other refs) after a call to
logout method in DefaultSecurityManager
I find this a bit confusing and semantically wrong as by having the same
name and the same meaning, both operations must have the same efect on the
subject state.
Also, having 2 ways to logout/login might be confusing at times.
Best Regards,
Razvan
Les Hazlewood-2 wrote:
>
> Hi Razvan,
>
> You're correct in that there is a 1:1 relationship between Subject and
> Session. Each Subject has 1 and only 1 Session at any given time.
>
> But your problem might be better solved by using permissions rather than
> going through all open sessions and checking them manually. JSecurity
> doesn't support this directly - you'd have to create a Jira issue if you'd
> like the ability to acquire all active Subjects. But this can be a
> dangerous proposition, since if there are a lot of active sessions, it
> could
> return quite a few results - not something I'm sure would be a good idea
> to
> allow - we'd have to debate it on the dev list for sure.
>
> But instead, let me propose using Permissions to handle your requirements.
> I use them for very similar if not identical reasons in a few of my
> applications:
>
> If you perform a permission check for the area that is restricted, you can
> just change the user's permission model at runtime and the next time a
> permission check is executed, it can reflect the user's ability at the
> time
> the check is performed - not necessarily their permission state of when
> they
> logged in only.
>
> Here's a simple example:
>
> Lets say you restrict access to a download based on a permission. The
> check
> might look something like this:
>
> String specificProductDownloadPermission = "product:download:" +
> awesomeProduct.getId();
>
> if ( subject.isPermitted( specificProductDownloadPermission ) {
> //show the download link
> } else {
> //don't show it
> }
>
> You would also execute that same Permission check again when they hit the
> url that allows a download, to ensure that even if they had access to the
> url at one time, that they may not have it when they visit the url.
>
> This all implies that you can change Permissions at runtime and the User's
> authorization state immediately reflects those changes. If your realm
> extends JSecurity's AuthorizingRealm (
> http://www.jsecurity.org/api/org/jsecurity/realm/AuthorizingRealm.html),
> as
> most do, then by default JSecurity caches authorization info after login
> so
> the Realm does not need to 'hit' the data store that manages the
> permission
> relationships.
>
> However, you need these permission checks to occur at any time during the
> life of the Subject's Session, so you can't rely on this type of behavior.
> You need the checks to appear instantaneous, not cached after login.
>
> However, if you do this correctly, you don't need ot 'hit' the database
> even
> after disabling caching after login. The way I handle this for my
> applications is that I use a 2nd-level cache with Hibernate to store all
> my
> Roles and Permission objects (for all users). This gives the code a
> 'feel'
> that I'm checking the database every time, but in reality, I'm being saved
> from that overhead by Hibernate's use of 2nd-level cache.
>
> To support this, you would need to do 2 things:
>
> 1) Extend AuthenticatingRealm directly (not AuthorizingRealm). This
> requires you to implement all the Authorization methods yourself. Because
> you have to do this, then you should have 2) a domain model like the
> following (based on some of my applications):
>
> A User entity 'has a' collection of 1 or more Role objects. Each Role
> object 'has a' collection of 1 or more Permission instances.
>
> Consider a user.isPermitted() method, which would iterate over all of the
> Roles assigned to it:
>
> public boolean isPermitted( Permission permission ) {
> for( Role role : getRoles() ) {
> if ( role.isPermitted( permission ) {
> return true;
> }
> }
> return false;
> }
>
> The Role.isPermitted() method would iterate over its children permissions:
>
> public boolean isPermitted( Permission permission ) {
> for( Permission p : getPermissions() ) {
> if ( p.implies(permission) ) {
> return true;
> }
> }
> return false;
> }
>
> Then, you Realm implementation would delegate to the User.* calls. For
> example, the Realm.isPermitted method:
>
> realm.isPermitted( PrincipalCollection userPrincipals, String permission )
> {
> User user = getUser( userPrincipals ); //write a method to acquire
> your
> User instance
> //create a Permission instance based on the String:
> Permission perm = getPermissionResolver().resolvePermission(
> permission
> );
> return user.isPermitted( permission );
> }
>
> You would have to do this for all the Realm.* methods that aren't
> implemented by AuthenticatingRealm, which would be all the authorization
> methods.
>
> You can do this iteration at runtime because of the 2nd-level cache - it
> is
> much faster than executing a RDBMS query every time you have a permission
> check. As you can see though, it _does_ require manual effort on your
> part
> to implement these Realm methods yourself, as well as to have a domain
> model
> that supports this.
>
> This does however allow permission assignments (and revocations) to be
> changed at runtime: you can add or remove permissions from Roles, or you
> can add or remove Roles from Users, all at runtime, and without requiring
> them to log out and then log back in again. I've done this for goverment
> applications that require very strict control that can change at runtime,
> during a user's session - the requirement is that an administrator could
> change their access control at any time and the changes must be reflected
> immediately.
>
> I hope that helps! Please let me know if this makes sense. I've used it
> with great success for highly dynamic environments, and assuming you can
> use
> a 2nd-level cache, you can do this cleanly and effectively.
>
> Best,
>
> Les
>
> On Tue, Feb 10, 2009 at 10:27 AM, Razvan Dragut
> <ra...@gmail.com>wrote:
>
>> Hi everyone,
>>
>> I am new to JSecurity, I am using it, I have a scenario to implement, I
>> have some problems with it and I thought you could help :)
>>
>> scenario :
>>
>> A website that uses JSecurity to manage user's access to different parts
>> of
>> the site. Different parts of the site are subject to different terms and
>> conditions. Also, the download of different products are also subject
>> different terms and conditions. These terms and conditions may change
>> while
>> the users are still logged in ( rememberMe or active connection). What we
>> need is that once the terms and conditions for a particular product/part
>> of
>> the site is changing, some users must be kicked before doing any action
>> and
>> forced to re-login to accept the new terms and conditions. Having this
>> scenario, we need to access a list of all logged in subjects, check their
>> principals against our particular set of users and kick those who match.
>>
>>
>> problem :
>>
>> I've got the JSecurity sources and tried to follow code paths, debug etc
>> etc and went to the point where I have all the active sessions.
>> Unfortunately I haven't found a way to reach the subject associated with
>> that session and I can't get the subject's principals and check them
>> against
>> my separate list.
>>
>>
>> questions :
>>
>> What is the way to reach the subject via a session, in my case ?
>> Is there another way/s to get all the logged in subjects ?
>> Do you think is a good idea to keep a list of authenticated subjects in
>> my
>> Realm implementation ? Does it affect clustering or anything else (
>> mainly
>> distributed stuff ) ?
>>
>>
>> still digging :
>>
>> If you will point me to some listeners, none of the listeners
>> (AuthenticatingListener or SessionListener) does not know about the
>> subject
>> but only auth token, auth info, and session so I cannot really handle my
>> problem (storing the subject somewhere at login time or session
>> initiation
>> time) only by using listeners and without extending some JSecurity
>> classes
>> like SecurityManager impls which is not necessary a big effort but it
>> looks
>> like it (not very nice to maintain) for such a basic thing.
>>
>>
>> Kind Regards,
>>
>> Thanks in advance
>>
>> Razvan
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Subject-Session-relationship-tp2303079p2309819.html
Sent from the JSecurity User mailing list archive at Nabble.com.
Re: Subject-Session relationship
Posted by Les Hazlewood <lh...@apache.org>.
Hi Razvan,
You're correct in that there is a 1:1 relationship between Subject and
Session. Each Subject has 1 and only 1 Session at any given time.
But your problem might be better solved by using permissions rather than
going through all open sessions and checking them manually. JSecurity
doesn't support this directly - you'd have to create a Jira issue if you'd
like the ability to acquire all active Subjects. But this can be a
dangerous proposition, since if there are a lot of active sessions, it could
return quite a few results - not something I'm sure would be a good idea to
allow - we'd have to debate it on the dev list for sure.
But instead, let me propose using Permissions to handle your requirements.
I use them for very similar if not identical reasons in a few of my
applications:
If you perform a permission check for the area that is restricted, you can
just change the user's permission model at runtime and the next time a
permission check is executed, it can reflect the user's ability at the time
the check is performed - not necessarily their permission state of when they
logged in only.
Here's a simple example:
Lets say you restrict access to a download based on a permission. The check
might look something like this:
String specificProductDownloadPermission = "product:download:" +
awesomeProduct.getId();
if ( subject.isPermitted( specificProductDownloadPermission ) {
//show the download link
} else {
//don't show it
}
You would also execute that same Permission check again when they hit the
url that allows a download, to ensure that even if they had access to the
url at one time, that they may not have it when they visit the url.
This all implies that you can change Permissions at runtime and the User's
authorization state immediately reflects those changes. If your realm
extends JSecurity's AuthorizingRealm (
http://www.jsecurity.org/api/org/jsecurity/realm/AuthorizingRealm.html), as
most do, then by default JSecurity caches authorization info after login so
the Realm does not need to 'hit' the data store that manages the permission
relationships.
However, you need these permission checks to occur at any time during the
life of the Subject's Session, so you can't rely on this type of behavior.
You need the checks to appear instantaneous, not cached after login.
However, if you do this correctly, you don't need ot 'hit' the database even
after disabling caching after login. The way I handle this for my
applications is that I use a 2nd-level cache with Hibernate to store all my
Roles and Permission objects (for all users). This gives the code a 'feel'
that I'm checking the database every time, but in reality, I'm being saved
from that overhead by Hibernate's use of 2nd-level cache.
To support this, you would need to do 2 things:
1) Extend AuthenticatingRealm directly (not AuthorizingRealm). This
requires you to implement all the Authorization methods yourself. Because
you have to do this, then you should have 2) a domain model like the
following (based on some of my applications):
A User entity 'has a' collection of 1 or more Role objects. Each Role
object 'has a' collection of 1 or more Permission instances.
Consider a user.isPermitted() method, which would iterate over all of the
Roles assigned to it:
public boolean isPermitted( Permission permission ) {
for( Role role : getRoles() ) {
if ( role.isPermitted( permission ) {
return true;
}
}
return false;
}
The Role.isPermitted() method would iterate over its children permissions:
public boolean isPermitted( Permission permission ) {
for( Permission p : getPermissions() ) {
if ( p.implies(permission) ) {
return true;
}
}
return false;
}
Then, you Realm implementation would delegate to the User.* calls. For
example, the Realm.isPermitted method:
realm.isPermitted( PrincipalCollection userPrincipals, String permission ) {
User user = getUser( userPrincipals ); //write a method to acquire your
User instance
//create a Permission instance based on the String:
Permission perm = getPermissionResolver().resolvePermission( permission
);
return user.isPermitted( permission );
}
You would have to do this for all the Realm.* methods that aren't
implemented by AuthenticatingRealm, which would be all the authorization
methods.
You can do this iteration at runtime because of the 2nd-level cache - it is
much faster than executing a RDBMS query every time you have a permission
check. As you can see though, it _does_ require manual effort on your part
to implement these Realm methods yourself, as well as to have a domain model
that supports this.
This does however allow permission assignments (and revocations) to be
changed at runtime: you can add or remove permissions from Roles, or you
can add or remove Roles from Users, all at runtime, and without requiring
them to log out and then log back in again. I've done this for goverment
applications that require very strict control that can change at runtime,
during a user's session - the requirement is that an administrator could
change their access control at any time and the changes must be reflected
immediately.
I hope that helps! Please let me know if this makes sense. I've used it
with great success for highly dynamic environments, and assuming you can use
a 2nd-level cache, you can do this cleanly and effectively.
Best,
Les
On Tue, Feb 10, 2009 at 10:27 AM, Razvan Dragut
<ra...@gmail.com>wrote:
> Hi everyone,
>
> I am new to JSecurity, I am using it, I have a scenario to implement, I
> have some problems with it and I thought you could help :)
>
> scenario :
>
> A website that uses JSecurity to manage user's access to different parts of
> the site. Different parts of the site are subject to different terms and
> conditions. Also, the download of different products are also subject
> different terms and conditions. These terms and conditions may change while
> the users are still logged in ( rememberMe or active connection). What we
> need is that once the terms and conditions for a particular product/part of
> the site is changing, some users must be kicked before doing any action and
> forced to re-login to accept the new terms and conditions. Having this
> scenario, we need to access a list of all logged in subjects, check their
> principals against our particular set of users and kick those who match.
>
>
> problem :
>
> I've got the JSecurity sources and tried to follow code paths, debug etc
> etc and went to the point where I have all the active sessions.
> Unfortunately I haven't found a way to reach the subject associated with
> that session and I can't get the subject's principals and check them against
> my separate list.
>
>
> questions :
>
> What is the way to reach the subject via a session, in my case ?
> Is there another way/s to get all the logged in subjects ?
> Do you think is a good idea to keep a list of authenticated subjects in my
> Realm implementation ? Does it affect clustering or anything else ( mainly
> distributed stuff ) ?
>
>
> still digging :
>
> If you will point me to some listeners, none of the listeners
> (AuthenticatingListener or SessionListener) does not know about the subject
> but only auth token, auth info, and session so I cannot really handle my
> problem (storing the subject somewhere at login time or session initiation
> time) only by using listeners and without extending some JSecurity classes
> like SecurityManager impls which is not necessary a big effort but it looks
> like it (not very nice to maintain) for such a basic thing.
>
>
> Kind Regards,
>
> Thanks in advance
>
> Razvan
>
>
Re: Subject-Session relationship
Posted by John Cladmore <ju...@lorrev.org>.
Per Les' response about NOT doing anything after logout. I tested it
and it worked even in the ZK event handler.
So if using ZK, just do:
Executions.getCurrent().sendRedirect(someURL); //
Thanks Les.
I remembering seeing this information, about not doing anything with the
session after logout in the quickstart or any the API doc. Please add
a big note about that there and in the logout() API.
.v
John Cladmore wrote:
> I have the same problem, but only when I log out using a ZK event
> handler in my Grails application.
> For some strange reason, calling logout() from a ZK event handler
> causes this problem. HOWEVER, if I instead have that same ZK button
> call a grails controller/action (like /auth/logout which is available
> with the jsec/ki plugin for grails), it works.
>
> For those who know ZK, this works:
> ----- .zul
> <button label="Logout" href="/auth/logout" />
>
> and allows you to log in again
>
> but this DOES NOT:
> --- .zul
> <button id="btLogout" label="Logout" forward="onLogout"/>
> ...
> ---- .groovy
> class SomeComposer extends GenericForwardComposer{
> ...
> void onLogout(ForwardEvent evt){
> ...
> SecurityUtils.subject.logout()
> ...
> }
> }
>
> Someone on the zk-grails forum suggested a listener setting in zk.xml,
> but it didn't work.
>
> I can provide more information/example code if it will help.
>
> .v
>
> Les Hazlewood wrote:
>> Subject#getSession() should not return null. Do you have a stack
>> trace or test case that can re-create this issue? If so, please
>> create a Jira issue.
>>
>> On Tue, Jul 14, 2009 at 12:50 AM, javamallu <binnyal@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>
>> Hi,
>>
>>
>> I am also facing a problem regarding sessions .First time when I
>> login to my
>> application the Subject.getSession returns a valid session and it is
>> successfully loggedin.But when I logout and login again in same
>> browser,the
>> Subject.getSession returns null.Please help.
>>
>> Alphy
>>
>> Razvan wrote:
>> >
>> > Hi everyone,
>> >
>> > I am new to JSecurity, I am using it, I have a scenario to
>> implement, I
>> > have
>> > some problems with it and I thought you could help :)
>> >
>> > scenario :
>> >
>> > A website that uses JSecurity to manage user's access to
>> different parts
>> > of
>> > the site. Different parts of the site are subject to different
>> terms and
>> > conditions. Also, the download of different products are also
>> subject
>> > different terms and conditions. These terms and conditions may
>> change
>> > while
>> > the users are still logged in ( rememberMe or active
>> connection). What we
>> > need is that once the terms and conditions for a particular
>> product/part
>> > of
>> > the site is changing, some users must be kicked before doing any
>> action
>> > and
>> > forced to re-login to accept the new terms and conditions.
>> Having this
>> > scenario, we need to access a list of all logged in subjects,
>> check their
>> > principals against our particular set of users and kick those
>> who match.
>> >
>> >
>> > problem :
>> >
>> > I've got the JSecurity sources and tried to follow code paths,
>> debug etc
>> > etc
>> > and went to the point where I have all the active sessions.
>> Unfortunately
>> > I
>> > haven't found a way to reach the subject associated with that
>> session and
>> > I
>> > can't get the subject's principals and check them against my
>> separate
>> > list.
>> >
>> >
>> > questions :
>> >
>> > What is the way to reach the subject via a session, in my case ?
>> > Is there another way/s to get all the logged in subjects ?
>> > Do you think is a good idea to keep a list of authenticated
>> subjects in my
>> > Realm implementation ? Does it affect clustering or anything
>> else ( mainly
>> > distributed stuff ) ?
>> >
>> >
>> > still digging :
>> >
>> > If you will point me to some listeners, none of the listeners
>> > (AuthenticatingListener or SessionListener) does not know about
>> the
>> > subject
>> > but only auth token, auth info, and session so I cannot really
>> handle my
>> > problem (storing the subject somewhere at login time or session
>> initiation
>> > time) only by using listeners and without extending some
>> JSecurity classes
>> > like SecurityManager impls which is not necessary a big effort
>> but it
>> > looks
>> > like it (not very nice to maintain) for such a basic thing.
>> >
>> >
>> > Kind Regards,
>> >
>> > Thanks in advance
>> >
>> > Razvan
>> >
>> >
>>
>> --
>> View this message in context:
>>
>> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3254275.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>>
Re: Subject-Session relationship
Posted by John Cladmore <ju...@lorrev.org>.
I have the same problem, but only when I log out using a ZK event
handler in my Grails application.
For some strange reason, calling logout() from a ZK event handler causes
this problem. HOWEVER, if I instead have that same ZK button call a
grails controller/action (like /auth/logout which is available with the
jsec/ki plugin for grails), it works.
For those who know ZK, this works:
----- .zul
<button label="Logout" href="/auth/logout" />
and allows you to log in again
but this DOES NOT:
--- .zul
<button id="btLogout" label="Logout" forward="onLogout"/>
...
---- .groovy
class SomeComposer extends GenericForwardComposer{
...
void onLogout(ForwardEvent evt){
...
SecurityUtils.subject.logout()
...
}
}
Someone on the zk-grails forum suggested a listener setting in zk.xml,
but it didn't work.
I can provide more information/example code if it will help.
.v
Les Hazlewood wrote:
> Subject#getSession() should not return null. Do you have a stack
> trace or test case that can re-create this issue? If so, please
> create a Jira issue.
>
> On Tue, Jul 14, 2009 at 12:50 AM, javamallu <binnyal@gmail.com
> <ma...@gmail.com>> wrote:
>
>
> Hi,
>
>
> I am also facing a problem regarding sessions .First time when I
> login to my
> application the Subject.getSession returns a valid session and it is
> successfully loggedin.But when I logout and login again in same
> browser,the
> Subject.getSession returns null.Please help.
>
> Alphy
>
> Razvan wrote:
> >
> > Hi everyone,
> >
> > I am new to JSecurity, I am using it, I have a scenario to
> implement, I
> > have
> > some problems with it and I thought you could help :)
> >
> > scenario :
> >
> > A website that uses JSecurity to manage user's access to
> different parts
> > of
> > the site. Different parts of the site are subject to different
> terms and
> > conditions. Also, the download of different products are also
> subject
> > different terms and conditions. These terms and conditions may
> change
> > while
> > the users are still logged in ( rememberMe or active
> connection). What we
> > need is that once the terms and conditions for a particular
> product/part
> > of
> > the site is changing, some users must be kicked before doing any
> action
> > and
> > forced to re-login to accept the new terms and conditions.
> Having this
> > scenario, we need to access a list of all logged in subjects,
> check their
> > principals against our particular set of users and kick those
> who match.
> >
> >
> > problem :
> >
> > I've got the JSecurity sources and tried to follow code paths,
> debug etc
> > etc
> > and went to the point where I have all the active sessions.
> Unfortunately
> > I
> > haven't found a way to reach the subject associated with that
> session and
> > I
> > can't get the subject's principals and check them against my
> separate
> > list.
> >
> >
> > questions :
> >
> > What is the way to reach the subject via a session, in my case ?
> > Is there another way/s to get all the logged in subjects ?
> > Do you think is a good idea to keep a list of authenticated
> subjects in my
> > Realm implementation ? Does it affect clustering or anything
> else ( mainly
> > distributed stuff ) ?
> >
> >
> > still digging :
> >
> > If you will point me to some listeners, none of the listeners
> > (AuthenticatingListener or SessionListener) does not know about the
> > subject
> > but only auth token, auth info, and session so I cannot really
> handle my
> > problem (storing the subject somewhere at login time or session
> initiation
> > time) only by using listeners and without extending some
> JSecurity classes
> > like SecurityManager impls which is not necessary a big effort
> but it
> > looks
> > like it (not very nice to maintain) for such a basic thing.
> >
> >
> > Kind Regards,
> >
> > Thanks in advance
> >
> > Razvan
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3254275.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
>
Re: Subject-Session relationship
Posted by javamallu <bi...@gmail.com>.
Thanks Les.
I will look into it and see what is happening.
On Wed, Jul 15, 2009 at 12:21 PM, Les Hazlewood-2 (via Nabble) <
ml-user+51627-469078609@n2.nabble.com<ml...@n2.nabble.com>
> wrote:
> Hi Alphy,
>
> This is highly irregular - the only way this could occur is if the Servlet
> Container returned null for the httpServletRequest.getSession() call, which
> I'm not sure should ever happen.
>
> Typically after logout, a user is redirected to a home page, login page, or
> some other status page stating the user has been logged out. Do you do do
> this kind of thing? If not, you have to be careful not to use the session
> after loggging out the Subject.
>
> That is, ensure that during a thread's execution, you do not do this:
>
> subject.logout();
>
> //some more work, anywhere in the application, but before the response is
> finished
>
> subject.getSession();
>
> This is a limitation of the servlet container, and not of Shiro. Just be
> aware of when you might be trying to use the http session after you call
> logout. This is a good reason to redirect immediately after calling
> logout() to ensure this won't happen to you in a webapp.
>
> I hope that helps!
>
> Les
>
> On Tue, Jul 14, 2009 at 11:05 PM, javamallu <binnyal@...<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3261043&i=0>
> > wrote:
>
>>
>> Hi Les,
>>
>> Please find the stack trace.
>>
>> java.lang.IllegalArgumentException: HttpSession constructor argument
>> cannot
>> be null.
>> at org.jsecurity.web.session.WebSession.<init>(WebSession.java:51)
>> at
>>
>> org.jsecurity.web.session.ServletContainerSessionManager.createSession(ServletContainerSessionManager.java:85)
>> at
>>
>> org.jsecurity.web.session.ServletContainerSessionManager.createSession(ServletContainerSessionManager.java:81)
>> at
>>
>> org.jsecurity.session.mgt.AbstractSessionManager.start(AbstractSessionManager.java:63)
>> at
>>
>> org.jsecurity.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:254)
>> at
>>
>> org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:286)
>> at
>>
>> org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:274)
>> at
>>
>> org.jsecurity.web.DefaultWebSecurityManager.bind(DefaultWebSecurityManager.java:244)
>> at
>>
>> org.jsecurity.web.DefaultWebSecurityManager.bind(DefaultWebSecurityManager.java:237)
>> at
>>
>> org.jsecurity.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:329)
>> at
>> org.jsecurity.subject.DelegatingSubject.login(DelegatingSubject.java:239)
>>
>>
>> Thanks,
>>
>> Alphy
>>
>>
>> Les Hazlewood-2 wrote:
>> >
>> > Subject#getSession() should not return null. Do you have a stack trace
>> or
>> > test case that can re-create this issue? If so, please create a Jira
>> > issue.
>> >
>> > On Tue, Jul 14, 2009 at 12:50 AM, javamallu <binnyal@...<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3261043&i=1>>
>> wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >>
>> >> I am also facing a problem regarding sessions .First time when I login
>> to
>> >> my
>> >> application the Subject.getSession returns a valid session and it is
>> >> successfully loggedin.But when I logout and login again in same
>> >> browser,the
>> >> Subject.getSession returns null.Please help.
>> >>
>> >> Alphy
>> >>
>> >> Razvan wrote:
>> >> >
>> >> > Hi everyone,
>> >> >
>> >> > I am new to JSecurity, I am using it, I have a scenario to implement,
>> I
>> >> > have
>> >> > some problems with it and I thought you could help :)
>> >> >
>> >> > scenario :
>> >> >
>> >> > A website that uses JSecurity to manage user's access to different
>> >> parts
>> >> > of
>> >> > the site. Different parts of the site are subject to different terms
>> >> and
>> >> > conditions. Also, the download of different products are also subject
>> >> > different terms and conditions. These terms and conditions may change
>> >> > while
>> >> > the users are still logged in ( rememberMe or active connection).
>> What
>> >> we
>> >> > need is that once the terms and conditions for a particular
>> >> product/part
>> >> > of
>> >> > the site is changing, some users must be kicked before doing any
>> action
>> >> > and
>> >> > forced to re-login to accept the new terms and conditions. Having
>> this
>> >> > scenario, we need to access a list of all logged in subjects, check
>> >> their
>> >> > principals against our particular set of users and kick those who
>> >> match.
>> >> >
>> >> >
>> >> > problem :
>> >> >
>> >> > I've got the JSecurity sources and tried to follow code paths, debug
>> >> etc
>> >> > etc
>> >> > and went to the point where I have all the active sessions.
>> >> Unfortunately
>> >> > I
>> >> > haven't found a way to reach the subject associated with that session
>> >> and
>> >> > I
>> >> > can't get the subject's principals and check them against my separate
>> >> > list.
>> >> >
>> >> >
>> >> > questions :
>> >> >
>> >> > What is the way to reach the subject via a session, in my case ?
>> >> > Is there another way/s to get all the logged in subjects ?
>> >> > Do you think is a good idea to keep a list of authenticated subjects
>> in
>> >> my
>> >> > Realm implementation ? Does it affect clustering or anything else (
>> >> mainly
>> >> > distributed stuff ) ?
>> >> >
>> >> >
>> >> > still digging :
>> >> >
>> >> > If you will point me to some listeners, none of the listeners
>> >> > (AuthenticatingListener or SessionListener) does not know about the
>> >> > subject
>> >> > but only auth token, auth info, and session so I cannot really handle
>> >> my
>> >> > problem (storing the subject somewhere at login time or session
>> >> initiation
>> >> > time) only by using listeners and without extending some JSecurity
>> >> classes
>> >> > like SecurityManager impls which is not necessary a big effort but it
>> >> > looks
>> >> > like it (not very nice to maintain) for such a basic thing.
>> >> >
>> >> >
>> >> > Kind Regards,
>> >> >
>> >> > Thanks in advance
>> >> >
>> >> > Razvan
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3254275.html
>> >> Sent from the Shiro User mailing list archive at Nabble.com.
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3260763.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
>
>
> ------------------------------
> View message @
> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3261043.html
> To unsubscribe from Re: Subject-Session relationship, click here< (link removed) ==>.
>
>
>
--
View this message in context: http://n2.nabble.com/Subject-Session-relationship-tp2303079p3270116.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Subject-Session relationship
Posted by Les Hazlewood <lh...@apache.org>.
Hi Alphy,
This is highly irregular - the only way this could occur is if the Servlet
Container returned null for the httpServletRequest.getSession() call, which
I'm not sure should ever happen.
Typically after logout, a user is redirected to a home page, login page, or
some other status page stating the user has been logged out. Do you do do
this kind of thing? If not, you have to be careful not to use the session
after loggging out the Subject.
That is, ensure that during a thread's execution, you do not do this:
subject.logout();
//some more work, anywhere in the application, but before the response is
finished
subject.getSession();
This is a limitation of the servlet container, and not of Shiro. Just be
aware of when you might be trying to use the http session after you call
logout. This is a good reason to redirect immediately after calling
logout() to ensure this won't happen to you in a webapp.
I hope that helps!
Les
On Tue, Jul 14, 2009 at 11:05 PM, javamallu <bi...@gmail.com> wrote:
>
> Hi Les,
>
> Please find the stack trace.
>
> java.lang.IllegalArgumentException: HttpSession constructor argument cannot
> be null.
> at org.jsecurity.web.session.WebSession.<init>(WebSession.java:51)
> at
>
> org.jsecurity.web.session.ServletContainerSessionManager.createSession(ServletContainerSessionManager.java:85)
> at
>
> org.jsecurity.web.session.ServletContainerSessionManager.createSession(ServletContainerSessionManager.java:81)
> at
>
> org.jsecurity.session.mgt.AbstractSessionManager.start(AbstractSessionManager.java:63)
> at
>
> org.jsecurity.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:254)
> at
>
> org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:286)
> at
>
> org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:274)
> at
>
> org.jsecurity.web.DefaultWebSecurityManager.bind(DefaultWebSecurityManager.java:244)
> at
>
> org.jsecurity.web.DefaultWebSecurityManager.bind(DefaultWebSecurityManager.java:237)
> at
>
> org.jsecurity.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:329)
> at
> org.jsecurity.subject.DelegatingSubject.login(DelegatingSubject.java:239)
>
>
> Thanks,
>
> Alphy
>
> Les Hazlewood-2 wrote:
> >
> > Subject#getSession() should not return null. Do you have a stack trace
> or
> > test case that can re-create this issue? If so, please create a Jira
> > issue.
> >
> > On Tue, Jul 14, 2009 at 12:50 AM, javamallu <bi...@gmail.com> wrote:
> >
> >>
> >> Hi,
> >>
> >>
> >> I am also facing a problem regarding sessions .First time when I login
> to
> >> my
> >> application the Subject.getSession returns a valid session and it is
> >> successfully loggedin.But when I logout and login again in same
> >> browser,the
> >> Subject.getSession returns null.Please help.
> >>
> >> Alphy
> >>
> >> Razvan wrote:
> >> >
> >> > Hi everyone,
> >> >
> >> > I am new to JSecurity, I am using it, I have a scenario to implement,
> I
> >> > have
> >> > some problems with it and I thought you could help :)
> >> >
> >> > scenario :
> >> >
> >> > A website that uses JSecurity to manage user's access to different
> >> parts
> >> > of
> >> > the site. Different parts of the site are subject to different terms
> >> and
> >> > conditions. Also, the download of different products are also subject
> >> > different terms and conditions. These terms and conditions may change
> >> > while
> >> > the users are still logged in ( rememberMe or active connection). What
> >> we
> >> > need is that once the terms and conditions for a particular
> >> product/part
> >> > of
> >> > the site is changing, some users must be kicked before doing any
> action
> >> > and
> >> > forced to re-login to accept the new terms and conditions. Having this
> >> > scenario, we need to access a list of all logged in subjects, check
> >> their
> >> > principals against our particular set of users and kick those who
> >> match.
> >> >
> >> >
> >> > problem :
> >> >
> >> > I've got the JSecurity sources and tried to follow code paths, debug
> >> etc
> >> > etc
> >> > and went to the point where I have all the active sessions.
> >> Unfortunately
> >> > I
> >> > haven't found a way to reach the subject associated with that session
> >> and
> >> > I
> >> > can't get the subject's principals and check them against my separate
> >> > list.
> >> >
> >> >
> >> > questions :
> >> >
> >> > What is the way to reach the subject via a session, in my case ?
> >> > Is there another way/s to get all the logged in subjects ?
> >> > Do you think is a good idea to keep a list of authenticated subjects
> in
> >> my
> >> > Realm implementation ? Does it affect clustering or anything else (
> >> mainly
> >> > distributed stuff ) ?
> >> >
> >> >
> >> > still digging :
> >> >
> >> > If you will point me to some listeners, none of the listeners
> >> > (AuthenticatingListener or SessionListener) does not know about the
> >> > subject
> >> > but only auth token, auth info, and session so I cannot really handle
> >> my
> >> > problem (storing the subject somewhere at login time or session
> >> initiation
> >> > time) only by using listeners and without extending some JSecurity
> >> classes
> >> > like SecurityManager impls which is not necessary a big effort but it
> >> > looks
> >> > like it (not very nice to maintain) for such a basic thing.
> >> >
> >> >
> >> > Kind Regards,
> >> >
> >> > Thanks in advance
> >> >
> >> > Razvan
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3254275.html
> >> Sent from the Shiro User mailing list archive at Nabble.com.
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3260763.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Subject-Session relationship
Posted by javamallu <bi...@gmail.com>.
Hi Les,
Please find the stack trace.
java.lang.IllegalArgumentException: HttpSession constructor argument cannot
be null.
at org.jsecurity.web.session.WebSession.<init>(WebSession.java:51)
at
org.jsecurity.web.session.ServletContainerSessionManager.createSession(ServletContainerSessionManager.java:85)
at
org.jsecurity.web.session.ServletContainerSessionManager.createSession(ServletContainerSessionManager.java:81)
at
org.jsecurity.session.mgt.AbstractSessionManager.start(AbstractSessionManager.java:63)
at
org.jsecurity.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:254)
at
org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:286)
at
org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:274)
at
org.jsecurity.web.DefaultWebSecurityManager.bind(DefaultWebSecurityManager.java:244)
at
org.jsecurity.web.DefaultWebSecurityManager.bind(DefaultWebSecurityManager.java:237)
at
org.jsecurity.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:329)
at
org.jsecurity.subject.DelegatingSubject.login(DelegatingSubject.java:239)
Thanks,
Alphy
Les Hazlewood-2 wrote:
>
> Subject#getSession() should not return null. Do you have a stack trace or
> test case that can re-create this issue? If so, please create a Jira
> issue.
>
> On Tue, Jul 14, 2009 at 12:50 AM, javamallu <bi...@gmail.com> wrote:
>
>>
>> Hi,
>>
>>
>> I am also facing a problem regarding sessions .First time when I login to
>> my
>> application the Subject.getSession returns a valid session and it is
>> successfully loggedin.But when I logout and login again in same
>> browser,the
>> Subject.getSession returns null.Please help.
>>
>> Alphy
>>
>> Razvan wrote:
>> >
>> > Hi everyone,
>> >
>> > I am new to JSecurity, I am using it, I have a scenario to implement, I
>> > have
>> > some problems with it and I thought you could help :)
>> >
>> > scenario :
>> >
>> > A website that uses JSecurity to manage user's access to different
>> parts
>> > of
>> > the site. Different parts of the site are subject to different terms
>> and
>> > conditions. Also, the download of different products are also subject
>> > different terms and conditions. These terms and conditions may change
>> > while
>> > the users are still logged in ( rememberMe or active connection). What
>> we
>> > need is that once the terms and conditions for a particular
>> product/part
>> > of
>> > the site is changing, some users must be kicked before doing any action
>> > and
>> > forced to re-login to accept the new terms and conditions. Having this
>> > scenario, we need to access a list of all logged in subjects, check
>> their
>> > principals against our particular set of users and kick those who
>> match.
>> >
>> >
>> > problem :
>> >
>> > I've got the JSecurity sources and tried to follow code paths, debug
>> etc
>> > etc
>> > and went to the point where I have all the active sessions.
>> Unfortunately
>> > I
>> > haven't found a way to reach the subject associated with that session
>> and
>> > I
>> > can't get the subject's principals and check them against my separate
>> > list.
>> >
>> >
>> > questions :
>> >
>> > What is the way to reach the subject via a session, in my case ?
>> > Is there another way/s to get all the logged in subjects ?
>> > Do you think is a good idea to keep a list of authenticated subjects in
>> my
>> > Realm implementation ? Does it affect clustering or anything else (
>> mainly
>> > distributed stuff ) ?
>> >
>> >
>> > still digging :
>> >
>> > If you will point me to some listeners, none of the listeners
>> > (AuthenticatingListener or SessionListener) does not know about the
>> > subject
>> > but only auth token, auth info, and session so I cannot really handle
>> my
>> > problem (storing the subject somewhere at login time or session
>> initiation
>> > time) only by using listeners and without extending some JSecurity
>> classes
>> > like SecurityManager impls which is not necessary a big effort but it
>> > looks
>> > like it (not very nice to maintain) for such a basic thing.
>> >
>> >
>> > Kind Regards,
>> >
>> > Thanks in advance
>> >
>> > Razvan
>> >
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3254275.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
>
--
View this message in context: http://n2.nabble.com/Subject-Session-relationship-tp2303079p3260763.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Subject-Session relationship
Posted by Les Hazlewood <lh...@apache.org>.
Subject#getSession() should not return null. Do you have a stack trace or
test case that can re-create this issue? If so, please create a Jira issue.
On Tue, Jul 14, 2009 at 12:50 AM, javamallu <bi...@gmail.com> wrote:
>
> Hi,
>
>
> I am also facing a problem regarding sessions .First time when I login to
> my
> application the Subject.getSession returns a valid session and it is
> successfully loggedin.But when I logout and login again in same browser,the
> Subject.getSession returns null.Please help.
>
> Alphy
>
> Razvan wrote:
> >
> > Hi everyone,
> >
> > I am new to JSecurity, I am using it, I have a scenario to implement, I
> > have
> > some problems with it and I thought you could help :)
> >
> > scenario :
> >
> > A website that uses JSecurity to manage user's access to different parts
> > of
> > the site. Different parts of the site are subject to different terms and
> > conditions. Also, the download of different products are also subject
> > different terms and conditions. These terms and conditions may change
> > while
> > the users are still logged in ( rememberMe or active connection). What we
> > need is that once the terms and conditions for a particular product/part
> > of
> > the site is changing, some users must be kicked before doing any action
> > and
> > forced to re-login to accept the new terms and conditions. Having this
> > scenario, we need to access a list of all logged in subjects, check their
> > principals against our particular set of users and kick those who match.
> >
> >
> > problem :
> >
> > I've got the JSecurity sources and tried to follow code paths, debug etc
> > etc
> > and went to the point where I have all the active sessions. Unfortunately
> > I
> > haven't found a way to reach the subject associated with that session and
> > I
> > can't get the subject's principals and check them against my separate
> > list.
> >
> >
> > questions :
> >
> > What is the way to reach the subject via a session, in my case ?
> > Is there another way/s to get all the logged in subjects ?
> > Do you think is a good idea to keep a list of authenticated subjects in
> my
> > Realm implementation ? Does it affect clustering or anything else (
> mainly
> > distributed stuff ) ?
> >
> >
> > still digging :
> >
> > If you will point me to some listeners, none of the listeners
> > (AuthenticatingListener or SessionListener) does not know about the
> > subject
> > but only auth token, auth info, and session so I cannot really handle my
> > problem (storing the subject somewhere at login time or session
> initiation
> > time) only by using listeners and without extending some JSecurity
> classes
> > like SecurityManager impls which is not necessary a big effort but it
> > looks
> > like it (not very nice to maintain) for such a basic thing.
> >
> >
> > Kind Regards,
> >
> > Thanks in advance
> >
> > Razvan
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Subject-Session-relationship-tp2303079p3254275.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Subject-Session relationship
Posted by javamallu <bi...@gmail.com>.
Hi,
I am also facing a problem regarding sessions .First time when I login to my
application the Subject.getSession returns a valid session and it is
successfully loggedin.But when I logout and login again in same browser,the
Subject.getSession returns null.Please help.
Alphy
Razvan wrote:
>
> Hi everyone,
>
> I am new to JSecurity, I am using it, I have a scenario to implement, I
> have
> some problems with it and I thought you could help :)
>
> scenario :
>
> A website that uses JSecurity to manage user's access to different parts
> of
> the site. Different parts of the site are subject to different terms and
> conditions. Also, the download of different products are also subject
> different terms and conditions. These terms and conditions may change
> while
> the users are still logged in ( rememberMe or active connection). What we
> need is that once the terms and conditions for a particular product/part
> of
> the site is changing, some users must be kicked before doing any action
> and
> forced to re-login to accept the new terms and conditions. Having this
> scenario, we need to access a list of all logged in subjects, check their
> principals against our particular set of users and kick those who match.
>
>
> problem :
>
> I've got the JSecurity sources and tried to follow code paths, debug etc
> etc
> and went to the point where I have all the active sessions. Unfortunately
> I
> haven't found a way to reach the subject associated with that session and
> I
> can't get the subject's principals and check them against my separate
> list.
>
>
> questions :
>
> What is the way to reach the subject via a session, in my case ?
> Is there another way/s to get all the logged in subjects ?
> Do you think is a good idea to keep a list of authenticated subjects in my
> Realm implementation ? Does it affect clustering or anything else ( mainly
> distributed stuff ) ?
>
>
> still digging :
>
> If you will point me to some listeners, none of the listeners
> (AuthenticatingListener or SessionListener) does not know about the
> subject
> but only auth token, auth info, and session so I cannot really handle my
> problem (storing the subject somewhere at login time or session initiation
> time) only by using listeners and without extending some JSecurity classes
> like SecurityManager impls which is not necessary a big effort but it
> looks
> like it (not very nice to maintain) for such a basic thing.
>
>
> Kind Regards,
>
> Thanks in advance
>
> Razvan
>
>
--
View this message in context: http://n2.nabble.com/Subject-Session-relationship-tp2303079p3254275.html
Sent from the Shiro User mailing list archive at Nabble.com.