On Wed, 2006-01-25 at 10:02, Matt Raible wrote: > > > > > > > > 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.
I strongly disagree with this one. I think it's fine if a site owner decides that they don't care about it and lets their secure/unsecure urls be interchangable, but I think by default we should strictly enforce the proper scheme for all urls. At the *very* least we should be able to support strict scheme enforcement, but currently we can't. IMO, https is serious overhead for the request/response cycle and it's entirely desireable to not have users browsing your site under https when they don't need to be. I would like to reinstate the old SchemeEnforcementFilter until we have this resolved. > > > > > 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? I do. I have lots of development and testing environments setup on my workstation that all need their own ports. With this broken I can't use https on any of them anymore. Besides, it's rediculous to not have this working. Even if most people are using the standard ports it should still be supported. -- Allen > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
