Page 1 of 1

how does the demo site setup https redirect

Posted: Sun Jun 15, 2014 6:13 am
by daniel_locious
Hi guys,

Everybody is in world cup mode but me... :cry:

I had my nginx setup to balance the request to tomcat, and it works fine on http. Now I am trying to setup the https, and found this wierd issue. My tomcat listen on 8080, 8443 and 8444, same as default on jetty evironment. However I found when I access to https://testserver:8443, tomcat replies http://testserver:8080, seems something in between redirected the request automatically.

I seached through the tomcat configure file (server.xml) just couldn't understand why this is. Also looked into broadleaf commerce code, all I found is <sec:port-mapping http="8080" https="8443"/> which in my understanding, is saying if it's secure region, and the port is 8080, then redirect to 8443.

I experienced the opposite redirection, I guess. Another thing I found is, login form, doesn't explicitely schema to https, so I could login under http protocol. Is it intend to do so?

Cheers,

Dan

Re: how does the demo site setup https redirect

Posted: Sun Jun 15, 2014 12:21 pm
by phillipuniverse
Configuring SSL/non-ssl for your URLs is all apart of Spring Security (which might help in your research). We have separated all of the Spring Security config in the file you already referenced from, applicationContext-security.xml.

Let's take a look at some of that URL configuration:

Code: Select all

<sec:intercept-url pattern="/account/wishlist/**" access="ROLE_USER" requires-channel="any" />

<!-- Specify these URLs as requiring HTTPS to encrypt user data  -->
<sec:intercept-url pattern="/register*" requires-channel="https" />
<sec:intercept-url pattern="/login*/**" requires-channel="https" />
<sec:intercept-url pattern="/account/**" access="ROLE_USER" requires-channel="https" />
<sec:intercept-url pattern="/checkout/**" requires-channel="https" />
<sec:intercept-url pattern="/null-checkout/**" requires-channel="https" />
<sec:intercept-url pattern="/null-giftcard/**" requires-channel="https" />
<sec:intercept-url pattern="/confirmation/**" requires-channel="https" />

<!-- Since the cart page is viewing as a modal, we want to allow it on any page -->
<sec:intercept-url pattern="/cart/**" requires-channel="any" />

<!-- All URLs not explicitly specified as https will be served under http -->
<sec:intercept-url pattern="/" requires-channel="http"/>
<sec:intercept-url pattern="/**" requires-channel="http"/>


Whenever there is a requires-channel, that means that all URL paths that match will have that protocol. So /register*, /login*/**, /account/** etc will all REQUIRE https, which means that if you try to load that URL from non-SSL, you will be redirected to the SSL version.

The opposite is also true. Since the URL matching goes in order, these lines at the bottom:

Code: Select all

<sec:intercept-url pattern="/" requires-channel="http"/>
<sec:intercept-url pattern="/**" requires-channel="http"/>


Mean that any URL not specified above it will FORCE non-SSL. In DemoSite terms, if you go to a category or product URL (or any other url that doesn't have requires-channel https above it) if you try to go there with https it will redirect you to http.

With your issue specifically, since you have all other URLs forcing http, if you try to visit https://testserver.com then Spring looks at the config, sees that it needs to force http, and redirects the user to http. The port mapping that you found:

Code: Select all

<sec:port-mapping http="8080" https="8443"/>


works in the opposite direction as well. If the user is on https and needs to be redirected to http, then it will use 8080.

Finally, if you're doing load balancing and have Tomcat listening on non-standard ports (meaning 8080 and 8443 instead of 80 and 443) then you will need this configuration: https://github.com/BroadleafCommerce/Br ... t-35304953. Although, that comment assumes that you are terminating SSL at your load balancer and Tomcat is just accepting http connections. I think that much if it still applies though, because you want redirects to happen correctly.