Losing https after redirecting from the backedn
Tagged: Prettyfaces https redirect
October 11, 2013 at 12:10 pm #25168
I’ve been using prettyfaces (2.0.4.Final) for 3 months now and I find its a really useful tool. I’m looking forward to use the rewrite as well.
Ok, let’s go to the point.
We have a webapplication running on glassfish (glassfish 3.2.1 ) with an Apache server. The Apache Server is redirecting the request from http to https.
If we don’t use pretty redirection from the back end the thing is working fine, but if we use pretty (like this “return pretty:home;”) we are losing the https in the URL.
Example: URL before redirecting from the back end ----> https://oursite.com URL after "return pretty:home;" -------------> oursite.com
And here the definition of the home page in our pretty-config:
<url-mapping id="home"> <pattern value="/" /> <view-id value="/index.xhtml" /> </url-mapping> <rewrite match="/home" substitute="/" redirect="301"/>
This is happening every time we redirect from the back end. Not just in the home page.
And that is the situation so far.
I would like to thank you in advance for your help.
Regards.October 11, 2013 at 12:40 pm #25171
Lincoln Baxter IIIKeymaster
First, I’d really like to help, and this sounds like a bug, so I think that it might be best if you could:
1. Upgrade to PrettyFaces/Rewrite 2.0.8.Final.
2. Provide a sample maven application and steps to reproduce the issue.
~LincolnOctober 11, 2013 at 2:24 pm #25172
just to clarify. Are you using Rewrite 2.0.4.Final with the rewrite-config-prettyfaces module or are you using a really old version of PrettyFaces (2.0.4)?
Sorry, for the dump question, but as PrettyFaces is now part of Rewrite, version numbers may get a bit confusing. 🙂October 14, 2013 at 3:38 am #25175
Thanks for the quick answer.
Lincoln, we are going to update to 2.0.8 and check if that solves the issue. If it doesn’t I’ll try to get back to you with the sample application and the steps to reproduce it.
Christian, I think we are using rewrite-config-prettyfaces 2.0.4, here is the definition in our pom.xml
<dependency> <groupId>org.ocpsoft.rewrite</groupId> <artifactId>rewrite-servlet</artifactId> <version>2.0.4.Final</version> </dependency> <dependency> <groupId>org.ocpsoft.rewrite</groupId> <artifactId>rewrite-config-prettyfaces</artifactId> <version>2.0.4.Final</version> </dependency>
Salva.October 14, 2013 at 4:31 am #25176
Ok, great. So you are not using an ancient version of PrettyFaces. That’s good. 🙂
Regarding your problem. You should have a look at the HTTP response headers of the redirect. AFAIK PrettyFaces only sends relative URLS (like
/new-url) and NOT absolute URLs (like
http://whatever.com/new-url). So actually I don’t think PrettyFaces can cause this issue, as relative URLs in redirects cannot change the URL schema. But I may be wrong. However, a sample app to would be very helpful.
ChristianOctober 16, 2013 at 4:51 am #25182
First of all thanks for the help.
I think I find a solution for this but I could not test it. In the end we decided to remove the prettyfaces from the part of the application where we are having the problems.
BTW my guess is that we were missing to set the navigation-rules in the faces-config.xml to make it redirect.
<navigation-case> <from-outcome>page1</from-outcome> <to-view-id>/page1.xhtml</to-view-id> <redirect /> </navigation-case>
The other components should be as follow, pretty-config.xml:
<url-mapping id="page1"> <pattern value="/page1" /> <view-id value="/page1.xhtml" /> </url-mapping>
And then from the managed bean:
Does it makes any sense to you guys?
As I said a couldn’t test it, so I just leave it for the record. 🙂
- This reply was modified 4 years, 4 months ago by Sal.
You must be logged in to reply to this topic.