Return-Path: X-Original-To: apmail-shiro-user-archive@www.apache.org Delivered-To: apmail-shiro-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 427A176DC for ; Thu, 17 Nov 2011 12:07:52 +0000 (UTC) Received: (qmail 78252 invoked by uid 500); 17 Nov 2011 12:07:52 -0000 Delivered-To: apmail-shiro-user-archive@shiro.apache.org Received: (qmail 78217 invoked by uid 500); 17 Nov 2011 12:07:51 -0000 Mailing-List: contact user-help@shiro.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@shiro.apache.org Delivered-To: mailing list user@shiro.apache.org Received: (qmail 78209 invoked by uid 99); 17 Nov 2011 12:07:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2011 12:07:51 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bengt.rodehav@gmail.com designates 209.85.161.173 as permitted sender) Received: from [209.85.161.173] (HELO mail-gx0-f173.google.com) (209.85.161.173) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2011 12:07:46 +0000 Received: by ggnr4 with SMTP id r4so1126215ggn.32 for ; Thu, 17 Nov 2011 04:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=q4k8kpcc2rGy/5R501QeJlBCkRQVI6r+a+I9zr5IXvo=; b=jYjTB5z1tu75WdpreoHQxOCsrMwIPtRdIV09tEm+aoQzwDrxWMX23vWka4N2Iws5GU pPPAMTaJ0aJCxtNlKCyAimEbWpeceCVB78trXvrVmTVcEowteduyvZ6OcE/tkdWnUr6p 7rKCwJJ+Sm8eIn94BNTZ4FuFVgKMOefRGkJow= MIME-Version: 1.0 Received: by 10.50.140.1 with SMTP id rc1mr44964028igb.25.1321531644380; Thu, 17 Nov 2011 04:07:24 -0800 (PST) Sender: bengt.rodehav@gmail.com Received: by 10.68.58.197 with HTTP; Thu, 17 Nov 2011 04:07:24 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Nov 2011 13:07:24 +0100 X-Google-Sender-Auth: ly1L43uFs8oLBYG-KSrI_exMT9o Message-ID: Subject: Re: Check if a user is authenticated without prolonging the session timeout From: Bengt Rodehav To: user@shiro.apache.org Content-Type: multipart/alternative; boundary=e89a8f923a9c39055904b1ed109c --e89a8f923a9c39055904b1ed109c Content-Type: text/plain; charset=ISO-8859-1 Les, I'm really interested about your suggestion to use Shiro's native session for my use case. I just didn't understand how I could do that. Can you elaborate on you thoughts a bit? /Bengt 2011/11/11 Bengt Rodehav > Les, > > I couldn't see how I could disable the servlet container's default > updating of the lastAccessedTime. The way I understood it this was not > being done by Shiro but by Jetty (in my case). How would you suggest that I > solve something like this? > > This is what I wanted to accomplish: > > I want to provide a URL ("checkLogin") that can be called without the > lastAccessedTime being updated. The use case is to allow the web browser to > poll the server in order to check whether the session has been terminated. > If it has been terminated then a login dialog would automatically appear. > With the default behaviour, every call to the "checkLogin" URL would update > the lastAccessedTime and the session would never time out which would > defeat the purpose of calling the "checkLogin". > > The way I interpreted the implementation of "updateSessionLastAccessTime" > was that it ensured that the lastAccessedTime would be updated even if > Shiro's native session were used instead of the web session. I want the > right opposite: I want to be able to prevent the lastAccessedTime to be > updated for certain URL's and I can't see how I can prevent the servlet > container from doing that. > > How can I solve this by using Shiro's native sessions? > > /Bengt > > > 2011/11/11 Les Hazlewood > >> Hi Bengt, >> >> Why go through all of that - why not use Shiro's native session >> support (which I assume would give you the results you want)? >> >> Les >> >> P.S. the 'updateSessionLastAccessTime' was added to support Shiro's >> native session needs in a web environment. It ensures sessions behave >> correctly in a web environment (at least according to what the Servlet >> spec implies). >> >> On Fri, Nov 11, 2011 at 5:01 AM, Bengt Rodehav wrote: >> > Manoj, >> > This is what I ended up doing: >> > The session timeout is handled by the underlying servlet container >> (Jetty in >> > my case) not by Shiro. The code you pointed me to is only used when >> Shiro >> > takes care of the session handling (not in a servlet context). >> > Unfortunately there is no way to set the lastAccessedTime in a servlet >> > container. The API only includes a getter. Therefore, I don't see any >> way of >> > stopping Jetty from updating the lastAccessedTime. I therefore disable >> the >> > standard session timeout (by setting it to -1). I then implement my own >> > session timeout. >> > I created my own subclass from IniShiroFilter and made an override of >> the >> > method "updateSessionLastAccessTime". I create my own session attribute >> for >> > storing the lastUsed time. In my "updateSessionLastAccessTime" I update >> that >> > attribute unless the request path is my special path ("checkLogin" that >> > should be called without updating lastUsed). >> > In that method I also check if the session should expire (I have a >> > configurable timeout for this). Unless the request path was either of >> > "login" or "logout", I end the session if the timeout has expired. >> > This solution seems to work fine although I think I've had to "roll my >> own" >> > a bit too much. Perhaps functionality like this could make it into >> Shiro? I >> > think the usecase should be useful for others as well. >> > /Bengt >> > >> > 2011/11/10 Bengt Rodehav >> >> >> >> OK - thanks Manoj, >> >> I'll take a deeper look in the code. >> >> /Bengt >> >> >> >> 2011/11/9 Manoj Khangaonkar >> >>> >> >>> Hi Bengt, >> >>> >> >>> The doFilterInternal method of AbstractShiroFilter starts the chain of >> >>> code that >> >>> extracts the sessionid from the request, locates the session, creates >> >>> the WebDelegatingSubject >> >>> whose session is touched. >> >>> >> >>> To get the behaviour you need, you might need to override some of this >> >>> code >> >>> >> >>> Manoj >> >>> >> >>> On Wed, Nov 9, 2011 at 12:50 AM, Bengt Rodehav >> wrote: >> >>> > Hello Manoj, >> >>> > I use my own subclass of FormAuthenticationFilter. I've changed the >> >>> > behaviour of onAccessDenied() so that a 401 is returned since I do >> not >> >>> > want >> >>> > a redirect to a login URL. It's an Ajax application so I don't want >> a >> >>> > page >> >>> > reload. This seems to work. >> >>> > My first idea was to just have a special GET Url >> >>> > (.../session/checkLogin) >> >>> > that the client would call. I assume that the web browser will send >> the >> >>> > session cookie (like it always does). On the server side I'm not >> clear >> >>> > of >> >>> > what exactly happens. However, since there is a last used property >> on >> >>> > the >> >>> > sesssion and I have set the session timeout, I assumed that all >> calls >> >>> > within >> >>> > a session (determined from the session cookie) would "automagically" >> >>> > update >> >>> > the last used timestamp. Not sure if this is Shiro functionality or >> >>> > general >> >>> > Jetty functionality (Jetty is used for the OSGi http service that >> I'm >> >>> > using). >> >>> > It's not clear to me how I can tell (Shiro or Jetty?) that this >> >>> > particular >> >>> > call should not "count". You're saying that >> subject.isAuthenticated() >> >>> > does >> >>> > not touch the session but I would guess that >> >>> > calling SecurityUtils.getSubject() to get the subject needs the >> session >> >>> > to >> >>> > work. >> >>> > When exactly is the last used property updated? >> >>> > BTW, I have a "login" method (POST .../session/login) that looks >> >>> > something >> >>> > like this: >> >>> > String username = theRequest.getParameter("j_username"); >> >>> > String password = theRequest.getParameter("j_password"); >> >>> > LoginStatus status = getStatus(); >> >>> > if (!getStatus().isAuthenticated()) { >> >>> > UsernamePasswordToken token = new >> UsernamePasswordToken(username, >> >>> > password); >> >>> > Subject currentUser = SecurityUtils.getSubject(); >> >>> > try { >> >>> > currentUser.login(token); >> >>> > status = new LoginStatus(currentUser.isAuthenticated(), >> >>> > currentUser.getPrincipal().toString(), currentUser >> >>> > .getPrincipal().toString()); >> >>> > HttpSession session = theRequest.getSession(); >> >>> > if (session != null) { >> >>> > >> session.setMaxInactiveInterval(mService.getSessionTimeout()); >> >>> > } >> >>> > } catch (AuthenticationException e) { >> >>> > status = new LoginStatus(false, null, null); >> >>> > } >> >>> > } >> >>> > Thus I set the session timeout on the HttpSession after a successful >> >>> > login. >> >>> > /Bengt >> >>> > >> >>> > 2011/11/8 Manoj Khangaonkar >> >>> >> >> >>> >> Hi Bengt, >> >>> >> >> >>> >> How do you plan on doing checkLogin ? >> >>> >> >> >>> >> If you use subject.isAuthenticated() , it does not touch the >> session. >> >>> >> >> >>> >> If you use an authenticationFilter like the >> FormAuthenticationFilter, >> >>> >> it can detect that the session has timed out >> >>> >> and redirect the request to a login url >> >>> >> >> >>> >> Manoj >> >>> >> >> >>> >> >> >>> >> On Tue, Nov 8, 2011 at 11:59 AM, Bengt Rodehav >> >>> >> wrote: >> >>> >> > Seems like I've been bombarding this list lately. I'm quite new >> to >> >>> >> > Shiro >> >>> >> > which is why I ask all these silly questions. Must say that I'm >> very >> >>> >> > pleased >> >>> >> > so far. Shiro has turned out to be much easier to use then Spring >> >>> >> > Acegi >> >>> >> > that >> >>> >> > I have been using in the past. >> >>> >> > Anyway, I'm using Shiro 1.1 to handle authentication for an OSGi >> >>> >> > based >> >>> >> > web >> >>> >> > application using the http service in Apache Karaf. >> >>> >> > Currently my web application will return status 401 when trying >> to >> >>> >> > access >> >>> >> > resources that requires an authenticated user in case the session >> >>> >> > does >> >>> >> > not >> >>> >> > contain an authenticated user. I would like to enhance the web >> >>> >> > application >> >>> >> > so that the client (the browser) can periodically (e g once a >> minut) >> >>> >> > can >> >>> >> > check whether a user is still logged in. That way, if a user >> leaves >> >>> >> > the >> >>> >> > application for a while, I can display a login dialog so that the >> >>> >> > user >> >>> >> > can >> >>> >> > clearly see that s/he has been logged out. >> >>> >> > The problem is that if the client calls my "checkLogin" method in >> >>> >> > the >> >>> >> > context of the current session once a minute then the session >> will >> >>> >> > never >> >>> >> > time out since the last used timestamp will be updated on each >> call. >> >>> >> > Is >> >>> >> > there a best practice to accomplish this? I'm not sure if it's >> >>> >> > possible >> >>> >> > to >> >>> >> > make a call "outside" of the session. I was thinking about saving >> >>> >> > the >> >>> >> > last >> >>> >> > used timestamp in another session attribute and then restore the >> >>> >> > real >> >>> >> > last >> >>> >> > used timestamp from my special attribute after invoking my >> >>> >> > "checkLogin" >> >>> >> > method. Not sure if that would work and thought it might be wise >> to >> >>> >> > ask >> >>> >> > if >> >>> >> > anyone has done something similar before. >> >>> >> > /Bengt >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> http://khangaonkar.blogspot.com/ >> >>> > >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> http://khangaonkar.blogspot.com/ >> > > --e89a8f923a9c39055904b1ed109c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Les,

I'm really interested about your suggestion to = use Shiro's native session for my use case. I just didn't understan= d how I could do that. Can you elaborate on you thoughts a bit?

/Bengt

2011/11/11 Bengt Ro= dehav <bengt@rode= hav.com>
Les,

I couldn't see how I could disable the servlet = container's default updating of the lastAccessedTime. The way I underst= ood it this was not being done by Shiro but by Jetty (in my case). How woul= d you suggest that I solve something like this?

This is what I wanted to accomplish:

I want to provide a URL ("checkLogin") that can be called = without the lastAccessedTime being updated. The use case is to allow the we= b browser to poll the server in order to check whether the session has been= terminated. If it has been terminated then a login dialog would automatica= lly appear. With the default behaviour, every call to the "checkLogin&= quot; URL would update the lastAccessedTime and the session would never tim= e out which would defeat the purpose of calling the "checkLogin".=

The way I interpreted the implementation of "updateSessionLastAccessTime" was that it ensured that the lastAcces= sedTime would be updated even if Shiro's native session were used inste= ad of the web session. I want the right opposite: I want to be able to prev= ent the lastAccessedTime to be updated for certain URL's and I can'= t see how I can prevent the servlet container from doing that.

How can I solve this by using Shiro'= s native sessions?

/Bengt


2011/11/11 Les Hazlewood= <lhazlewood@apache.org>
Hi Bengt,

Why go through all of that - why not use Shiro's native session
support (which I assume would give you the results you want)?

Les

P.S. the 'updateSessionLastAccessTime' =A0was added to support Shir= o's
native session needs in a web environment. =A0It ensures sessions behave correctly in a web environment (at least according to what the Servlet
spec implies).

On Fri, Nov 11, 2011 at 5:01 AM, Bengt Rodehav <bengt@rodehav.com> wrote:
> Manoj,
> This is what I ended up doing:
> The session timeout is handled by the underlying servlet container (Je= tty in
> my case) not by Shiro. The code you pointed me to is only used when Sh= iro
> takes care of the session handling (not in a servlet context).
> Unfortunately there is no way to set the lastAccessedTime in a servlet=
> container. The API only includes a getter. Therefore, I don't see = any way of
> stopping Jetty from updating the lastAccessedTime. I therefore disable= the
> standard session timeout (by setting it to -1). I then implement my ow= n
> session timeout.
> I created my own subclass from=A0IniShiroFilter and made an override o= f the
> method "updateSessionLastAccessTime". I create my own sessio= n attribute for
> storing the lastUsed time. In my=A0"updateSessionLastAccessTime&q= uot; I update that
> attribute unless the request path is my special path ("checkLogin= " that
> should be called without updating lastUsed).
> In that method I also check if the session should expire (I have a
> configurable timeout for this). Unless the request path was either of<= br> > "login" or "logout", I end the session if the time= out has expired.
> This solution seems to work fine although I think I've had to &quo= t;roll my own"
> a bit too much. Perhaps functionality like this could make it into Shi= ro? I
> think the usecase should be useful for others as well.
> /Bengt
>
> 2011/11/10 Bengt Rodehav <bengt@rodehav.com>
>>
>> OK - thanks Manoj,
>> I'll take a deeper look in the code.
>> /Bengt
>>
>> 2011/11/9 Manoj Khangaonkar <khangaonkar@gmail.com>
>>>
>>> Hi Bengt,
>>>
>>> The doFilterInternal method of AbstractShiroFilter starts the = chain of
>>> code that
>>> extracts the sessionid from the request, locates the session, = creates
>>> the WebDelegatingSubject
>>> whose session is touched.
>>>
>>> To get the behaviour you need, you might need to override some= of this
>>> code
>>>
>>> Manoj
>>>
>>> On Wed, Nov 9, 2011 at 12:50 AM, Bengt Rodehav <bengt@rodehav.com> wrote= :
>>> > Hello Manoj,
>>> > I use my own subclass of FormAuthenticationFilter. I'= ve changed the
>>> > behaviour of onAccessDenied() so that a 401 is returned s= ince I do not
>>> > want
>>> > a redirect to a login URL. It's an Ajax application s= o I don't want a
>>> > page
>>> > reload. This seems to work.
>>> > My first idea was to just have a special GET Url
>>> > (.../session/checkLogin)
>>> > that the client would call. I assume that the web browser= will send the
>>> > session cookie (like it always does). On the server side = I'm not clear
>>> > of
>>> > what exactly happens. However, since there is a last used= property on
>>> > the
>>> > sesssion and I have set the session timeout, I assumed th= at all calls
>>> > within
>>> > a session (determined from the session cookie) would &quo= t;automagically"
>>> > update
>>> > the last used timestamp. Not sure if this is Shiro functi= onality or
>>> > general
>>> > Jetty functionality (Jetty is used for the OSGi http serv= ice that I'm
>>> > using).
>>> > It's not clear to me how I can tell (Shiro or Jetty?)= that this
>>> > particular
>>> > call should not "count". You're saying that= subject.isAuthenticated()
>>> > does
>>> > not touch the session but I would guess that
>>> > calling=A0SecurityUtils.getSubject() to get the subject n= eeds the session
>>> > to
>>> > work.
>>> > When exactly is the last used property updated?
>>> > BTW, I have a "login" method (POST .../session/= login) that looks
>>> > something
>>> > like this:
>>> > =A0 =A0 String username =3D theRequest.getParameter("= ;j_username");
>>> > =A0 =A0 String password =3D theRequest.getParameter("= ;j_password");
>>> > =A0 =A0 LoginStatus status =3D getStatus();
>>> > =A0 =A0 if (!getStatus().isAuthenticated()) {
>>> > =A0 =A0 =A0 UsernamePasswordToken token =3D new UsernameP= asswordToken(username,
>>> > password);
>>> > =A0 =A0 =A0 Subject currentUser =3D SecurityUtils.getSubj= ect();
>>> > =A0 =A0 =A0 try {
>>> > =A0 =A0 =A0 =A0 currentUser.login(token);
>>> > =A0 =A0 =A0 =A0 status =3D new LoginStatus(currentUser.is= Authenticated(),
>>> > currentUser.getPrincipal().toString(), currentUser
>>> > =A0 =A0 =A0 =A0 =A0 =A0 .getPrincipal().toString());
>>> > =A0 =A0 =A0 =A0 HttpSession session =3D theRequest.getSes= sion();
>>> > =A0 =A0 =A0 =A0 if (session !=3D null) {
>>> > =A0 =A0 =A0 =A0 =A0 session.setMaxInactiveInterval(mServi= ce.getSessionTimeout());
>>> > =A0 =A0 =A0 =A0 }
>>> > =A0 =A0 =A0 } catch (AuthenticationException e) {
>>> > =A0 =A0 =A0 =A0 status =3D new LoginStatus(false, null, n= ull);
>>> > =A0 =A0 =A0 }
>>> > =A0 =A0 }
>>> > Thus I set the session timeout on the HttpSession after a= successful
>>> > login.
>>> > /Bengt
>>> >
>>> > 2011/11/8 Manoj Khangaonkar <khangaonkar@gmail.com>
>>> >>
>>> >> Hi Bengt,
>>> >>
>>> >> How do you plan on doing checkLogin ?
>>> >>
>>> >> If you use subject.isAuthenticated() , it does not to= uch the session.
>>> >>
>>> >> If you use an authenticationFilter like the FormAuthe= nticationFilter,
>>> >> it can detect that the session has timed out
>>> >> and redirect the request to a login url
>>> >>
>>> >> Manoj
>>> >>
>>> >>
>>> >> On Tue, Nov 8, 2011 at 11:59 AM, Bengt Rodehav <bengt@rodehav.com&= gt;
>>> >> wrote:
>>> >> > Seems like I've been bombarding this list la= tely. I'm quite new to
>>> >> > Shiro
>>> >> > which is why I ask all these silly questions. Mu= st say that I'm very
>>> >> > pleased
>>> >> > so far. Shiro has turned out to be much easier t= o use then Spring
>>> >> > Acegi
>>> >> > that
>>> >> > I have been using in the past.
>>> >> > Anyway, I'm using Shiro 1.1 to handle authen= tication for an OSGi
>>> >> > based
>>> >> > web
>>> >> > application using the http service in Apache Kar= af.
>>> >> > Currently my web application will return status = 401 when trying to
>>> >> > access
>>> >> > resources that requires an authenticated user in= case the session
>>> >> > does
>>> >> > not
>>> >> > contain an authenticated user. I would like to e= nhance the web
>>> >> > application
>>> >> > so that the client (the browser) can periodicall= y (e g once a minut)
>>> >> > can
>>> >> > check whether a user is still logged in. That wa= y, if a user leaves
>>> >> > the
>>> >> > application for a while, I can display a login d= ialog so that the
>>> >> > user
>>> >> > can
>>> >> > clearly see that s/he has been logged out.
>>> >> > The problem is that if the client calls my "= ;checkLogin" method in
>>> >> > the
>>> >> > context of the current session once a minute the= n the session will
>>> >> > never
>>> >> > time out since the last used timestamp will be u= pdated on each call.
>>> >> > Is
>>> >> > there a best practice to accomplish this? I'= m not sure if it's
>>> >> > possible
>>> >> > to
>>> >> > make a call "outside" of the session. = I was thinking about saving
>>> >> > the
>>> >> > last
>>> >> > used timestamp in another session attribute and = then restore the
>>> >> > real
>>> >> > last
>>> >> > used timestamp from my special attribute after i= nvoking my
>>> >> > "checkLogin"
>>> >> > method. Not sure if that would work and thought = it might be wise to
>>> >> > ask
>>> >> > if
>>> >> > anyone has done something similar before.
>>> >> > /Bengt
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> http://khangaonkar.blogspot.com/
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> http://khangaonkar.blogspot.com/


--e89a8f923a9c39055904b1ed109c--