Hi, Everyone,
As you can see from the message stack I am testing Acegi security https
channel switching. I got a problem with SchemeEnforcementFilter. The
request.getServletPath returned empty string for
'/roller-ui/login-redirect.rol'. This is actually a bugs on IBM WebSphere
since V6.1. I fixed this bugs by setting
'com.ibm.ws.webcontainer.removetrailingservletpathslash' to 'true' for web
container custom properties.
However, it still doesn't work. No error message, something was running hard
in the background and then it got stalled there.
I then did the following test to see how it works just on Acegi itself. I
make following changes:
1. Take out SchemeEnforcementFilter from Roller application
2. Set 'forceHttps' to 'true' in security.xml so we got
<bean id="authenticationProcessingFilterEntryPoint"
class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">
3. Set SSL switching in security.xml
<!-- ===================== SSL SWITCHING ==================== -->
<bean id="channelProcessingFilter"
class="org.acegisecurity.securechannel.ChannelProcessingFilter">
<property name="channelDecisionManager" ref="channelDecisionManager"/>
<property name="filterInvocationDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/roller_j_security_check=REQUIRES_SECURE_CHANNEL
/roller-ui/login-redirect.jsp=REQUIRES_SECURE_CHANNEL
/roller-ui/login-redirect.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/login.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/register.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/register!save.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/profile.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/profile!save.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/admin/userAdmin.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/admin/createUser.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/admin/createUser!save.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/authoring/userdata=REQUIRES_SECURE_CHANNEL
/roller-ui/authoring/membersInvite.rol=REQUIRES_SECURE_CHANNEL
/roller-ui/authoring/membersInvite!save.rol=REQUIRES_SECURE_CHANNEL
/**=REQUIRES_INSECURE_CHANNEL
</value>
</property>
</bean>
<property name="loginFormUrl" value="/roller-ui/login.rol"/>
<property name="forceHttps" value="true"/>
</bean>
Now I got error message directly on browser when I was starting the application:
Status Code 500
Message javax.servlet.ServletException Filter [securityFilter]: could not be
initialized
Type
Exception Roller????????
I took out the line 'CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
' and I started the application, but I got the following error message on
browser when I click on 'Login' link:
Status Code 404
Message javax.servlet.ServletException: SRVE0190E: File not found:
/WEB-INF/jsps/tiles/tiles-simplepage.jsp
Type
Exception ??????????
And the URL address on browser is:
http://localhost/blog/WEB-INF/jsps/tiles/tiles-simplepage.jsp
So what's wrong? I would appreciate if some one could shed some light on this.
The following are my further questions:
1. I did not see anyhwhere in Acegi security for us to specify the path of
certificate store. This is kind of strange. In a serious production
environment, I would use Verisign certificate, and I need specify the path of
the certificate for Acegi security. Can some one explain about this?
2. I found that WebSphere form based security constraints doesn't guard Struts
2 action, but it does guard Struts 1.x action. The reason I believe is that
Struts 2 is filter instead of servlet. I believe that WebSphere form based
login invoked login form through a servlet filter at the bottom of the filter
stack. So that with Struts 2 filter at above, the http request got forwarded
to the action without even touching the web container's security filter. So it
seems J2EE declarative security is not able to guard Struts 2 action. What's
your opinion?
Thank you very much.
David
--- On Sat, 6/13/09, (David) Ming Xia <[email protected]> wrote:
> From: (David) Ming Xia <[email protected]>
> Subject: Re: Problem in switching to HTTPS channel
> To: [email protected]
> Date: Saturday, June 13, 2009, 12:06 AM
>
> Hi, Greg.
>
> Thank you so much for your help. With the clue
> you provided I moved forward a little bit. The
> following is what I got so far.
>
> In Roller 4.0.1, the switching between http and
> https channels was implemented with
> org.apache.roller.weblogger.ui.core.filters.SchemeEnforcementFilter.
> SchemeEnforcementFilter takes four parameters, and the
> following are what I have in my roller-custom.properties.
>
> -----------------------------------------------
> # Added this line to provide https channel
> securelogin.http.port=9080 <-- I added this
> securelogin.https.port=9443 <-- I added this
> # Enables HTTPS for login page only
> securelogin.enabled=true <-- I change
> this to 'true'
> # Enable scheme enforcement?
> # Scheme enforcement ensures that specific URLs are viewed
> only via HTTPS
> schemeenforcement.enabled=true <-- I change this
> to 'true'
> -----------------------------------------------
>
> Also, I have to add some url for https
> --------------------------------------------------------
> schemeenforcement.https.urls=/roller_j_security_check,\
> /roller-ui/login-redirect.jsp,\
> /roller-ui/login-redirect.rol,\ <-- I
> added this
> --------------------------------------------------------
>
>
> However, it still doesn't work. The reason is that in
>
> req.getServletPath() return empty string for
> 'http://9080/blog/roller-ui/login-redirect.rol', so the
> process could not find a match for switching channel.
>
>
> So why req.getServletPath() return empty string for
> '/roller-ui/login-redirect.rol'? I am using WebSphere
> 7.0.3. Will it return '/roller-ui/login-redirect.rol'
> in Tomcat? I don't know.
>
> But overall, I feel this is not good. Switching
> between http and https channels should by implemented in
> service layer and should be handled by web container.
> By Java EE declarative security standard, we only need to
> specify user data constraints in web.xml. Now
> SchemeEnforcementFilter moved service layer code to
> application layer. Moreover, SchemeEnforcementFilter
> doesn't implement Spring's interface, so it doesn't work
> with Spring container. That means that it doesn't work
> with any standard. This make it too hard to
> maintain. Actually in my case, with the clue from you
> I would really get lost.
>
> I learned Roller will be moved to CMA in 4.1. I
> believe that is a right move.
>
>
> Any ideas or advices? Appreciate.
>
>
> Thank you very much.
>
> David
>
>
> --- On Fri, 6/12/09, [email protected]
> <[email protected]>
> wrote:
>
> > From: [email protected]
> <[email protected]>
> > Subject: Re: Problem in switching to HTTPS channel
> > To: [email protected]
> > Cc: "Mailing List Apache Roller Developer" <[email protected]>,
> "Mailing List Apache Roller User" <[email protected]>
> > Date: Friday, June 12, 2009, 7:44 AM
> > Hello,
> >
> > What you could try and do is add
> > "securelogin.https.port=9443" (as it
> > looks like you are using a non standard port) to
> either the
> >
> > roller.properties or your custom
> roller-custom.properties
> > file.
> >
> > Make sure also that the https is switched on also via
> the
> > roller.properties schemeenforcement.enabled=true and
> > securelogin.enabled=true properties.
> >
> >
> > Cheers Greg
> >
> >
> >
> >
> >
> > "(David) Ming Xia" <[email protected]>
> >
> > 11/06/2009 16:06
> > Please respond to
> > [email protected]
> >
> >
> > To
> > Mailing List Apache Roller User <[email protected]>,
> > Mailing List
> > Apache Roller Developer <[email protected]>
> > cc
> >
> > Subject
> > Problem in switching to HTTPS channel
> >
> >
> >
> >
> >
> >
> > Hi, Everyone.
> >
> > I could not set up switching to HTTPS channel for
> > login. I added
> > couple of line into security.xml as illustrated in
> the
> > following sample
> > code. I started the application and tried to login
> at
> >
> > https://localhost:9443/blog/roller-ui/login.rol.
> > The login page was not
> > load up.
> >
> >
> > I would appreciate if some one could give some
> > advices. Do I need to
> > something in addition to change security.xml?
> >
> >
> >
> > Thank you for your help.
> >
> > David
> >
> > <!-- ===================== SSL SWITCHING
> > ==================== -->
> > <bean id="channelProcessingFilter"
> >
> class="org.acegisecurity.securechannel.ChannelProcessingFilter">
> >
> > <property name="channelDecisionManager"
> > ref="channelDecisionManager"/>
> > <property
> name="filterInvocationDefinitionSource">
> > <value>
> > CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
> > PATTERN_TYPE_APACHE_ANT
> > /roller_j_security_check=REQUIRES_SECURE_CHANNEL
> > /roller-ui/login.rol=REQUIRES_SECURE_CHANNEL
> > /roller-ui/login-redirect.rol=REQUIRES_SECURE_CHANNEL
>
> > /**=REQUIRES_INSECURE_CHANNEL
> > </value>
> > </property>
> > </bean>
> > <bean id="channelDecisionManager"
> >
> class="org.acegisecurity.securechannel.ChannelDecisionManagerImpl">
> >
> > <property name="channelProcessors">
> > <list>
> > <bean
> >
> class="org.acegisecurity.securechannel.SecureChannelProcessor"/>
> >
> > <bean
> >
> class="org.acegisecurity.securechannel.InsecureChannelProcessor"/>
> >
> > </list>
> > </property>
> > </bean>
> >
> >
> > Share our environment commitment - conserve resources
> and
> > contribute to the reduction of CO2 emissions by not
> printing
> > the email unless absolutely necessary to do so.
> >
> > Any opinions expressed are those of the author, not
> Ricoh
> > UK Ltd. This communication does not constitute either
> offer
> > or acceptance of any contractually binding agreement.
> Such
> > offer or acceptance must be communicated in writing.
> It is
> > the responsibility of the recipient to ensure this
> email and
> > attachments are free from computer viruses before use
> and
> > the sender accepts no responsibility or liability for
> any
> > such computer viruses.
> >
> > Ricoh UK Ltd. may monitor the content of emails sent
> and
> > received via its network for the purpose of ensuring
> > compliance with its policies and procedures. This
> > communication contains information, which may be
> > confidential or privileged. The information is
> intended
> > solely for the use of the individual or entity named
> above.
> > If you are not the intended recipient, be aware that
> any
> > disclosure, copying, distribution or use of the
> contents of
> > this information is prohibited. If you have received
> this
> > communication in error, please notify the sender
> immediately
> > by return email with a copy to [email protected]
> > . Please contact us on +44 (0) 208 261 4000 if you
> need
> > assistance.
> >
> > Registered in England No: 473236
> > VAT No: GB524161280
>
