On 1/24/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > Well, it works if all you do is start in http and login, but it doesn't > actually enforce the proper schemes. i.e. try hitting the root page of the > app under https and you'll see that it won't redirect you back to http. > > A typical example would be to hit the login link and get to the login page > under https, then click the "front page" link. It'll send you to the front > page under https. > > I'm also very confused about the roller.properties scheme enforcement > settings and how they fit into the whole situation. If I apply your changes > it works as I described above, but that's when our scheme enforcement > property is "false". If I set our scheme enforcement property to "true" then > things break again and I get into infinite redirect loops.
I spent a couple of hours looking at this tonight and found that the login will always work for http/https switching. However, the channelProcessFilter seems to have a bug in it where it won't read custom ports. It *will* work if you use the default 80/443 and 8080/8443. More details on the Acegi Forums: http://forum.springframework.org/showthread.php?p=48082 IMO, this isn't a show stopper because I believe that most folks will either use 80/443 or 8080/8443. On a (possibly) related note, I noticed that JRoller is using Acegi now. A couple of issues I found in the last 5 minutes: 1. Logging on from the front page with no user/pass results in a stacktrace. 2. Clicking login from my blog (which goes to https://jroller.com/login-redirect.jsp - notice "https") results in an error page on Firefox/Win XP. Matt > > -- Allen > > > On Tue, 2006-01-24 at 10:21, Matt Raible wrote: > > It worked for me on login. What ports are you using? Please provide > > the steps to reproduce and I'll try to do so. > > > > Matt > > > > On 1/24/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > I only see this partially working. I get switching from http -> https, > > > but it never switches back to http. > > > > > > -- Allen > > > > > > > > > On Mon, 2006-01-23 at 21:47, Matt Raible wrote: > > > > This seems to work - we might want to specify 80/443 and 8080/8443 as > > > > the defaults and point users to security.xml if they'd like to add > > > > others. For the most part, I don't see why the above won't work for > > > > folks, so I don't know if it's a good idea to add this in or not. > > > > > > > > Index: C:/Source/roller/web/WEB-INF/security.xml > > > > =================================================================== > > > > --- C:/Source/roller/web/WEB-INF/security.xml (revision 371815) > > > > +++ C:/Source/roller/web/WEB-INF/security.xml (working copy) > > > > @@ -12,7 +12,6 @@ > > > > PATTERN_TYPE_APACHE_ANT > > > > > > > > /**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,channelProcessingFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter > > > > </value> > > > > - <!-- Note that channelProcessingFilter before > > > > remoteUserFilter to turn on SSL switching, it's off by default --> > > > > </property> > > > > </bean> > > > > > > > > @@ -114,14 +113,30 @@ > > > > > > > > <bean id="securityEnforcementFilter" > > > > class="net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter"> > > > > <property name="filterSecurityInterceptor" > > > > ref="filterInvocationInterceptor"/> > > > > - <property name="authenticationEntryPoint" > > > > ref="authenticationProcessingFilterEntryPoint"/> > > > > + <property name="authenticationEntryPoint" > > > > ref="authenticationProcessingFilterEntryPoint"/> > > > > + <property name="portResolver" ref="portResolver"/> > > > > </bean> > > > > + > > > > + <bean id="portResolver" > > > > class="net.sf.acegisecurity.util.PortResolverImpl"> > > > > + <property name="portMapper" ref="portMapper"/> > > > > + </bean> > > > > + > > > > + <bean id="portMapper" > > > > class="net.sf.acegisecurity.util.PortMapperImpl"> > > > > + <property name="portMappings"> > > > > + <map> > > > > + <entry key="8080" value="8443"/> > > > > + <entry key="80" value="443"/> > > > > + <entry key="9080" value="9443"/> > > > > + </map> > > > > + </property> > > > > + </bean> > > > > > > > > <bean id="remoteUserFilter" > > > > class="net.sf.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter"/> > > > > > > > > <bean id="authenticationProcessingFilterEntryPoint" > > > > class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint"> > > > > <property name="loginFormUrl" value="/login.jsp"/> > > > > - <property name="forceHttps" value="false"/> > > > > + <property name="forceHttps" value="false"/> > > > > + <property name="portMapper" ref="portMapper"/> > > > > </bean> > > > > > > > > <!-- ===================== REMEMBER ME ==================== --> > > > > > > > > > > > > Hope this helps, > > > > > > > > Matt > > > > > > > > > > > > On 1/23/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > > > Matt, > > > > > > > > > > there is currently still no way to set the ports that Acegi uses for > > > > > it's scheme enforcement. i think this is something that has to be > > > > > done before we can release 2.1. > > > > > > > > > > i've tried looking at it myself and i haven't been able to get the > > > > > config elements correct for some reason. > > > > > > > > > > can you take a look at it? > > > > > > > > > > -- Allen > > > > > > > > > > > > > > > > > > > > > > >
