Hot answers tagged

12

One method is using something like the following in your general.php file. Using this method the config settings will take on the scheme of the request being made. I've set both the siteUrl and example environmentVariables below: <?php // Ensure our urls have the right scheme define('URI_SCHEME', ( isset($_SERVER['HTTPS'] ) ) ? "https://" : "http://" ...


5

The solution I came to was creating an Origin Certificate on Cloudflare, installing on it on my VPS, and setting the SSL setting to Full Strict. Now admin assets are loading perfectly over https. No .htaccess or Patrol plugin required. If someone knows more about why this worked and the previous approach didn't I would love to hear your thoughts. Thanks @...


5

This could be a couple things: Server config .htaccess file SSL Certificate But it sounds to me like the insecure login button means those assets are not being served over SSL. How'd you confirm the site is served over https? Craft's control panel resources are not actually in the document root so what's happening is Craft's controller (index.php) is ...


5

Try setting it as the actual siteUrl config setting, rather than a siteUrl environment variable. See here for an explanation.


5

I've already answered this question but ran into another situation that I feel merits a separate answer instead of making my first answer more complicated. In some cases, we use Cloudflare Flexible SSL. Due to the way Cloudflare does SSL, this adds support for SSL but not via a certificate on the server or via the standard SSL port so the common $_SERVER['...


5

Sorry about that guys, this issue has been fixed in Videos 1.0.20: https://dukt.net/craft/videos/updates#v1.0.20


4

The condition should be: RewriteCond %{HTTPS} !=on (You were missing the = sign.) For more info, see our help article, How do I force SSL for CP requests?


4

This seems missing from the other answers, so I feel the need to emphasize it here... Craft does not require .dev for local development. Your local URL can be anything you want, Craft does not care. There is no requirement whatsoever on using a .dev domain. That being said, it is recommended that you use a "dev-sounding" URL, in order to avoid the ...


3

By checking the code, I could find a method named getHeaders() that will return all the headers of the current request. So if you want to retrieve the content of the foo header, just use: {% set headers = craft.app.request.getHeaders() %} {% set fooHeader = headers['foo'] %}


3

There are docs for removing index.php from your URLs here: https://craftcms.com/support/remove-index.php There are also docs for enforcing SSL for all CP requests here: https://craftcms.com/support/force-ssl Note that they mention the the SSL rewrite should happen before the index.php rewrite in your .htaccess file.


3

Yea Google bought .dev a few years back and now chrome forces https on all .dev domains. I switched to using .test which has been reserved. So far, so good. https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd


3

What web server are you running? I ask because IIS will define the $_SERVER['https'] variable even if the site is being accessed via HTTP (it's value will be 'off') and Ben's answer is only checking if the $_SERVER['https'] variable is present. One solution is to add a further check that $_SERVER['https'] == 'on' Try updating this: // Ensure our urls have ...


3

Yes, you can use getRestParams() like so: $input = craft()->request->getRestParams() A bit confusing naming there, which is why it's changing to getBodyParams() in Yii 2.


3

Try using: {{ gist.gistImage.first().getUrl('gistUnit')|replace({'http': 'https'}) }}


3

The fix was to delete the content of the /cpresources folder and that did the trick.


2

We've run into this as well. I don't know if there is a better fix, but for our case, we ended up using the video url parameter and the replace filter to get around it: {% if entry.video|length %} <iframe src="{{ entry.video.url|replace("http://youtu.be/", "https://www.youtube.com/embed/")|raw }}?wmode=transparent&enablejsapi=1" width="640" height="...


2

I've never done this, but you should be able to use the cache using key parameter with the craft.request.isSecure property to do this. isSecure Whether the current request is over SSL. Something like: {% cache using key (craft.request.isSecure ? 'https': 'http') %}


2

Something like this would work: {% if craft.request.isSecure() %} {% set cacheKey = 'secure' %} {% else %} {% set cacheKey = 'insecure' %} {% endif %} {% cache using key cacheKey %} ... {% endcache %} See here for more info.


2

Once the same problem happened for me because of server caching and it may happen because of client-side cookie/cache. Sometimes, server caching will cache the entire form including CSRF token. So if there any option to use the minimal cache on the server, apply it/remove the server cache option itself. it may fix this problem. Note: This only my experience....


2

I have exactly the same issue, clearing cookies worked for me


2

Change your site url in your config file. Add a 301 redirect to your htaccess to send requests for http to https. # Redirect http to https RewriteCond %{HTTP:X-Forwarded-Proto} !=https RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] If that doesn't work for you then I suggest doing some Google searching. There are hundreds of guides on how to ...


2

Sprig will use whatever your site's base URL is set to, to construct the action URL. Ensure in Settings → Sites that the base URL is either set to an absolute path starting with https://, or if an alias or environment variable, that it is defined as an absolute path starting with https://. Also be sure to either force the www subdomain or force a naked ...


1

In example.com.nginx.ssl.conf need to insert: location / { try_files $uri/index.html $uri $uri/ /index.php?$query_string; }


1

If you are using Laravel Valet, the newest version takes care of that. You may either change the domain with valet domain test, or better: automatically secure your project it with valet secure. It's very smooth.


1

Think we figured out the root cause of this - we have a load balancer in front of our origin server and, long story short, that load balancer was communicating with our origin server via HTTP, causing the extra http redirect. Fixing that issue would be a long and arduous process so, through some infrastructure updates, we'll be moving away from using the ...


1

Craft's default setting is 'resourceBaseUrl' => '@web/cpresources'. If your site or Docker Container runs http, Craft seems to (correctly) determine the http setup. This is why it ignores your siteUrl / ROOT_SITE_URL. To fix this, either overwrite @web or manually set 'resourceBaseUrl'. Set resourceBaseUrl Explictly set 'resourceBaseUrl' => getenv('...


1

It's probable that your Site URL in your website's config is using http rather than https. Setting it to https should force the control panel assets to load appropriately. You can change this in Craft's Settings > System > General screen. If you've overriden this in your website's config setting you'll instead need to update the siteUrl setting in ...


1

It turned out not to be Craft's fault, indeed: On the server, the HTTP_X_FORWARDED_PROTO environment variable was erroneously set to https in the reverse proxy – an issue that my hosting provider had to resolve. (As a quick fix, the following line in index.php did the trick, too:) apache_setenv('HTTP_X_FORWARDED_PROTO', 'http'); Thanks to @brad-bell ...


1

I'd give Patrol plugin a try, just activate secure connections.


1

Using MediaTemple, I have this working: #FORCE HTTPS RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] <IfModule mod_rewrite.c> RewriteEngine On # Send would-be 404 requests to Craft RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !^/(favicon\....


Only top voted, non community-wiki answers of a minimum length are eligible