Great!! On Tue, Apr 10, 2018 at 4:29 AM, Martin Nielsen <mny...@gmail.com> wrote:
> I mailed the ICLA to secret...@apache.org this morning > > On Mon, Apr 9, 2018 at 3:50 PM, Brian Demers <brian.dem...@gmail.com> > 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 <mny...@gmail.com> 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 <brian.dem...@gmail.com> >>> 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 <mny...@gmail.com> >>>> 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, <brian.dem...@gmail.com> >>>>> 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 <mny...@gmail.com> >>>>>> 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 <mny...@gmail.com> >>>>>>> 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 :) >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>> >> >
