On 1/25/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > 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?
Yeah, I noticed that too. I tried removing the FORWARD on the filter, but that didn't work either (IIRC). > > > > > 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. IMO, this works as it should. In AppFuse, things have been much easier since I quit forcing a specific port for http/https. Users sometimes forget to modify web.xml - and when they get redirected to 8080 (and their server is running on 80) - things blow up and they can't figure out why. If you choose to browse an http site with https - so be it. To get around this, we could force /**=REQUIRES_INSECURE_CHANNEL, but that seems like overkill to me. > > 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. The real question is - how many people are using this feature, let alone non-standard ports? Matt > > -- 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
