That's what it sounds like to me, but I guess I'm a bit confused. That's what I was hoping to see a stack trace.
It seems to me that, no matter what my setup, I should always be able to successfully invoke the code (Provided that SecurityUtils.getSecurityManager() returns successfully) : new Subject.Builder().buildSubject(); -Jared On Tue 13 Mar 2012 09:28:52 PM CDT, Les Hazlewood wrote: > 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.
