7
Yes, the cookies are still susceptible to being intercepted. The full set of cookies for matching domains is transmitted by the browser with each page request to that domain, even if the original cookies were set using HTTPS/SSL and the current page is HTTP.
One way around this is by setting the "secure" flag on cookies you set. Any cookies set with the "...
5
After a lot of research and experimenting, I think I found a solution:
# Force non-SSL on these URLs
<IfModule mod_rewrite.c>
RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond $1 !^(account|system|admin\.php) [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{...
4
In your templates you can wrap any custom fields that might contain a non-https embed code with Low Replace, finding and replacing any non-https embed sources.
For example:
{exp:low_replace
find="http://www.youtube.com/embed"
replace="https://www.youtube.com/embed"
}
{your_custom_field}
{/exp:low_replace}
Low Replace will allow you to ...
4
If it’s just the search/filters that aren’t working, Playa uses Ajax to apply those things, which goes through your Site URL, not your themes folder.
If you don’t want to set your main site URL to use SSL, you can give Playa an alternate URL to use by opening up system/expressionengine/config/config.php and adding this:
$config['playa_site_index'] = "https:...
4
This isn't really an issue with your htaccess. You need to look at using a simple EE config bootstrap file such as this one to automatically set $config['theme_folder_url'] as either HTTP or HTTPS depending on whether the current request is served over HTTPS.
In the most basic form, you could probably just add this to your config.php file:
if (empty($...
4
It turns out this error was caused by a misconfiguration of the SSL certificate at the web host's end.
After getting the error on Exp:resso Store pages using https, I tested a page load of the home page (a non Store page) and got the same error. I concluded it wasn't an Exp:resso Store specific issue.
I eliminated htaccess as the source of the error by ...
4
This is always a themes folder and protocol issue, I've found. You mentioned this:
$env_config['cp_url'] = $env_config['base_url'] . '/admin.php';
What are you parameters for various $env_config array entries? Make sure that array is using https for that URL, and also your themes folder must also be behind SSL.
Update
Hey, so are you forcing SSL for all ...
3
The answer to getting the fieldtypes all under SSL is to make sure the fieldframe settings are set to https in the fieldtype path.
utilities -> extensions manager -> fieldframe -> settings
.htaccess forces ssl by the below:
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
So to recap, converting an ...
3
You can try making the requests "schemeless"...
Instead of http://www.example.com/styles/ngen_file_field.css or https://www.example.com/styles/ngen_file_field.css simply edit to:
//www.example.com/styles/ngen_file_field.css
This will cause the resources to inherit the scheme of the page in which they are loaded.
3
Correct, just make the jQuery settings in the extension area to be a relative protocol:
//ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js
3
I've run into similar issues in the past, and honestly I gave up on htaccess in the end as I never could get it to work exactly as I intended.
A much easier solution I found was using an add on to force the redirect instead, doing it this way I gained direct control of pages needed redirecting in templates instead.
I used an addon called Force SSL, http://...
3
Try changing
$assign_to_config['site_url'] = 'http://www.mydomain.com/nl/';
to
$assign_to_config['site_url'] = '//www.mydomain.com/nl/';
we haven't done with Store before, but had to use it in other areas of sites we've done, so that the page will properly load as SSL. The process is called 'protocol-relative'. We were having a slew of SSL issues, ...
3
Is https://secure.domainname.com the actual place where EE is installed? You'll need to install it in this 'secure' subdirectory and ensure that all paths within the system are correctly pointing to this location on the server.
3
The two chunks of code you require are:
# Redirect certain site pages to SSL and vice-versa
RewriteCond %{REQUEST_URI} !(extranet|themes|images|assets)
RewriteCond %{QUERY_STRING} !^(ACT=.*)$ [NC]
RewriteCond %{HTTPS} on
RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [R=301,NC,L]
RewriteCond %{REQUEST_URI} (extranet)
RewriteCond %{HTTPS} !=on
#...
3
One possible culprit - if you have Store installed, and have the Require SSL connection for checkout and order tags setting enabled, it would redirect every time you use Store tags on your site over an unencrypted connection.
That might explain why it's only happening on some pages.
3
I'm having the same issue, even though I've set PayFlow Pro to Test mode. I'm surprised any non PHP experienced developer can figure this out. I only did after digging through the code and dumping the responses at several points in the checkout process. It also does not let you use a test CC number. For example 411111111111 is a common test number that all ...
3
Take a look at this: http://kevinthompson.info/blog/2011/03/04/completely-remove-index-php-from-expressionengine-urls.html
I just recently discovered that solution and it's working great on our ecommerce website running with CartThrob and certain pages with https.
3
This is a hard coded requirement in Store. We do not allow credit card details to be submitted over an unsecure (HTTP) connection, period. If we had a setting to disable this, it would be far too easy to forget to re-enable it when you move to production (or every time you push to production if you're using multiple environments). Then aside from breaking ...
2
Having gone round in circles for the best part of a day the issue was caused by a painfully simple issue.
My .httaccess file was in the wrong place. Following best practice advise I have moved my system folder above the web root and have the .htaccess file at that level.
Instead the .htaccess file should have been placed in the web root. As soon as I ...
2
Try changing the $config['uri_protocol'] setting in config.php, as I suggested in this thread:
$config['uri_protocol'] = 'PATH_INFO';
In that thread there are also a few other suggestions to try for the rewrite line:
RewriteRule ^(.*)$ index.php/$1 [L]
RewriteRule ^(.*)$ /index.php?/$1 [L]
RewriteRule ^(.*)$ index.php?/$1 [L]
RewriteRule . index.php [L]
...
2
Let me start off by saying I fully support not allowing even test transactions with an on-site gateway (even the dummy gateway) to be processed over HTTP as it is a security risk to you and your customers if you forgot to enable HTTPS/SSL before the site goes live.
If you are on a local environment and you can not enable HTTPS for various reasons there is ...
2
Really good question. I suppose it could open you up to session sidejacking.
There's a couple of potential solutions I can think of without doing any research or prototyping.
If the website is managed by a business, you could make your HTACCESS file only allow access to the control panel for certain IP addresses (yours and their offices). Alongside this, ...
2
EE does not have any built-in link constructors that directly handle single sites spanning multiple domains / protocols / ports. So, to your question: EE doesn't understand that part of your site lives in HTTP, and part lives in HTTPS.
You may want to just use hand-entered URLs. For the home page, instead of using {path=''}, use literally: http://domain.com/...
2
Just throwing it out there but I've used this module before and it only requires a small tag in templates you want to serve via https.
http://devot-ee.com/add-ons/dm-force-ssl
2
Firstly I think you should rename admin.php to something else, in line with the Post-Installation Best Practices which can be read at http://ellislab.com/expressionengine/user-guide/installation/best_practices.html
I would go for a sub-folder, and rename it something obscure like /badgers/index.php
In turn, this would make your htaccess file easier because ...
2
Just make sure your site url and all of your url paths in your admin > general configuration are https:// and also go to your content > file > file upload preferences and make sure that the url path there is https://. Also if you are hard coding the urls in your html head when attaching assets like css and js make sure those are https:// as well.
2
It's also worth noting that using protocol relative ( //domain.com ) will work in most situations. This allows you to not have to hardcode a protocol specific url. Helpful when you're using the same code on a live HTTPS site as well as a local, HTTP site.
2
This was a silly oversight after a long week of coding. Upon login the website redirected with a prefix of "www" where the rest of the site does not use this.
Fixed with WWW resolve in .htaccess
2
First thing to ask is, do you really need to? Your links could just be protocol relative:
{stash:item_link}//example.com{/stash:item_link}
If that's not the issue then you could create a global prefix in your config using Stash's config variable stash_var_prefix:
$config['stash_var_prefix'] = isset($_SERVER['HTTPS'] ) ? 'ssl:' : 'nonssl:';
(Note that a ...
2
Just remove the protocol from the Default base URL in system settings > URL and Path Settings, so you have:
//yourdomain.com/
instead of
http://yourdomain.com/
Only top voted, non community-wiki answers of a minimum length are eligible
