Hello Ben,

I figured what is happening but I don't know how to fix it. I narrowed down the problem to the presence of an IFRAME inside the jsp view of my protected page.

If I have the IFRAME, the problem happens and I get the DEBUG messages as you have seen in my earlier message. If I don't have the IFRAME, acegi behaves as expected, requiring authentication to every call to the protected page.

The IFRAME contains a protected page itself and that seems to be affecting how acegi's IntegrationFilter is handling the Authorization object.

I need this IFRAME because I have a drop-down called "sub-group" in my form that needs to change whenever I change the selected option in another drop-down called "group" and I don't want to refresh the entire page. So, when I change the "group" drop-down, I use javascript to refresh this IFRAME so that it loads new information from the database and calls another javascript function to change the options in the drop-down "sub-group" accordingly.

My use of this IFRAME is equivalent to the technique presented here:

http://www.convert2online.com/articles/examples/8.php

Thompson

Ben Alex wrote:

Thompson Marzagao wrote:

Hi all,

I am having a problem with HTTP Session authentication where the Authentication object somehow seems like is being cached even across sessions it seems. This causes user A to be immediately successfully authenticated as user B when caling a protected URL, if user B logged in a few moments earlier. Terrible. If user A then calls the same or any other protected URL again, only then is he required to login.

Does anybody know what might be causing this?


Hi Thompson

I cannot see anything wrong with your configuration, although I recommend using FilterToBeanProxy for the Auto Integration Filter:

<filter>
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.AutoIntegrationFilter</param-value>
</init-param>
</filter>


Does the Contacts sample app behave properly in your container? We test with Tomcat 5, so I'd be a little surprised if that was the problem.

Would you please confirm you're not doing anything special with HttpSessions or threads or the ContextHolder.

For this sort of thread/session related problem, the main class to look at is HttpSessionIntegrationFilter. In your configuration you're using AutoIntegrationFilter, which automatically tries the HttpSession first and delegates to HttpSessionIntegrationFilter. For this reason I'd recommend you try using HttpSessionIntegrationFilter directly and then switching on debug level logging, seeing if that gives any clues.

If you can't resolve it using the above, please post the debug-level log for HttpSessionIntegrationFilter in particular to the list.

Thanks
Ben



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer







-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

Reply via email to