On Tue, 2006-01-24 at 22:39, Matt Raible wrote: > 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
well ... at least that proves that I am not crazy. strangely though, I found that the scheme enforcement doesn't even work properly on the standard ports if you set this ... "/**=REQUIRES_INSECURE_CHANNEL". when i have that configured, any time i access a *.do url the scheme enforcement filter actually redirects me to one of our tiles jsps which causes an error. my guess is that the port resolver is being a little too smart? > > IMO, this isn't a show stopper because I believe that most folks will > either use 80/443 or 8080/8443. sort of, but even with our current config it's not setup to properly force all urls back to http except for the ones we list. i.e. someone can browse anything under /page/* in https mode, and i think that is a show stopper. as far as only supporting 80/443 and 8080/8443 ... i can live with that in the short term, but if that is not going to be fixed fairly quickly then i think that's a problem. -- Allen > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
