You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@wicket.apache.org by Michael Sparer <mi...@gmx.at> on 2007/10/24 19:14:13 UTC

Re: Acegi and Wicket-auth-roles

Hi, 

I get the same Nullpointer when calling
SecurityContextHolder.getContext().getAuthentication().getAuthorities();
(getAuthentication returns null) when I do a _refresh_ on the page which is
displayed immediately after the login (and requires authorization), which
seems weird to me ... any suggestions? 

thanks in advance

michael



Erik van Oosten (old) wrote:
> 
> Hi Ian,
> 
> Indeed, the Wicket base class from Wicket-auth-roles does keep the 'is 
> signed in' state. This is okay; it is the intention that you invalidate 
> the session upon logout. This should of course happen automatically on a 
> timeout after you close the browser.
>  
> If the browser did not keep the cookie, you should have gotten a new 
> session in which isSigned() should return false. If this is really the 
> case, then this sounds like a bug in Wicket core and not in 
> Wicket-auth-roles.
> 
> If your browser /did/ keep the cookie and brought you back to the same 
> session, you should also have gotten the security context from Acegi.
> It this is the case the problem is either (again) a Wicket bug, or a 
> problem with the session authentication store of Acegi. Please 
> investigate whether you configured the Acegi filter on all relevant URLs.
> 
> Regards,
>      Erik.
> 
> 
> Ian Godman wrote:
>> Hi
>>
>> I am trying to get Acegi (Spring Security) working with Wicket.
>>
>> It almost works except that if I close the browser and reopen the page I
>> get a null pointer exception because the
>> SecurityContextHolder.getContext().getAuthentication() is null in the
>> getRoles() method of the appSession, which is actually what I would
>> expect as the use should not be logged on because the browser was closed.
>>
>> It appears to me that Wicket-auth-roles is not noticing that the user is
>> not authenticated (its remembering the previous authentication) so checks
>> to see if they have the role required to access the page and because the
>> authentication does not exist in the security context I get
>> NullPointerException.
>>
>> Been going around this all morning, completely out of ideas.
>>
>>
>> Ian
>>
>>
>>
>>
>>
>>       ___________________________________________________________
>> Yahoo! Answers - Got a question? Someone out there knows the answer. Try
>> it
>> now.
>> http://uk.answers.yahoo.com/ 
>>   
> 
> -- 
> Erik van Oosten
> http://2008.rubyenrails.nl/
> http://www.day-to-day-stuff.blogspot.com/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Acegi-and-Wicket-auth-roles-tf4280003.html#a13388277
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Acegi and Wicket-auth-roles

Posted by Erik van Oosten <e....@grons.nl>.

Thanks for adding this to the wiki!

Regards,
    Erik.


Michael Sparer schreef:
> and _not_ vice versa. otherwise the wicket servlet looks for authorities
> that haven't been set yet.
> ... always the easy and logical things waste my time ;-)
>
>   
--
Erik van Oosten
http://2008.rubyenrails.nl/
http://day-to-day-stuff.blogspot.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Acegi and Wicket-auth-roles

Posted by Michael Sparer <mi...@gmx.at>.

Allright, I solved it. 
The error was the order of the filters in the web.xml. It is _very_
important to let the acegi filter run _before_ the wicket filter. 
e.g.
    <!-- acegi checks every request -->
    <filter-mapping>
        <filter-name>Acegi HTTP Request Security Filter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    
        <!-- each request goes through the wicket filter -->
    <filter-mapping>
      <filter-name>wicket.iPlayQuizClient</filter-name>
	  <url-pattern>/*</url-pattern>
    </filter-mapping>


and _not_ vice versa. otherwise the wicket servlet looks for authorities
that haven't been set yet.
... always the easy and logical things waste my time ;-)




Michael Sparer wrote:
> 
> Hi, 
> 
> I get the same Nullpointer when calling
> SecurityContextHolder.getContext().getAuthentication().getAuthorities();
> (getAuthentication returns null) when I do a _refresh_ on the page which
> is displayed immediately after the login (and requires authorization),
> which seems weird to me ... any suggestions? 
> 
> thanks in advance
> 
> michael
> 
> 
> 
> Erik van Oosten (old) wrote:
>> 
>> Hi Ian,
>> 
>> Indeed, the Wicket base class from Wicket-auth-roles does keep the 'is 
>> signed in' state. This is okay; it is the intention that you invalidate 
>> the session upon logout. This should of course happen automatically on a 
>> timeout after you close the browser.
>>  
>> If the browser did not keep the cookie, you should have gotten a new 
>> session in which isSigned() should return false. If this is really the 
>> case, then this sounds like a bug in Wicket core and not in 
>> Wicket-auth-roles.
>> 
>> If your browser /did/ keep the cookie and brought you back to the same 
>> session, you should also have gotten the security context from Acegi.
>> It this is the case the problem is either (again) a Wicket bug, or a 
>> problem with the session authentication store of Acegi. Please 
>> investigate whether you configured the Acegi filter on all relevant URLs.
>> 
>> Regards,
>>      Erik.
>> 
>> 
>> Ian Godman wrote:
>>> Hi
>>>
>>> I am trying to get Acegi (Spring Security) working with Wicket.
>>>
>>> It almost works except that if I close the browser and reopen the page I
>>> get a null pointer exception because the
>>> SecurityContextHolder.getContext().getAuthentication() is null in the
>>> getRoles() method of the appSession, which is actually what I would
>>> expect as the use should not be logged on because the browser was
>>> closed.
>>>
>>> It appears to me that Wicket-auth-roles is not noticing that the user is
>>> not authenticated (its remembering the previous authentication) so
>>> checks to see if they have the role required to access the page and
>>> because the authentication does not exist in the security context I get
>>> NullPointerException.
>>>
>>> Been going around this all morning, completely out of ideas.
>>>
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>>
>>>       ___________________________________________________________
>>> Yahoo! Answers - Got a question? Someone out there knows the answer. Try
>>> it
>>> now.
>>> http://uk.answers.yahoo.com/ 
>>>   
>> 
>> -- 
>> Erik van Oosten
>> http://2008.rubyenrails.nl/
>> http://www.day-to-day-stuff.blogspot.com/
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Acegi-and-Wicket-auth-roles-tf4280003.html#a13388684
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org