Shop - SCPPIO Logo should always point to :8080, not :8443


#1

If you enter the ecommerce shop using the default port :8080 (not encrypted), the whole site will render fast, until you add something to the shopping cart. Obviously, the shopping cart and checkout should be encrypted (:8443), but at any time you "Return to Shopping:, or click the top left logo, the site should return to :8080. It seems to permanently stay on :8443.


#2

The defaults for all URLs have been set to 8443. So unless a link is specified as secure=“false” within the controller, the links will be generated as https links only.

There are mutiple reasons for this (and the internet is littered with blog articles about this): https://www.siteground.com/blog/https-2017/

In general, one can say that nowadays it is not wise to run a website under anything else than ssl. If you must override it, then you can change your website or default settings: http://www.scipioerp.com/community/developer/installation-configuration/configuration/ (click on the URL tab)


#3

Even ebay uses http:// until you perform a checkout. For a fast website, you really want to avoid https:// until checkout. You can at least cache images and website content.


#4

OK. This is a big problem. If you add items to your shopping cart (:8080), then go to checkout (:8443), then go back to (:8080), the contents of your shopping cart is empty. If you go back to (:8443), the shopping cart contents returns.

The shopping cart should be consistent between (:8080) and (:8443).


#5

I used to agree with you on the performance factor, but times have changed. Nowadays the benefits of running websites on ssl only by far outweigh the cost. To name a few:

Form data on unsecure pages will throw a browser warning, even when posting against an https request: http sites will show a browser warning, even when posting against a secure request:

https://www.feistyduck.com/bulletproof-tls-newsletter/issue_24_firefox_and_chrome_start_warning_about_insecure_login_forms.html

2)Google and other search engines put a negative impact on insecure pages to “discourage” the use of it.
https://bbrmarketing.com/blog/get-serious-using-ssl-get-penalized-google/

  1. It has become significantly easier and cheaper to secure your website through services like
    https://letsencrypt.org/

There are more good reasons for it, but in all honesty, we are sticking with this as a default, as we do not recommend running a website without ssl anymore. If you want to override specific pages on your own instance of scipio, you can easily achive this by either

  1. Setting specific controller entries to secure=“false”
  2. Changing URL configuration to generate no secure urls (this is still possible, since you may want to do this when behind a loadbalancer)
  3. Updating specific links from inside the ftls. The link on the logo you mentions, happens to be stored inside the header.ftl of your themes directory

We do not recommend this for above reasons, however.


#6

About your issue with the cart: each protocol will result in its own session. This is a default on all application servers and true for us also. There are multple reasons for this, but mostly the security aspects come into mind: Going from https to keep the login “secure” is pointless if the rest of the session is in cleartext. You just open yourself up for an attacker to copy the session id and use info afterwards:


If you switch from one to the other, the one session info is lost. If you really insist, encode the jsessionId in the redirect to the http url or remove cookies entirely. But truely: you should not be using http on an ecommerce application anymore


#7

Thanks Paul. The video really cleared things up. I was also operating on 10 year old practices where you had to have an expensive load balancer to offload SSL, As usual, you guys at scipio are (again) right on.


#8

Thanks again. Having the jsessionid in the URL is quite annoying. Eventually, I’m going to ask you guys for a recommended apache or nginx config.


#9

It is indeed. In general in an environment like that, we would recommend to run (1) Scipio on http only and rely on (2) the webserver to terminate ssl for the systems via a reverse-proxy.That way the request is always ssl-secured whereas the systems communicate on http (loadbalancing wouldn’t really work without this anyway).

I think I may be able to hook you up with a few config snippets, too.