You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Allen Gilliland <Al...@Sun.COM> on 2006/01/23 23:14:47 UTC
new Acegi port switching code
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
Re: new Acegi port switching code
Posted by Allen Gilliland <Al...@Sun.COM>.
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 <Al...@sun.com> 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 <Al...@sun.com> 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
Re: new Acegi port switching code
Posted by Matt Raible <mr...@gmail.com>.
On 1/25/06, Allen Gilliland <Al...@sun.com> wrote:
> On Tue, 2006-01-24 at 22:39, Matt Raible wrote:
> > On 1/24/06, Allen Gilliland <Al...@sun.com> 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 <Al...@sun.com> 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 <Al...@sun.com> 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>
Re: new Acegi port switching code
Posted by Allen Gilliland <Al...@Sun.COM>.
On Tue, 2006-01-24 at 22:39, Matt Raible wrote:
> On 1/24/06, Allen Gilliland <Al...@sun.com> 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 <Al...@sun.com> 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 <Al...@sun.com> 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
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
Re: new Acegi port switching code
Posted by Matt Raible <mr...@gmail.com>.
On 1/24/06, Allen Gilliland <Al...@sun.com> 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 <Al...@sun.com> 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 <Al...@sun.com> 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
> > > > >
> > > > >
> > > > >
> > >
> > >
>
>
Re: new Acegi port switching code
Posted by Allen Gilliland <Al...@Sun.COM>.
Alright, well I've this again and I still can't get it to work, so unless someone else can tackle this then I think the only alternative is to bring back the old SchemeEnforcementFilter and not use Acegi's scheme switching.
-- Allen
On Tue, 2006-01-24 at 10:55, Allen Gilliland 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.
>
> -- 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 <Al...@sun.com> 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 <Al...@sun.com> 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
> > > > >
> > > > >
> > > > >
> > >
> > >
>
Re: new Acegi port switching code
Posted by Matt Raible <mr...@gmail.com>.
I'll attempt to fix this tonight.
Matt
On 1/24/06, Allen Gilliland <Al...@sun.com> 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.
>
> -- 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 <Al...@sun.com> 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 <Al...@sun.com> 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
> > > > >
> > > > >
> > > > >
> > >
> > >
>
>
Re: new Acegi port switching code
Posted by Allen Gilliland <Al...@Sun.COM>.
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.
-- 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 <Al...@sun.com> 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 <Al...@sun.com> 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
> > > >
> > > >
> > > >
> >
> >
Re: new Acegi port switching code
Posted by Matt Raible <mr...@gmail.com>.
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 <Al...@sun.com> 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 <Al...@sun.com> 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
> > >
> > >
> > >
>
>
Re: new Acegi port switching code
Posted by Allen Gilliland <Al...@Sun.COM>.
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 <Al...@sun.com> 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
> >
> >
> >
Re: new Acegi port switching code
Posted by Matt Raible <mr...@gmail.com>.
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 <Al...@sun.com> 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
>
>
>
Re: new Acegi port switching code
Posted by Matt Raible <mr...@gmail.com>.
I'll try to look at this tonight.
Matt
On 1/23/06, Allen Gilliland <Al...@sun.com> 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
>
>
>