Unforcing Silverstripe

[Michael Gall]

Hi guys,

we are using SSL and Director::forceSSL to ensure that we have secure CC transactions, however I run into a problem after the transaction where general navigation of the site is https. Is there a way to redirect back to the unsecure site for subsequent page views?

Cheers,

Michael

--

http://wakeless.net

[Aaron Cooper]

I don't have an answer to this, but the question raises an interesting issue that I had with a custom app several years ago.

 

When the site is in https://, shouldn't there be an option to make a nav link absolute rather than relative?

 

e.g. a checkbox on the metadata tab that says something along the lines of "Make URL absolute".

 

Some apps require cross navigation between Secure and Non-secure pages. If I understand what Michael is saying, once a user goes to the secure port, they are stuck there.

 

Cheers

Aaron

[Sam Minnee]

So, are you wanting a "Director::forceNonSSL()" function? None
currently exists but it would be pretty straightforward to write one.

[Michael Gall]

Yeah, I've just written one however it doesn't end up working quite as nicely as perhaps it should because I redirect to a content managed page for our confirmation. This has client details on it so also needs to be encrypted. I'll give it a bit of "burn-in" time and let you know how it goes. I think a better way to do this would be to be able to specify secure sections of the site, perhaps with the Director rules interface.


Cheers,

Michael

--

http://wakeless.net

[Sam Minnee]

> I think a better way to do this would be to be able to specify secure
> sections of the site, perhaps with the Director rules interface.

Yeah I agree that it needs work. The other thing that is problematic
is that I believe you usually lose your session cookie when moving
from secure to insecure and vice versa.

[Matt Peel]

This is why I've always put Director::forceSSL(); in the _config.php for
a whole site - because transferring things between :80 and :443 was a
problem. Is there a particular reason you only want a part of a site to
be SSL-secured? If anything, it helps ensure credibility for the rest of
the site - I always take a good hard look at sites when I notice I'm
transferring between :80 and :443 (e.g. PayPal used to have only the
members area under SSL, the homepage etc weren't secured).

Just a thought.

[Michael Gall]

Google maps doesn't work on SSL. Or it does, but with user warnings and I'd prefer not to have those warnings.

--

http://wakeless.net

[Aaron Cooper]

> Is there a particular reason you only want a part of a site to
> be SSL-secured?

I worked for an online medical company in London that had many pages of
general info and services. There were also a number of submission forms for
various services that needed to be SSL as the content may contain medical
info.

It was an old site, and poor architecture really (Having a seperate
"submission zone" on 443 would have been better)

However, I think many ecommerce sites require both. Like Amazon.com - their
main product directory is not secured, yet their MyAccount subsections (like
tracking orders) are. Also, the header and footer navigation on https is
exactly the same as http, but all the links are absolute. (yet they are
relative on the un-secured site).

Also, including non-secure items on a secure page breaks the cert. (Like
Micheal pointed out with G maps)

Aaron

[Matt Peel]

> On Mon, 2008-06-16 at 17:31 +1200, Michael Gall wrote:
> Google maps doesn't work on SSL. Or it does, but with user warnings
> and I'd prefer not to have those warnings.

Ah fair enough - I haven't had to deal with this yet and hadn't thought
about it. Thanks :)

On Mon, 2008-06-16 at 17:36 +1200, Aaron Cooper wrote:
> I worked for an online medical company in London that had many pages of
> general info and services. There were also a number of submission forms for
> various services that needed to be SSL as the content may contain medical
> info.
>
> It was an old site, and poor architecture really (Having a seperate
> "submission zone" on 443 would have been better)

I was just meaning why not have the whole site :443 in this case? Unless you include external services that don't offer their content on :443 as Michael and you have mentioned, I can't see any downside (except for the browsing experience being slightly slower as the browser looks up/verifies the cert).

[Nicolaas Thiemen Francken]

Would it be easier to run the entire site over a secure connection?

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.3.0/1504 - Release Date: 15/06/2008
5:52 p.m.

[Matt Peel]

That was what I was asking - in this case it's not because his site
depends on external sources (e.g. Google Maps) that don't have a secure
version of their services. If that happens, users would get popups
telling them that the site needs to load secure and non-secure files,
but there also seems to be other problems that wakeless is experiencing
as well.

Matt.

[Sam Minnee]

> > Would it be easier to run the entire site over a secure connection?

Yeah, that's the approach that we have generally taken in the past,
which is why the Director::forceSSL() function is so simple. Not that
it's the best solution by any means, it was just the easiest to
implement at the time. :-P

[Sagen Creative]

It's my understanding that SSL for an entire site creates a
performance issue when scaling to serve many users, which is why most
larger companies separate encrypted from non-encrypted content.