Not that I'm aware of. Les
P.S. Happy Thanksgiving! :) On Thu, Nov 25, 2010 at 8:44 AM, Alan D. Cabrera <[email protected]> wrote: > 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! >>>>> >>> >>>
