Ben,
I took a look at InsecureChannelProcessor and there's no
response.sendRedirect() happening in there. It's delegating those types of
calls to the entryPoint.commence() methods. So I guess it's the
RetryWithHttpEntryPoint that I need to extend and provide my own commence()
implementation, right?
I just want to be sure I'm getting this right. When a
URI has determined to be non-secure by the ChannelSecurity component is it
delegating the task of determining whether or not to redirect to the
ChannelProcessors?
Thanks again,
Joseph
----- Original Message -----
From: Ben Alex
Sent: Monday, June 21, 2004 7:30 PM
Subject: Re: [Acegisecurity-developer] How do I avoid the IE
redirect warning dialog? > First let me say that I'm thoroughly impressed with the work you guys > have done in designing and coding the Acegi Security Framework. Thank > you (from all of us) for all that hard work. I've implemented a web > app using it but have a question regarding the ChannelProcessingFilter > and how it redirects back to HTTP. > > As I'm sure you're already aware, if IE is already in a HTTPS page, > when it receives a response.sendRedirect() to a non-secure resource, > by default it gives that dialog box "You are about to be redirected to > a non-secure page". Of course this can be turned off via a setting in > the user's browser, but we're not going to go and ask thousands of > users using IE to change this setting. Most of them can't anyways due > to IT control. > > I've seen workarounds to this where instead of a > sendRedirect(http://abc.com/non-secureURL), the server sends back a > https redirect and in that page there's a small piece of > _javascript_ that does a refresh of the browser to the non-secure URL. > > As it is right now your ChannelProcessingFilter is just doing a > simple sendRedirect(). Have you guys ran across this issue? or > should I implement my own filter which extends yours and just changes > this behavior to write a tiny little page with the _javascript_ I > mentioned to do the redirecting? > Hi Joseph I haven't run across this issue, but what you say is correct. The handlers for changing the channel being used are completely pluggable. See for example the Contacts sample application. A fragment of its XML follows: <bean id="channelDecisionManager" class="net.sf.acegisecurity.securechannel.ChannelDecisionManagerImpl"> <property name="channelProcessors"> <list> <ref bean="secureChannelProcessor"/> <ref bean="insecureChannelProcessor"/> </list> </property> </bean> <bean id="secureChannelProcessor" class="net.sf.acegisecurity.securechannel.SecureChannelProcessor"/> <bean id="insecureChannelProcessor" class="net.sf.acegisecurity.securechannel.InsecureChannelProcessor"/> So you can simply write a replacement insecureChannelProcessor to achieve your goal. Then wire it up in your application context. HTH Ben ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer |
- [Acegisecurity-developer] How do I avoid the IE redirect w... Joseph Schmoley
- Re: [Acegisecurity-developer] How do I avoid the IE r... Ben Alex
- Re: [Acegisecurity-developer] How do I avoid the ... Joseph Schmoley
- Re: [Acegisecurity-developer] How do I avoid ... Ben Alex
- Re: [Acegisecurity-developer] How do I av... Joseph Schmoley
- Re: [Acegisecurity-developer] How do... Ben Alex
- [Acegisecurity-developer] Authen... Joseph Schmoley
- Re: [Acegisecurity-developer... Ben Alex