force https

Laravel will just read and use the protocol used to access the site.

Do you use a proxy that could of sent http instead for a request? Was the asset rendered via JS or anything other than blade {{ asset() }} helper?

The most sure-fire way to get it to work everywhere, is to do it in your nginx or apache site config. Rewrite/redirect all http requests to https. It's also a lot faster than doing it in laravel since it happens before the request even hits laravel.

@Cronix Redirecting http->https won't really solve it if Laravel is seeing http as the protocol. You'll also get mixed-content warnings if resources are having to redirect to https.

@Cronix I tried to include in my vhost to rewrite all http to https I get this error: this website redirected you too many times

@bashy I don't think i have a proxy. The asset was rendered in blade directly.

However i have an image load failure with permission denied with the error: Error code: 403 You don't have access to /path port 80

Is it possible that my https is loading over port 80 being the issue?

@mushood You will need to give more info on how you're supplying https to the browser via your web server. Have you also set https on your APP_URL environment var?

note this does not answer the question of the topic starter. But maybe somebody else passing by can use this.

Use // prefix instead of full schemes.

instead of http://google.com/image.jpg 
or https://google.com/image.jpg

use //google.com/image.jpg

This way the same scheme is used as your own website. If your own website is in https the assets are also loaded via https. This only works ofcourse if the remote is supporting https. If not, you should reconsider even linking to a remote party like that.

Redirect http to https in nginx

Depending on your specific nginx config it could look something like this:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /path/to/cert-crt.crt;
    ssl_certificate_key /path/to/cert-key.key;
    #other site settings go here (e.g. ssl, logs, site root)
}

source: https://www.vultr.com/docs/redirect-http-requests-to-https-on-nginx

@m-rk That's not always a good idea. I'd much rather load external resources via https even if my site is not https. Your reply also had nothing to do with this thread really. They're not loading external resources and they would of still got the same issue if the connection came through as http.

@bashy I did the following tests on my v-host:

1. I comment out the config for 443 BUT leave 80 uncommented, my site still loads in https.

2. If i comment out the config on port 80 BUT leave 443 uncommented, the site does not load anymore.

3. If i add this in my port 80 config:

    RewriteEngine on
    RewriteCond %{SERVER_NAME} =domain.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

I get this error: This site has redirected you too many times.

I have limited access to the virtual machine, and that's all the details I have right now. Am correct to affirm that my https is loading on port 80 which makes laravel think it is in http and thus generates the URL in http instead of https? The DevOps 'engineer' tells me that everything is done properly since after adding

\URL::forceSchema('https');

The website works correctly.

@m-rk Thank you for the reply. However, Bashy is right in that it will not solve my specific case.

@mushood I don't know Apache well enough to give you a good config or htaccess fixes but you need to do some testing and show more network results.

GET to https:// domain.com shows asset http:// domain.com/assets/img/test.jpg which I've included by using {{ asset('asset/img/test.jpg') }} etc etc

To close this subject, the environment was using a load balancer: https://cloud.google.com/compute/docs/load-balancing/http/

The client and the load balancer were talking in https However, the load balancer and the vm instance where my application was were talking in http causing the above mentioned error.

So you WERE using a proxy...