Oh well... The approach described on my previous message below works fine
with FireFox but I found a weird issue testing it on IE6. Using IE6 I go to
the login page (or try to go to a page that requires credentials so it loads
the login page), and but when I enter my credentials and click Login it is
not directing the browser to HTTPS (it doesn't ask me to accept my local
certificate) but re-direct me back to the login screen with no error being
shown in the screen nor in the log. It looks like for some weird reason IE6
and/or Spring security don't like a full URL for j_security_check ???
Anyways... I had to re-think this solution and tried something different
that worked:
in security.xml I replaced the old line with this one:
<form-login always-use-default-target="true"
default-target-url="${default-target-url}" login-page="/login.jsp"
authentication-failure-url="/login.jsp?error=true"
login-processing-url="/j_security_check"/>
In pom.xml I set this property default-target-url as a HTTPS URL, which can
be different for each profile I have (1 local, 2 for remote servers). It is
less flexible in the sense that I need to always remember to update this
property in case my servers change but it worked for me.
If anyone want to try this approach, just remember to also modify your
pom.xml to process tag replaces in security.xml during build, since this is
something AppFuse doesn't do by default. If interested, see how here:
http://www.nabble.com/how-to-set-in-web.xml-value-from-maven2-properties--to11026773s2369.html#a18571766
Pedro Burglin
pedro_burglin wrote:
>
> I still couldn't find the optimal solution to this problem but given my
> timeframe I had to implement a quick and less flexible shortcut (i.e. a
> hardcoded hack :P) to make it work.
>
> Instead of setting the HTTP/HTTPS switch in security.xml like I wanted to
> I am setting it in few JSPs like login.jsp. Where the form action is
> "<c:url value='/j_security_check'/>", if I replace with "<c:url
> value='${newUrl}'/>", where newUrl is something like
> "https://localhost:8443/j_security_check"; I got the user switch from HTTP
> to HTTPS successfully!
>
> I am not completely hardcoding the URL, I added this code in the JSP to
> dynamically evaluate newUrl:
>
> // evaluate new HTTPS URL
> StringBuffer baseUrl = request.getRequestURL();
> baseUrl.setLength( request.getRequestURL().length() -
> request.getRequestURI().length() );
> String newUrl = baseUrl.toString().replaceFirst("http:", "https:");
> newUrl = newUrl.replaceFirst(":8080", ":8443");
>
> newUrl = newUrl + "/j_security_check";
> request.setAttribute("newUrl",newUrl);
>
> Then I will add similar code to logout.jsp to switch the user back to
> HTTP.
>
> Pedro Burglin
>
>
> pedro_burglin wrote:
>>
>> Yep, using the right package definitely helps but I am still not able to
>> make it work properly.
>>
>> I am not getting any exceptions when I start Jetty (I followed this
>> helpful post to configure Jetty to use SSL too:
>> http://markmail.org/message/nnzgq3yzbkxlvvx2#query:appfuse%20jetty%20ssl+page:1+mid:snxnys7chmfpw4ws+state:results),
>> and I am able to use the application either with HTTP and with HTTPS. The
>> problem is that it is not switching from HTTP to HTTPS like I set on
>> 'filterChainProxy'. Now I am wondering if this bean 'filterChainProxy' I
>> included in security.xml following this post
>> (http://www.nabble.com/Appfuse-2-SSL-switching-td14878223.html#a14878223)
>> is being used at all, and if there is some other place in security.xml or
>> another config file I need to change to make acegi to use it.
>>
>> So my current security.xml is exactly like the original security.xml you
>> get when you start a new AppFuse JSF project. I then added the following
>> entries. Note that I had to remove some bean references from
>> 'filterInvocationDefinitionSource' from the steps described on the post
>> mentioned above.
>>
>> The references I removed are
>> "httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor"
>> because these were giving me errors like "NoSuchBeanDefinitionException:
>> No bean named 'filterInvocationInterceptor' is defined". I suppose these
>> should work on a different flavor or version of AppFuse?
>>
>> Can anyone point what I may need to do to have the switch rules defined
>> below applied on a AppFuse JSF application?
>>
>> (Just to clarify, for testing purposes I tried to configure it to switch
>> any URL to HTTPS, so I am testing it going to the app login page with
>> HTTP and expecting it to switch to HTTPS, but no luck with it so far)
>>
>> <beans:bean id="filterChainProxy"
>> class="org.springframework.security.util.FilterChainProxy">
>> <beans:property name="filterInvocationDefinitionSource">
>> <beans:value>
>> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
>> PATTERN_TYPE_APACHE_ANT
>> /**=channelProcessingFilter
>> </beans:value>
>> </beans:property>
>> </beans:bean>
>>
>> <beans:bean id="channelProcessingFilter"
>> class="org.springframework.security.securechannel.ChannelProcessingFilter">
>> <beans:property name="channelDecisionManager"
>> ref="channelDecisionManager"/>
>> <beans:property name="filterInvocationDefinitionSource">
>> <beans:value>
>> PATTERN_TYPE_APACHE_ANT
>> /login*=REQUIRES_SECURE_CHANNEL
>> /j_security_check*=REQUIRES_SECURE_CHANNEL
>> /admin/**=REQUIRES_SECURE_CHANNEL
>> /**=REQUIRES_SECURE_CHANNEL
>> </beans:value>
>> </beans:property>
>> </beans:bean>
>>
>> <beans:bean id="channelDecisionManager"
>> class="org.springframework.security.securechannel.ChannelDecisionManagerImpl">
>> <beans:property name="channelProcessors">
>> <beans:list>
>> <beans:bean
>> class="org.springframework.security.securechannel.SecureChannelProcessor"/>
>> <beans:bean
>> class="org.springframework.security.securechannel.InsecureChannelProcessor"/>
>> </beans:list>
>> </beans:property>
>> </beans:bean>
>>
>>
>> Any help is appreciated,
>> Pedro Burglin
>>
>>
>> mraible wrote:
>>>
>>> I'd try using org.springframework.security.* instead of
>>> org.acegisecurity.*.
>>>
>>> HTH,
>>>
>>> Matt
>>>
>>> On Wed, Jul 23, 2008 at 12:33 PM, pedro_burglin
>>> <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>>
>>>> Hi All,
>>>>
>>>> I am trying to setup http/https switch for certain pages of AppFuse 2
>>>> JSF.
>>>>
>>>> I am running Tomcat 6 and I set up the SSL part of it (created the
>>>> certificate and uncommented the SSL connector). I am using default
>>>> ports
>>>> (8080 / 8443). I am now able to access the site both on ports 8080
>>>> (http)
>>>> and on 8443 (https) but I would like to setup automatic switch from
>>>> http to
>>>> https when user goes to the login screen, and back to http when he logs
>>>> off.
>>>>
>>>> I found this link describing how to do it for AppFuse with struts but I
>>>> was
>>>> unable to use it on my JSF app:
>>>>
>>>> URL:
>>>> http://www.nabble.com/Appfuse-2-SSL-switching-td14878223.html#a14878223
>>>> I follow the changes to security.xml but I get multiple
>>>> ClassNotFoundException for classes like
>>>> "org.acegisecurity.util.FilterChainProxy". Since I also had to make
>>>> minor
>>>> changes to the XML additions to conform with the schema I am not sure
>>>> if
>>>> that is the right approach anymore...
>>>>
>>>> Does anyone know how to setup AppFuse with JSF so I can specify URLs I
>>>> want
>>>> it to automatically switch to HTTPS or HTTP?
>>>>
>>>> Any help is greatly appreciated,
>>>> Pedro Burglin
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/AppFuse-2-JSF-how-to-setup-https-switch-tp18617807s2369p18617807.html
>>>> Sent from the AppFuse - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/AppFuse-2-JSF-how-to-setup-https-switch-tp18617807s2369p18839605.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
