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

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