Session management and creation / destruction

[Marcus Bond <ma...@marcusbond.me.uk>]

Hi all,

 

I was reading through the documentation and I couldn't find relevant
information so hope you guys can help.. essentially I have three Subject /
user session management scenarios in the one web application..

 

1)      Certain urls are accessed via a user's browser, this is easy enough
with the FormAuthenticationFilter or PassThrough version and sessions are
managed by Shiro using the default Servlet container sessions - it is a
Spring MVC application and so it is important that the session data is
stored in the same object regardless of if set via a Subject or on the
session passed to any controllers.. this works fine.

 

2)      Another set of URL's are accessed differently and require
authentication on every request with Basic Authentication so a
BasicHttpAuthenticationFilter is used but any session created must be
destroyed at the end of the request, however I may need to fire up separate
threads during these requests that will run as the authenticated user.

 

3)      Other processes are kicked off by Quartz and are run as particular
subjects and I need to be able to create Subjects that are not dependent
upon any form of web context (e.g. HTTPRequest / Session).

 

 

So the problems I need to solve in the same configuration are :

HTTP basic authentication of a subject (ok), populating their session with
some data (because the session is the only "data holder" that a subject has)
and starting other threads with this subject and session whilst ensuring
that their session is no longer 

hanging about in the application once the HTTP request is complete and any
child threads have completed.

 

Web application sessions such that any data set on the HTTPSession (filters,
controllers etc.) is available from the Shiro subject session (in the
request thread and any child threads that may be started).

 

Subject creation (and again session as a data holder) where there is no web
context.

 

 

If anyone can detail how the combination above could be achieve or point me
in the direction of other articles that may have achieved this I would be
most grateful (the web subject / session and non-web subject / session in
the same app must be a common use-case right?)

 

Regards,

Marcus.

 

RE: Session management and creation / destruction

[Marcus Bond <ma...@marcusbond.me.uk>]

Thanks Les, yes that helps.

I haven't checked yet but could you confirm that if we use Shiro native
sessions in a web environment then Shiro still simply "decorates" the normal
HttpSession?
In other words if for instance some filthy JSP code or  a Spring controller
sets a (HTTP) session attribute it can later be accessed directly from the
Shiro subjects session AND from the session given to the JSP or controller?
My feeling from a cursory glance at the code is that the first thing that
Shiro does is to wrap / decorate the HTTP session provided by the container
prior to passing down the filter chain hence the Shiro subject session and
Http session as exposed to later code are one and the same thing?

If this is the case then I don't think I have anything to worry about..

-----Original Message-----
From: Les Hazlewood [mailto:lhazlewood@apache.org] 
Sent: 24 August 2012 22:23
To: user@shiro.apache.org
Subject: Re: Session management and creation / destruction

On Sun, Jul 29, 2012 at 1:59 PM, Marcus Bond <ma...@marcusbond.me.uk>
wrote:

> 2)      Another set of URL's are accessed differently and require
> authentication on every request with Basic Authentication so a 
> BasicHttpAuthenticationFilter is used but any session created must be 
> destroyed at the end of the request, however I may need to fire up 
> separate threads during these requests that will run as the authenticated
user.

I don't think you need a session in this case.  You can tell Shiro to not
create a session during a request (and therefore you don't need to stop it
at the end of a request) by using the 'noSessionCreation'
filter:

http://shiro.apache.org/static/current/apidocs/org/apache/shiro/web/filter/s
ession/NoSessionCreationFilter.html

As long as you don't use the session during the thread processing.

If you must use the session during the request, but the session must be
cleaned up at the end of the request, you'll need to create a custom filter
that will call subject.logout() at the end of the request, after all other
filters and/or servlets have executed.

You could do this by subclassing Shiro's AdviceFilter and overriding the
afterCompletion method to execute subject.logout();

> So the problems I need to solve in the same configuration are :

If you require a single Shiro environment/configuration, and your #3
scenario requires sessions as well, you cannot use the default Servlet
container session manager.
The servlet container sessions only work by filtering http requests, which
won't exist in #3.

Shiro's native session manager however supports sessions in both web and
non-web scenarios.

> Subject creation (and again session as a data holder) where there is 
> no web context.

You will need to use the Subject.Builder for this.  The ShiroFilter will
automatically instantiate and bind the Subject to the thread during HTTP
requests.  If you application executes code outside the context of a request
(e.g. cron or quartz), you will need to instantiate the Subject and bind it
to the thread yourself.

This is actually very easy to do with the Subject.Builder.  For example:

Subject subject = new Subject.Builder(shiroSecurityManager). // chain
methods here as necessary  //
    .buildSubject();

//the Subject.execute call will automatically bind and unbind the Subject to
the thread, before and after the method completes
(respectively):

subject.execute(new Callable() {
    //do work as the Subject here
});

The different techniques for Subject creation and thread association are
documented here: http://shiro.apache.org/subject.html

In the 'Subject.Builder' section.

HTH!

Les

Re: Session management and creation / destruction

[Les Hazlewood <lh...@apache.org>]

On Sun, Jul 29, 2012 at 1:59 PM, Marcus Bond <ma...@marcusbond.me.uk> wrote:

> 2)      Another set of URL’s are accessed differently and require
> authentication on every request with Basic Authentication so a
> BasicHttpAuthenticationFilter is used but any session created must be
> destroyed at the end of the request, however I may need to fire up separate
> threads during these requests that will run as the authenticated user.

I don't think you need a session in this case.  You can tell Shiro to
not create a session during a request (and therefore you don't need to
stop it at the end of a request) by using the 'noSessionCreation'
filter:

http://shiro.apache.org/static/current/apidocs/org/apache/shiro/web/filter/session/NoSessionCreationFilter.html

As long as you don't use the session during the thread processing.

If you must use the session during the request, but the session must
be cleaned up at the end of the request, you'll need to create a
custom filter that will call subject.logout() at the end of the
request, after all other filters and/or servlets have executed.

You could do this by subclassing Shiro's AdviceFilter and overriding
the afterCompletion method to execute subject.logout();

> So the problems I need to solve in the same configuration are :

If you require a single Shiro environment/configuration, and your #3
scenario requires sessions as well, you cannot use the default Servlet
container session manager.
The servlet container sessions only work by filtering http requests,
which won't exist in #3.

Shiro's native session manager however supports sessions in both web
and non-web scenarios.

> Subject creation (and again session as a data holder) where there is no web
> context.

You will need to use the Subject.Builder for this.  The ShiroFilter
will automatically instantiate and bind the Subject to the thread
during HTTP requests.  If you application executes code outside the
context of a request (e.g. cron or quartz), you will need to
instantiate the Subject and bind it to the thread yourself.

This is actually very easy to do with the Subject.Builder.  For example:

Subject subject = new Subject.Builder(shiroSecurityManager). // chain
methods here as necessary  //
    .buildSubject();

//the Subject.execute call will automatically bind and unbind the
Subject to the thread, before and after the method completes
(respectively):

subject.execute(new Callable() {
    //do work as the Subject here
});

The different techniques for Subject creation and thread association
are documented here: http://shiro.apache.org/subject.html

In the 'Subject.Builder' section.

HTH!

Les