Re: [Acegisecurity-developer] How do I avoid the IE redirect warning dialog?

[Joseph Schmoley]

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 To: [EMAIL PROTECTED] Sent: Monday, June 21, 2004 7:30 PM Subject: Re: [Acegisecurity-developer] How do I avoid the IE redirect warning dialog? Joseph Schmoley wrote: > 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