P.S. You can also avoid this problem by not using/creating a Session with the built Subject.
On Tue, Mar 13, 2012 at 7:25 PM, Les Hazlewood <[email protected]> wrote: > It is not a bug - someone (or something) is attempting to create a Session > when: > > 1. The SessionManager in use at runtime is a > ServletContainerSessionManager instance. This is the default > SessionManager implementation for a Shiro-enabled web application, and > it delegates to the Servlet container (e.g. Jetty/Tomcat) to do the > 'real' session management. > > and > > 2. The Subject instance on which subject.getSession() is being called > is not aware of an HTTP request/response pair. (In a web app, the > Shiro Filter creates WebSubject instances automatically, which are > aware of their 'source' request/response pair). > > So in your situation, subject.getSession() is being called, and the > Subject implementation (under the hood) says, > > 'Hey, SessionManager, create me a new Session please!' > > The ServletContainerSessionManager replies (with the exception): > > "I'm a web-only SessionManager, and I need a ServletRequest to do that > for you. Because you're not providing me with a request/response > pair, I can't help you!'. > > The easiest solution for this is to use the WebSubject.Builder when > your underlying SessionManager is web-only, and it should work fine. > (Shiro 'native' SessionManagers can function both with and without web > requests, but the ServletContainer-based ones cannot - they are web > only). > > HTH, > > -- > Les Hazlewood > CTO, Stormpath | http://www.stormpath.com | 888.391.5282 > twitter: @lhazlewood | http://twitter.com/lhazlewood > blog: http://leshazlewood.com > stormpath blog: http://www.stormpath.com/blog/index > > On Tue, Mar 13, 2012 at 6:08 PM, Jared Bunting > <[email protected]> wrote: >> Do you have a stack trace for this error? It seems like a bug to me. >> >> On Tue 13 Mar 2012 05:49:21 PM CDT, dan wrote: >>> Hi -- >>> >>> I am upgrading to Shiro 1.2 and have the following problem. In the code, I >>> determine the role of an arbitrary user by calling this method and then >>> doing a hasRole(...): >>> >>> public Subject getSubjectByLogin(final String login) { >>> PrincipalCollection principals = new >>> SimplePrincipalCollection(login, >>> REALM_NAME); >>> return new >>> Subject.Builder().principals(principals).buildSubject(); >>> } >>> >>> It worked fine with Shiro 1.1. With Shiro 1.2, searching through the forum, >>> I saw a similar issue and changed the method to use WebSubject: >>> >>> public Subject getSubjectByLogin(final String login) { >>> PrincipalCollection principals = new >>> SimplePrincipalCollection(login, >>> REALM_NAME); >>> final FacesContext faces = FacesContext.getCurrentInstance(); >>> >>> HttpServletResponse resp = >>> (HttpServletResponse)faces.getExternalContext().getResponse(); >>> HttpServletRequest reqs = >>> (HttpServletRequest)faces.getExternalContext().getRequest(); >>> >>> WebSubject.Builder b = new WebSubject.Builder(reqs, resp); >>> return b.principals(principals).buildSubject(); >>> } >>> >>> This worked better but it has the side effect of changing the Subject object >>> of the logged in user to the one was being checked. The effect is that any >>> subsequent click takes me to a accessDenied page because the changed subject >>> has lesser privledges. >>> >>> So... can you comment on how to retrieve the role of an arbitrary user? >>> >>> Thanks, >>> Dan >>> >>> PS. I am still wanting to implement Guice support but had to back off on >>> that until this upgrade issue was resolved! ;| >>> >>> >>> >>> -- >>> View this message in context: >>> http://shiro-user.582556.n2.nabble.com/Subject-being-changed-tp7370203p7370203.html >>> Sent from the Shiro User mailing list archive at Nabble.com.
