Using non-web-based sessions from within a web application's background jobs

[Thilo-Alexander Ginkel <th...@ginkel.com>]

Hi there,

I have a web application that sets up Shiro using Shiro Guice based on
a ShiroWebModule. Most of the time, Shiro is used for authenticating
and authorizing web requests. However, there is also an instance of a
Quartz Scheduler running, which executes jobs that interact with
services that perform authz checks (based on Shiro's annotations).

Based on past threads in the mailing list archive, my current attempt
to associate a principal with the current thread while the job is
being run looks like this:

PrincipalCollection principals = new SimplePrincipalCollection(new
QuartzPrincipal(), "quartz");
Subject subject = new
Subject.Builder(shiroSecurityManager).principals(principals).buildSubject();
subject.execute(new Callable<Void>() {
  @Override
  public Void call() throws Exception {
    executePrivileged(context);
    return null;
  }
});

Unfortunately, when building the Subject, Shiro complains about the
session not being web-based (which is IMHO ok as this is done from a
background job, which neither needs a permanent session, nor is any
web request involved in its execution):

java.lang.IllegalArgumentException: SessionContext must be an HTTP
compatible implementation.
	at org.apache.shiro.web.session.mgt.ServletContainerSessionManager.createSession(ServletContainerSessionManager.java:103)
~[shiro-web-1.2.0.jar:1.2.0]
	at org.apache.shiro.web.session.mgt.ServletContainerSessionManager.start(ServletContainerSessionManager.java:64)
~[shiro-web-1.2.0.jar:1.2.0]
	at org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:121)
~[shiro-core-1.2.0.jar:1.2.0]
	at org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:336)
~[shiro-core-1.2.0.jar:1.2.0]
	at org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:314)
~[shiro-core-1.2.0.jar:1.2.0]
	at org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(DefaultSubjectDAO.java:182)
~[shiro-core-1.2.0.jar:1.2.0]
	at org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(DefaultSubjectDAO.java:163)
~[shiro-core-1.2.0.jar:1.2.0]
	at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDAO.java:144)
~[shiro-core-1.2.0.jar:1.2.0]
	at org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityManager.java:383)
~[shiro-core-1.2.0.jar:1.2.0]
	at org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:350)
~[shiro-core-1.2.0.jar:1.2.0]
	at org.apache.shiro.subject.Subject$Builder.buildSubject(Subject.java:846)
~[shiro-core-1.2.0.jar:1.2.0]
	at com.example.service.cron.PrivilegedJob.execute(PrivilegedJob.java:30)
~[PrivilegedJob.class:na]
	at org.quartz.core.JobRunShell.run(JobRunShell.java:213) ~[quartz-2.1.5.jar:na]

I am obtaining shiroSecurityManager via DI, so it is probably the same
instance that also handles web requests.

Any suggestions how to resolve this issue are much appreciated!

Thanks,
Thilo

Re: Using non-web-based sessions from within a web application's background jobs

[Thilo-Alexander Ginkel <th...@ginkel.com>]

On Wed, Jun 13, 2012 at 5:27 PM, Thilo-Alexander Ginkel
<th...@ginkel.com> wrote:
> I have a web application that sets up Shiro using Shiro Guice based on
> a ShiroWebModule. Most of the time, Shiro is used for authenticating
> and authorizing web requests. However, there is also an instance of a
> Quartz Scheduler running, which executes jobs that interact with
> services that perform authz checks (based on Shiro's annotations).
> [...]
>
> Unfortunately, when building the Subject, Shiro complains about the
> session not being web-based (which is IMHO ok as this is done from a
> background job, which neither needs a permanent session, nor is any
> web request involved in its execution):
>
> java.lang.IllegalArgumentException: SessionContext must be an HTTP
> compatible implementation.

After switching over to DefaultWebSessionManager (by overriding
ShiroWebModule#bindSessionManager) everything is now working as
expected.

Thanks,
Thilo