Able to reload https pages without http prefix, is this normal?

[vampirehunter]

I just wanted to ask if this is the normal behaviour of the BS Oscommerce?

 

I have an SSL loaded, and it seems to be working fine

with the site url as www always via htaccess.

 

However, a problem occuring is that if you visit a https link directly, and then reload this link by going into the browser url and removing https and/or www, then the website would reload the page without https and thus unsecure.

 

is this the default behaviour of the oscommerce?

 

can anyone clarify, if there any live shops with SSL, this can be tested

 

I would like to know, as normally, a https page should always be accessible only via https.

 

[Jack_mcs]

This is normal, though not correct. You have to force ssl on pages that should have it. Here is the code for the create account and login pages.

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} "(.*)/create_account\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/login\.php"
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

[MrPhil]

Are you positive that it's actually reloading the page, and not just displaying the cached copy? If it is reloading, what is your final .htaccess code (maybe it's actually changing the http to https for you)?

 

BTW, RewriteCond AND and OR precedence are different than, say, C code. My understanding is that it goes through and does all the ORs first, and then whatever remains is ANDed. So, Jack's code checks for HTTP and (file1 OR file2).

[Jack_mcs]

That's correct. Only one of the pages can be loaded at one time so it is one or the other.

[vampirehunter]

Are you positive that it's actually reloading the page, and not just displaying the cached copy? If it is reloading, what is your final .htaccess code (maybe it's actually changing the http to https for you)?

 

BTW, RewriteCond AND and OR precedence are different than, say, C code. My understanding is that it goes through and does all the ORs first, and then whatever remains is ANDed. So, Jack's code checks for HTTP and (file1 OR file2).

Im not sure

Im just removing the https in the url and pressing enter.

The page then reloads without https.

The padlock in the browser doesn't show.

 

This happens even if im logged in as customer.

[vampirehunter]

 

This is normal, though not correct. You have to force ssl on pages that should have it. Here is the code for the create account and login pages.

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} "(.*)/create_account\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/login\.php"
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Well so far,

I've done this.

 

In the main publichtml htaccess,

Im redirecting all non www to www.

 

There's nothing else being done.

 

SSL is installed

 

I've checked the configure files and both are correct.

 

Im just trying to work out why this behavior is happening.

 

I was always under the impression that a https page should always stay https.

[vampirehunter]

 

This is normal, though not correct. You have to force ssl on pages that should have it. Here is the code for the create account and login pages.

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} "(.*)/create_account\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/login\.php"
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Would this need to be done on every page a user is logged in.

Is it required to specify each page url like above.

[vampirehunter]

 

This is normal, though not correct. You have to force ssl on pages that should have it. Here is the code for the create account and login pages.

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} "(.*)/create_account\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/login\.php"
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

 

Are you positive that it's actually reloading the page, and not just displaying the cached copy? If it is reloading, what is your final .htaccess code (maybe it's actually changing the http to https for you)?

 

BTW, RewriteCond AND and OR precedence are different than, say, C code. My understanding is that it goes through and does all the ORs first, and then whatever remains is ANDed. So, Jack's code checks for HTTP and (file1 OR file2).

 

 

well after spending 8 hours yesterday, and trying various combinations, im still nowhere at a solution.

 

here is the current htaccess

# Redirect non-www urls to www
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.mysite\.co.uk
RewriteRule (.*) http://www.mysite.co.uk/$1 [R=301,L] 

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} "(.*)/create_account\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/login\.php"
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}




# Force HTTPS for /myadmin
RewriteCond %{HTTPS} !=on
RewriteCond %{THE_REQUEST} ^[A-Z]+\s/myadmin [NC]
RewriteRule ^(myadmin) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]

For create account and login, the force SSL seems to be working, because if you remove the https, http and www, it redirects back to https only.

 

However, this doesn't solve the issue of when you are logged in and on another section such as "my account" or other page which needs to be https.

Just removing the https, or www from the browser url and reloading the page means the whole page is reloaded without https.

 

im not sure why this thing is so complicated to setup. You would think adding SSL would be simple, but its created a whole new problem that needs to be solved. I can't find any upto date instructions around here either as to what to do for this problem.

 

Seems like its a case of scouring around and hoping for the best.

 

It would seem like the only option is to manually add into htaccess all the exact pages that are https and make sure they are declared, because otherwise by default, having an SSL is not going to secure the site, especially if you can simply reload the page without the https prefix.

 

Looks like a major security flaw and coding issue.

 

The only topic i have found relating to this is here:

 

http://www.oscommerce.com/forums/topic/396398-force-ssl-on-loginphp-create-accountphp-any-page-via-htaccess/

 

Seems like I will just do that and call it a day as i'm pretty sure there will be tons of people out there thinking they have secure SSL, but if you went to their https pages and did the above like im doing, you would be able to load a https page without SSL, thus rendering SSL useless.

[vampirehunter]

That's correct. Only one of the pages can be loaded at one time so it is one or the other.

 

I took your code and did following into the main publichtml/htaccess

 

Seems like manually putting in each page that must be https works.

I'm guessing there's hundreds of people who don't realise their stores are not secure if they remove the https from the browser url?

I always assumed it was default behaviour that SSL and https once declared in the configure files would ensure no https pages can be accessed without the https prefix, but i was wrong.

 

You have to manually do it for each and every page.

 

I also noticed, when logged in as customer, the shopping cart is non HTTPS. Is that supposed to be the default also? So when logged in, your account details etc are under https, but even though you are logged in, the shopping cart is not?

# Redirect non-www urls to www
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.mysite\.co.uk
RewriteRule (.*) http://www.mysite.co.uk/$1 [R=301,L] 


RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} "(.*)/create_account\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/login\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_edit\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_history\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_history_info\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_newsletters\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_notifications\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_password\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/address_book\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/address_book_process\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/password_forgotten\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_shipping\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_shipping_address\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_success\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_payment_address\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_confirmation\.php" [OR]

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}



# Force HTTPS for /my
RewriteCond %{HTTPS} !=on
RewriteCond %{THE_REQUEST} ^[A-Z]+\s/myadmin [NC]
RewriteRule ^(myadmin) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]

[auzStar]

 @@vampirehunter

 

You can simplify the secure pages condition check with this (using wildcards to cover all options):

RewriteCond %{REQUEST_URI} ^/(login|logoff|create.*|account.*|address.*|checkout.*|password.*)\.php$

The shopping cart doesn't need to be secured, only payment and personal details.

 

cheers

[vampirehunter]

@@vampirehunter

 

You can simplify the secure pages condition check with this (using wildcards to cover all options):

RewriteCond %{REQUEST_URI} ^/(login|logoff|create.*|account.*|address.*|checkout.*|password.*)\.php$

The shopping cart doesn't need to be secured, only payment and personal details.

 

cheers

Hi

Thanks will update the htaccess

Is it normal practice though to have to force SSL on specific pages with oscommerce via htaccess?

[auzStar]

@@vampirehunter

Is it normal practice though to have to force SSL on specific pages with oscommerce via htaccess?

 

Seems so. This is what I have also had to do.

 

cheers

[MrPhil]

Is it normal practice though to have to force SSL on specific pages with oscommerce via htaccess?

 

No. Each page which developers consider to have sensitive information has "SSL" in the tep_href_link() call. Provided your configure.php files are correctly set up, this will use https in the links for those pages, and http elsewhere, if you use the store-provided links (don't type them in yourself).

 

Now, what exactly are you trying to accomplish here? If you are trying to force www. on your domain, that can be done without messing up everything else. If you are trying to force https for the entire admin side, if you neglect to type it in, that can be done. You can even force the entire site to https if you want to.

 

Right now you have a hodge-podge of stuff in your .htaccess because you have no idea what you're doing. First, clarify what you're trying to do with respect to omitting the protocol (defaults to http: in that case) when typing in a URL, whether you're forcing www. or non-www. domain name, and whether you want to force certain URI patterns to https: if you neglect to specify that explicitly. Then we can tell you the best way to accomplish this.

[vampirehunter]

No. Each page which developers consider to have sensitive information has "SSL" in the tep_href_link() call. Provided your configure.php files are correctly set up, this will use https in the links for those pages, and http elsewhere, if you use the store-provided links (don't type them in yourself).

 

Now, what exactly are you trying to accomplish here? If you are trying to force www. on your domain, that can be done without messing up everything else. If you are trying to force https for the entire admin side, if you neglect to type it in, that can be done. You can even force the entire site to https if you want to.

 

Right now you have a hodge-podge of stuff in your .htaccess because you have no idea what you're doing. First, clarify what you're trying to do with respect to omitting the protocol (defaults to http: in that case) when typing in a URL, whether you're forcing www. or non-www. domain name, and whether you want to force certain URI patterns to https: if you neglect to specify that explicitly. Then we can tell you the best way to accomplish this.

Hi thanks

 

Well there is these main things to be done.

 

1.) point the site always to www.

 

2.) use SSL and https for secure sections only, not on whole site

 

3.) prevent those secure urls from being accessed unless they have a https prefix. So user or anyone cannot access the secure pages unless they have https prefix.

The same should apply for store admin.

 

 

I have checked other commerce stores and this is standard behavior, where secure pages are always accessed with a https prefix.

 

 

The default oscommerce behavior doesn't seem to force any secure urls to always use https prefix in front.

You are able to remove prefixes and reload pages without it.

 

I might be worrying over nothing, but just trying to ensure that sensitive details are never entered in an unsecured page.

 

Forcing the https prefix would ensure safety.

[MrPhil]

Hmm. I just tried https://www.google.com, stripped off the https:// (leaving the UQS), and it was reloaded with the default http:. So this is a browser or server issue, not osCommerce's behavior. Unless the server forces https: on a page (or all pages), it appears that the server will be happy to accept http:.  In your case, if you want to make sure certain pages are https: under all circumstances, you will have to explicitly list them in .htaccess to force https: instead of http:. It might just be easier to put the whole site under SSL.

 

Now, is it worth the bother? Remember, SSL reduces the chances that someone snooping on your transmissions can read your data packets going back and forth. It does nothing for data (including caches) stored on the PC or on the server, nor will it lock out hackers from either end. If a customer wants to force http: for a sensitive page, it serves them right to have someone snoop their data. When would anyone be accessing, say, create_account.php, by typing it in on the browser address bar, and without https: for that matter, rather than using the link provided by osC?

 

You way you want both www. forced, and https: on certain pages (including all of admin), because you want to minimize your typing. Leaving aside your browser's ability to remember and offer you the full URL if you type in part of it, do you really need to be concerned about some customer deliberately bypassing security by forcing http:? As far as I would be concerned, that's their problem. For your admin work, it's certainly possible to force https: on the whole admin directory (as well as www.).

 

Note that your forcing of www. is also first forcing http:, even on sensitive pages. You need to preserve https if that's what it's coming in on. I haven't tried it, but the following has been suggested to force www. without changing the protocol (http: or https: ):

RewriteCond %{HTTP_HOST} !^www\. [NC] 

RewriteCond %{HTTPS}s ^on(s)|             

RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

See if that works for you. It will break any subdomains (add www. to them), so use with care if you have any subdomains. There are other ways to do this, so if one way doesn't work, there should be another.

[vampirehunter]

Hmm. I just tried https://www.google.com, stripped off the https:// (leaving the UQS), and it was reloaded with the default http:. So this is a browser or server issue, not osCommerce's behavior. Unless the server forces https: on a page (or all pages), it appears that the server will be happy to accept http:. In your case, if you want to make sure certain pages are https: under all circumstances, you will have to explicitly list them in .htaccess to force https: instead of http:. It might just be easier to put the whole site under SSL.

 

Now, is it worth the bother? Remember, SSL reduces the chances that someone snooping on your transmissions can read your data packets going back and forth. It does nothing for data (including caches) stored on the PC or on the server, nor will it lock out hackers from either end. If a customer wants to force http: for a sensitive page, it serves them right to have someone snoop their data. When would anyone be accessing, say, create_account.php, by typing it in on the browser address bar, and without https: for that matter, rather than using the link provided by osC?

 

You way you want both www. forced, and https: on certain pages (including all of admin), because you want to minimize your typing. Leaving aside your browser's ability to remember and offer you the full URL if you type in part of it, do you really need to be concerned about some customer deliberately bypassing security by forcing http:? As far as I would be concerned, that's their problem. For your admin work, it's certainly possible to force https: on the whole admin directory (as well as www.).

 

Note that your forcing of www. is also first forcing http:, even on sensitive pages. You need to preserve https if that's what it's coming in on. I haven't tried it, but the following has been suggested to force www. without changing the protocol (http: or https: ):

RewriteCond %{HTTP_HOST} !^www\. [NC] 

RewriteCond %{HTTPS}s ^on(s)|			 

RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

See if that works for you. It will break any subdomains (add www. to them), so use with care if you have any subdomains. There are other ways to do this, so if one way doesn't work, there should be another.

Cool thanks. Will focus on what's really necessary as it is unlikely anybody acceses the url without https by removing the prefix in url and reloading.

 

Maybe im doing overkill, but the admin area definitely is one area I prefer at least to be forced SSL, as I was getting a double login problem when htaccess password protection is turned on, but the admin mod rewrite above solves that.

[Jack_mcs]

The purpose of the code I posted to force ssl on the create account and login pages is to prevent the details of those pages from being transmitted in a non-secure way. It may not be a problem on your site but many purchased templates include links to those pages that don't use ssl. So if such a link was on your site and a customer clicked on it to login, they would transmit their login unencrypted. If you don't have such a link, then forcing the ssl on those pages may not matter in your case, though I would add them just in case since you may add a link at some point, or it may be in an addon, and that would cause the security hole.

[vampirehunter]

The purpose of the code I posted to force ssl on the create account and login pages is to prevent the details of those pages from being transmitted in a non-secure way. It may not be a problem on your site but many purchased templates include links to those pages that don't use ssl. So if such a link was on your site and a customer clicked on it to login, they would transmit their login unencrypted. If you don't have such a link, then forcing the ssl on those pages may not matter in your case, though I would add them just in case since you may add a link at some point, or it may be in an addon, and that would cause the security hole.

 

thanks

so whats your opinion on the current status if I was to leave the admin section and the front end section as it is?

 

So just a non www to www redirect with this code here

RewriteCond %{HTTP_HOST} !^www\. [NC] 

RewriteCond %{HTTPS}s ^on(s)|             

RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

So  at the moment it is possible for someone to reload a https page by removing the https and www.

 

Since most people are going to go the URL direct via the website links and not by typing in, I guess the extra force SSL could be a bonus.

[Jack_mcs]

It is unlikely a customer would click in the url and switch to http. As mentioned, that code is mainly for badly formed links. Although I guess an argument could be made that hackers will sometimes create accounts since it gives them a little more access to the site. And if they can then use an http connection on some pages, they might be able to gather information they shouldn't. I doubt they would go that far but a few lines can prevent it so why not use them?

 

For the admin, if you wake up in a haze and login to your admin and forget to use https, then your username and password are transmitted unencrypted. Why take that chance? In my opinion, the admin should be forced to use ssl.

[vampirehunter]

It is unlikely a customer would click in the url and switch to http. As mentioned, that code is mainly for badly formed links. Although I guess an argument could be made that hackers will sometimes create accounts since it gives them a little more access to the site. And if they can then use an http connection on some pages, they might be able to gather information they shouldn't. I doubt they would go that far but a few lines can prevent it so why not use them?

 

For the admin, if you wake up in a haze and login to your admin and forget to use https, then your username and password are transmitted unencrypted. Why take that chance? In my opinion, the admin should be forced to use ssl.

 

Cool thanks, Yes! thats my worry, that i may log into the admin without https and send password unencrypted!

I will definitely secure the admin side, thats super important out of everything.

[MrPhil]

The code I provided was just to force www. without accidentally changing https: to http:. If in addition you want to make sure certain files or directories are always done in https: (even if typed in manually), you need to add additional code to check for specific URIs and use of http:, and redirect to https:. Needless to say, your configure.php (and tep_href_link calls) should be set up to to provide proper links (with www,. and with https: wherever security is needed). This extra code in the .htaccess is just to make sure, if someone has manually typed in a link without https:.

 

If you want to put the entire admin under https: (a good idea), you can force https: (SSL) unconditionally in the admin .htaccess. Any http: (non-SSL) would be redirected (301) to https:. On the customer-facing side, you can force https: on specific listed pages, in case someone typed in an address without https:. Given that Google is "encouraging" entire sites to be https:, it may be easier to simply make everything https:, and unconditionally redirect http: to https:, and be done with it. Of course, there is a price: additional processing time on both ends of the connection.

[vampirehunter]

The code I provided was just to force www. without accidentally changing https: to http:. If in addition you want to make sure certain files or directories are always done in https: (even if typed in manually), you need to add additional code to check for specific URIs and use of http:, and redirect to https:. Needless to say, your configure.php (and tep_href_link calls) should be set up to to provide proper links (with www,. and with https: wherever security is needed). This extra code in the .htaccess is just to make sure, if someone has manually typed in a link without https:.

 

If you want to put the entire admin under https: (a good idea), you can force https: (SSL) unconditionally in the admin .htaccess. Any http: (non-SSL) would be redirected (301) to https:. On the customer-facing side, you can force https: on specific listed pages, in case someone typed in an address without https:. Given that Google is "encouraging" entire sites to be https:, it may be easier to simply make everything https:, and unconditionally redirect http: to https:, and be done with it. Of course, there is a price: additional processing time on both ends of the connection.

 

hi thanks

 

in the admin .htaccess file,

ive tried to force SSL with the previous code Jack mentioned, but it doesn't seem to work.

 

What does work is this code here which is specifically targeting the admin directory.

# Force HTTPS for /myadmin
RewriteCond %{HTTPS} !=on
RewriteCond %{THE_REQUEST} ^[A-Z]+\s/myadmin [NC]
RewriteRule ^(myadmin) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]

[MrPhil]

This feeding us little bits and pieces of your .htaccess isn't helping us to diagnose the problem(s). So please post at least the entire section of your .htaccess file(s) that deal with 1) forcing www for everyone, 2) SSL for myadmin/, and 3) SSL for selected customer-side pages. This will take three sections of code, and if you're not careful, they can interact with each other and break something. The myadmin/ SSL force is best and easiest in that section's own .htaccess file, while the other two belong in the top level .htaccess. We need to see everything. Tell us what is working and what isn't. Of course, obscure any sensitive information.

[vampirehunter]

This feeding us little bits and pieces of your .htaccess isn't helping us to diagnose the problem(s). So please post at least the entire section of your .htaccess file(s) that deal with 1) forcing www for everyone, 2) SSL for myadmin/, and 3) SSL for selected customer-side pages. This will take three sections of code, and if you're not careful, they can interact with each other and break something. The myadmin/ SSL force is best and easiest in that section's own .htaccess file, while the other two belong in the top level .htaccess. We need to see everything. Tell us what is working and what isn't. Of course, obscure any sensitive information.

this is whats in the htaccess file in the root.

 

Seems to work fine.

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.mysite\.co.uk
RewriteRule (.*) http://www.mysite.co.uk/$1 [R=301,L] 

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} "(.*)/create_account\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/login\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_edit\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_history\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_history_info\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_newsletters\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_notifications\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/account_password\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/address_book\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/address_book_process\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/password_forgotten\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_shipping\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_shipping_address\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_success\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_payment_address\.php" [OR]
RewriteCond %{REQUEST_URI} "(.*)/checkout_confirmation\.php" [OR]

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]


# Force HTTPS for /myadmin
RewriteCond %{HTTPS} !=on
RewriteCond %{THE_REQUEST} ^[A-Z]+\s/myadmin [NC]
RewriteRule ^(myadmin) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]

Also, wanted to know, whats the difference / benefit of your version of the non www to www redirect code here which you mentioned before:

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC] 
RewriteCond %{HTTPS}s ^on(s)|             
RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

and this one im currently using which was recommended by others.

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.mysite\.co.uk
RewriteRule (.*) http://www.mysite.co.uk/$1 [R=301,L] 

[MrPhil]

I would put the /myadmin force HTTPS into /myadmin/.htaccess, so you don't need to test THE_REQUEST in the shop root, but that's my taste for doing things that way.

 

Regarding the two versions of the force-www code, your (second) version appears to be not only adding www. to the domain, but also (when that's done) forcing the protocol to http! Then you need to go back and check those selected REQUEST_URIs for non-https and fix them. My (first) version preserves the http or https protocol of the original URL. If it's important to you to fix users who have removed "https" and let the browser default to "http", you may have those fixes in there anyway, but still, it's a wasted round-trip between the server and browser to update the URL (code 301).

 

As a minor nit, my version just checks if the domain starts with www., while yours checks the entire domain (and you should add an escape for the last dot:  co\.uk).