I mailed the ICLA to [email protected] this morning On Mon, Apr 9, 2018 at 3:50 PM, Brian Demers <[email protected]> wrote:
> Thanks!! I left a few minor comments and a pointer to the Apache icla: > https://www.apache.org/licenses/icla.pdf > > IIRC, the use of NATIVE_SESSION_MODE and/or DefaultWebSessionManager, > reverts to the non-web DefaultSessionManager when there is no web context. > > On Mon, Apr 9, 2018 at 6:17 AM, Martin Nielsen <[email protected]> wrote: > >> I created a jira issue SHIRO-646 >> <https://issues.apache.org/jira/browse/SHIRO-646> as well as a pull >> request https://github.com/apache/shiro/pull/82 >> >> The pull request contains a test and two fixes to make the test pass. >> >> A small note to something I didn't check up on: >> Calling >> DefaultWebSecurityManager.setSessionMode(DefaultWebSecurityM >> anager.NATIVE_SESSION_MODE); >> makes the error disappear. I can't invest more time in it right now, >> sorry. >> >> I hope to check up on it in a few days if no one can explain it outright, >> but trawling though all those classes has been a lengthy, albeit >> interesting learning experience :) >> >> -Martin >> >> On Fri, Apr 6, 2018 at 3:29 PM, Brian Demers <[email protected]> >> wrote: >> >>> Cool, that sounds like something we should be able to write a simple >>> test for too! >>> >>> On Fri, Apr 6, 2018 at 8:50 AM, Martin Nielsen <[email protected]> wrote: >>> >>>> Hi Brian >>>> >>>> I looked a bit further at the issue and i will create a bug report when >>>> i have the chance. The websubject created by the login method ends up >>>> having both httpservlet response and requests set to null. That seems to be >>>> a pretty straight forward error. I fixed the issue by creating a new >>>> websubject factory which creates delegatingsubjects instead of websubjects >>>> if the existing subject was itself a delegatingsubject. No second >>>> securitymanager needed, at least for now. >>>> >>>> >>>> On Thu, 5 Apr 2018, 16:22 Brian Demers, <[email protected]> wrote: >>>> >>>>> Hey Martin, >>>>> >>>>> Take a look at the few sections following: >>>>> https://shiro.apache.org/session-management.html#disabling-s >>>>> ubject-state-session-storage >>>>> Though I agree throwing an exception in this case probably isn't the >>>>> best default. >>>>> >>>>> I had a similar problem a while back and IIRC I solved it by >>>>> configuring a second SecurityManager (one configured for web access and >>>>> the >>>>> second for non-web). I had a few other differences configured as well, >>>>> but >>>>> this approach means you need to manage the lifecycle of the second >>>>> instance. >>>>> >>>>> If that first link doesn't get you what you need, think about the >>>>> second option. But either way please create a JIRA! >>>>> >>>>> >>>>> On Thu, Apr 5, 2018 at 5:49 AM, Martin Nielsen <[email protected]> >>>>> wrote: >>>>> >>>>>> Right. So i got a little further, and discovered that the problem is >>>>>> the SessionStorageEvaluator on the DefaultSubjectDAO. It is set to >>>>>> a DefaultWebSessionStorageEvaluator, seems like it should handle the >>>>>> problem with this code: >>>>>> >>>>>> //SHIRO-350: non-web subject instances can't be saved to web-only >>>>>> session managers: >>>>>> //since 1.2.1: >>>>>> if (!(subject instanceof WebSubject) && (this.sessionManager >>>>>> != null && !(this.sessionManager instanceof NativeSessionManager))) { >>>>>> return false; >>>>>> } >>>>>> >>>>>> The problem is that when i login, the DelegatingSubject i create is >>>>>> automatically changed to a WebDelegatingSubject, which means that this >>>>>> code >>>>>> is skipped. >>>>>> >>>>>> What happens is this: >>>>>> >>>>>> shiroSubject = subjectBuilder.buildSubject(); >>>>>> Builds a DelegatingSubject, which passes through the Evaluator >>>>>> without issue. >>>>>> >>>>>> shiroSubject.login(new UsernamePasswordToken(user, password)); >>>>>> Seems to have some unfriendly behavior as >>>>>> the DefaultWebSecurityManager delegates its login >>>>>> to DefaultSecurityManager, which creates a new Subject in its login >>>>>> method >>>>>> which becomes a WebDelegatingSubject thanks to the >>>>>> DefaultWebSubjectFactory >>>>>> set by the DefaultWebSecurityManager, which also >>>>>> overrides createSubjectContext() to return >>>>>> a DefaultWebSubjectContext. >>>>>> >>>>>> In short: It seems no matter what i do, a WebDelegatingSubject is >>>>>> ALWAYS created when i call the login method, causing the >>>>>> DefaultWebSessionStorageEvaluator to attempt to create a session for >>>>>> a WebDelegatingSubject which does not have a session as it was >>>>>> created from a normal DelegatingSubject. >>>>>> >>>>>> This does seem more a bug than by design, and if people shout "bug" i >>>>>> will gladly create a decent bug-report. But for now: How on earth do i >>>>>> get >>>>>> around this? >>>>>> >>>>>> >>>>>> On Thu, Apr 5, 2018 at 9:23 AM, Martin Nielsen <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi all >>>>>>> >>>>>>> I have an application which uses a WebSecurityManager in conjunction >>>>>>> with Apache Wicket. That works all well and good, but now I have >>>>>>> encountered a single issue where i need to authenticate a user through a >>>>>>> different entrance, which does not have any notion of http sessions. >>>>>>> When i >>>>>>> try to login a Subject without a session like this: >>>>>>> >>>>>>> Subject shiroSubject = null; >>>>>>> Subject.Builder subjectBuilder = new Subject.Builder(manager).sessi >>>>>>> onCreationEnabled(false); >>>>>>> shiroSubject = subjectBuilder.buildSubject(); >>>>>>> ... >>>>>>> shiroSubject.login(new UsernamePasswordToken(user, password)); >>>>>>> >>>>>>> I tried every permutation of sessionCreationEnabled >>>>>>> >>>>>>> >>>>>>> I get the following exception: >>>>>>> >>>>>>> >>>>>>> javax.security.auth.login.LoginException: >>>>>>> java.lang.IllegalArgumentException: SessionContext must be an HTTP >>>>>>> compatible implementation. >>>>>>> at org.apache.shiro.web.session.mgt.ServletContainerSessionMana >>>>>>> ger.createSession(ServletContainerSessionManager.java:103) >>>>>>> at org.apache.shiro.web.session.mgt.ServletContainerSessionMana >>>>>>> ger.start(ServletContainerSessionManager.java:64) >>>>>>> at org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsS >>>>>>> ecurityManager.java:152) >>>>>>> at org.apache.shiro.subject.support.DelegatingSubject.getSessio >>>>>>> n(DelegatingSubject.java:336) >>>>>>> at org.apache.shiro.subject.support.DelegatingSubject.getSessio >>>>>>> n(DelegatingSubject.java:312) >>>>>>> at org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(Defau >>>>>>> ltSubjectDAO.java:204) >>>>>>> at org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(Default >>>>>>> SubjectDAO.java:166) >>>>>>> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDA >>>>>>> O.java:147) >>>>>>> at org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecu >>>>>>> rityManager.java:383) >>>>>>> at org.apache.shiro.mgt.DefaultSecurityManager.createSubject(De >>>>>>> faultSecurityManager.java:350) >>>>>>> at org.apache.shiro.mgt.DefaultSecurityManager.createSubject(De >>>>>>> faultSecurityManager.java:183) >>>>>>> at org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSec >>>>>>> urityManager.java:283) >>>>>>> at org.apache.shiro.subject.support.DelegatingSubject.login(Del >>>>>>> egatingSubject.java:256) >>>>>>> >>>>>>> I then looked at WebSubject.Builder i can't create a builder without >>>>>>> a Request and Response. >>>>>>> >>>>>>> >>>>>>> So the question is: When you are using a WebSecurityManager, how do >>>>>>> you authenticate a Subject in a case where there is no Request/Response >>>>>>> available? >>>>>>> >>>>>>> The only way that I can see is to highjack the WebSecurityManager's >>>>>>> Authenticator and Authorizer and call their methods directly, completely >>>>>>> ignoring the Subject, but that feels so wrong that I am guessing that i >>>>>>> am >>>>>>> way off :) >>>>>>> >>>>>> >>>>>> >>>>> >>> >> >
