Has a Jira issue been filed on this? I am interested in watching since I am concerned about this as well.
Regards, Alan On Nov 16, 2010, at 3:22 PM, Kalle Korhonen wrote: > On Tue, Nov 16, 2010 at 12:03 PM, Erik Beeson <[email protected]> wrote: >> I was looking into trying to implement a stateless session cookie approach >> and was getting a little lost with where to hook into Shiro. If someone >> could offer some pointers, I'd be happy to hack away at it. >> Maybe another option would be to put Stateless Session Filter in front of >> Shiro configured to use http sessions? > > Look into Shiro's native session support - you could use both of these > together with your own custom native sessions. However, I don't see > this as relevant to the session creation discussion. (JEE) sessions > are the best thing going for JEE environments, problems arise only > when you abuse the system by carelessly creating them and not keeping > them lightweight. > > Kalle > > >> On Tue, Nov 16, 2010 at 11:13 AM, Kalle Korhonen >> <[email protected]> wrote: >>> >>> For scalability, it's critical that session creation is delayed as >>> long as possible. Also, automatic session creation on permission >>> denied creates an easy attack vector for denial of service. Agree with >>> Les that a generic url rewriting would be difficult to achieve but an >>> alternative, cookie-based approach that people who care about this >>> could turn on at will should work just fine. Please open an issue, >>> I'll be happy to work on it since I need it myself at some point. >>> >>> Kalle >>> >>> >>> On Tue, Nov 16, 2010 at 10:35 AM, Les Hazlewood <[email protected]> >>> wrote: >>>> Yes, this is because Shiro will save a request by putting it in the >>>> session and there is no way currently to turn off this feature. >>>> Creating URL-rewriting logic to ensure this works cleanly in any >>>> request scenario just hasn't been worth the pain. Not to mention such >>>> a feature is very implementation specific: if you URL re-write when >>>> directing to the login page, you have to ensure all of that data is >>>> encoded again when the login page is submitted - how this works is >>>> very different across UI technologies (JSF, vs JSP vs Wicket vs, etc). >>>> >>>> This could be done as a cookie as well I suppose, but it hasn't been >>>> worth it when most people don't care about a session being created. >>>> If you'd like to see this feature implemented with a cookie instead of >>>> the session, please open a Jira issue as a feature request. >>>> >>>> The other thing to realize is that if a user authenticates >>>> successfully, there will be a session created at that time to hold on >>>> to the user's principals and authentication state. In other words, >>>> you're going to have a session created _anyway_. The only time this >>>> wouldn't happen is if the user doesn't login after they're redirected >>>> to the login page, at which point the session will expire and that >>>> orphan will be cleaned by the session manager. Usually this is a >>>> negligible case and not worth the effort to circumvent it. >>>> >>>> The only way to change this is to subclass the existing authc filter >>>> and override the onAccessDenied method implementation. This method >>>> has the logic that calls the 'saveRequestAndRedirectToLogin' method. >>>> Assuming you've kept the 'authc' filter an instance of >>>> FormAuthenticatinoFilter, look at its 'onAccessDenied' method source >>>> code for ideas in your own implementation. >>>> >>>> HTH, >>>> >>>> Les >>>> >>>> On Mon, Nov 15, 2010 at 11:01 PM, Nassos A. Michas >>>> <[email protected]> wrote: >>>>> Hello, >>>>> >>>>> I am protecting a webapp with Shiro (not using Shiro's native >>>>> sessions). The webapp is protected from "/" with a simple shiro.ini such >>>>> as: >>>>> >>>>> [main] >>>>> authc.loginUrl = /login/index.action >>>>> authc.successUrl = /home/index.action >>>>> >>>>> [urls] >>>>> /login/** = anon >>>>> /images/** = anon >>>>> /scripts/** = anon >>>>> /css/** = anon >>>>> /** = authc >>>>> >>>>> When a non-authenticated user is trying to access "/" is correctly >>>>> redirected to the login page however, an http session is automatically >>>>> created at this point by Shiro. >>>>> 1/ Would it be possible to avoid this and only have a session being >>>>> created when my own application logic requests to do so? >>>>> 2/ Is this maybe a result of Shiro wanting to save the originally >>>>> requested URL and if yes, would it be possible to instruct Shiro to >>>>> perform >>>>> some kind of URL rewriting instead of creating a session? >>>>> 3/ Can I turn completely off the saveRequest functionality through >>>>> shiro.ini? >>>>> >>>>> >>>>> thanks! >>>> >> >>
