I made a Swagger, and try to deploy it to Heroku.
This swagger has been made with this package swagger for laravel.
It works fine on my localhost (http://localhost:8000/api/documentation).
I tried to deploy this Swagger on Heroku. It works fine with HTTP, and failed with HTTPS.
The error, with HTTPS, is :
Mixed Content: The page at 'https://school-back.herokuapp.com/api/documentation' was loaded over HTTPS, but requested an insecure stylesheet 'http://school-back.herokuapp.com/docs/asset/swagger-ui.css?v=8db32e4681a17f1b67d7ae8ca54724eb'. This request has been blocked; the content must be served over HTTPS.
I understand the problem. My question is how to parameter the swagger, or the conf of this package, to not have this kind of problem ?
Update your APP_URL env variable to APP_URL=https://school-back.herokuapp.com. I suspect because you're not including a protocol the framework has to guess what you mean when referencing your static assets.
Related
I deployed a Laravel 9 app (with Jetstream/Livewire) to DigitalOcean using their "App" service from GitHub. Deployment was smooth and CI/CD works fine.
When viewing the application in the browser, I noticed that the assets (CSS and JS) are being served with a HTTP URL. None of the modern browsers like this (called "mixed content"). So I configured Vite (/vite.config.js) to compile the assets using HTTPS. Now they work.
However, Laravel itself insists on using HTTP when building URL's within the Blade templates (url() and route()). For instance, on the login page, the login form action is http://mywebsite.com.
I have tried:
Editing AppServiceProvider.php and adding \Illuminate\Support\Facades\URL::forceScheme('https'); to the boot() method
Setting proxies to '*' in TrustProxies middleware
Adding all of the CloudFlare IP's to the proxies property of TrustProxies middleware
Setting APP_URL and ASSET_URL to https://mywebsite.com in .env
Clearing the caches after changing the settings by php artisan optimize:clear
But none of this has helped and the forms (and other URL's) are generated under the HTTP scheme. I am guessing that the reverse proxy setup is confusing Laravel. What are the right Laravel settings to help it play nicely with DigitalOcean App service (which uses Heroku and CloudFlare? for deployment)?
Turns out, forceScheme() should be added as
\URL::forceScheme('https');
and not as
\Illuminate\Support\Facades\URL::forceScheme('https');
Because it lives in the Illuminate\Routing\UrlGenerator class. Some answer in the internets has mislead me... Don't let is mislead you!
i'm using Laravel 5 with php7.4
So i put this into header
<script src="http://10.105.2.10/js/bootstrap.min.js"></script>
And this is what they trying to get https
GET https://10.105.2.10/js/bootstrap.min.js net::ERR_CONNECTION_REFUSED
Its work well on local but when deploy to test server it's not working
And the weird thing is other page is work fine but only one page had this problem
I've got a Laravel app that's hosted on Heroku, currently in staging environment that's password protected. It's accessible via https:// but axios is making requests to http:// and causing a cors error... I've tried adding allow origin headers as middleware on the routes but that doesn't fix the error.
Is there a way to force axios to use https by default? I don't want to pass the full URL to the axios.get()
This doesn't happen on local so could it be something caused by Heroku?
There is a Pull Request on the way that will try to access http/s if the other protocol fails. So it's a matter of time now.
I think the issue is actually related to Heroku but I can't be certain.
The only thing that tells me this is that I moved to an EC2 instance via Laravel Forge and I don't have any problems.
Strangely I also had a couple of files that were being requested without www. And when viewing in browser it forced the css files to the naked domain. What's weird though is other css files loaded with www. And weren't redirected so I think it could also have been a permissions thing.
I solved the file issue by simply changing the file name and the redirect stopped so maybe an overzealous redirect. Either way it was annoying and I think I tried everything so hopefully that information helps somebody else in future.
Cheers
I have issue with oil price
which we were getting form below script/ external website link :-
But Due to SSL , we have changed link from below way
which is perfectly working on chrome browser but on other browser script not loading properly
(Have you any idea regarding this how we can resolve )
I am doing this in Wordpress
From an https website you can't include js from an http host. (Active mixed content is blocked)
If you need to include a script, host it yourself (or use a CDN provider with https)
If you need to include a data provider, you need to proxy the request :
https://you.website/get_data.js returns the content of https://the.other.website/get_data.js
I'm developing an application that will eventually need to be fully HTTPS but I'm temporarily developing locally on HTTP.
If I use URL::to_asset('path', false) locally then I'd have to go and change every instance of that to true when I switch to HTTPS.
At the moment I'm thinking a Config::get('app.https', true) as the second argument would be the easiest way around this but I was wondering whether there's a more system-wide approach for ensuring your assets follow the routes (for example if I had an application that had partial usage of HTTPS routes it would be nice if Laravel automatically worked out whether you're on a HTTPS route and returned the correct asset link).
Or is it possible to get assets to use the "//domain.tld/path/to/something" approach
instead of manually setting it through configs you could use Request::secure() to check, if the request is done over HTTPS.
reference: laravel request information
Set HTTPS 'on' or 'off' in your web server's environment. That should propagate to Laravel, and result in http: or https: URL generation.
It may be worth adding that we run our Laravel apps on Elastic Beanstalk. EB terminates SSL at the Load Balancer, so Laravel "thinks" it's HTTP, when it's not. We use redirects to ensure all traffic is HTTPS from the outside, and set HTTPS=ON in the EB Dashboard settings so that assets aren't subject to redirects.
Tested on Laravel 5x, you can do like this:
asset('path_to_file', \App::environment() == 'production')
If you're in production, it will return true and load the asset via https, while returning false in development, loading via http.
If you are using Laravel 5.3 you can just use the Laravel asset() helper function. It loads assets using the current scheme of the request (HTTP or HTTPS)
You can find more details here