I've changed my APP_URL=https://example.com, I've added this into my AppServiceProvider's boot method:
/** Enable HTTPS */
if(env('REDIRECT_HTTPS')) {
$url->forceSchema('https');
}
And I've run php artisan cache:clear, php artisan view:clear and php artisan config:clear. I still can't get assets and dynamic routes to use https. Just getting the error:
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure stylesheet 'http://example.com/css/app.css'. This request has been blocked; the content must be served over HTTPS.
I know I can use secure_asset instead of asset and that should work, but I need this to be dynamic, as I still need to serve the http version of the site for now on another domain.
The asset() helper relies on a couple possibilities to determine whether to make a HTTP or HTTPS URL:
$_SERVER['HTTPS'] being on. This is Apache's way of doing things. For nginx, you can set that server param yourself in the config.
$_SERVER['HTTP_X_FORWARDED_PROTO'] being https.
If you're behind a load balancer, it's probably sending the X-Forwarded-Proto header, but Laravel doesn't trust it by default because it can be set by a malicious user in some cases. You can tell Laravel to trust this header coming from your load balancer using the TrustedProxy package. (edit: This is now built into Laravel)
See also: Symfony2: getScheme does not return 'https' (Laravel uses Symfony's getScheme() function for this)
in .env file please change the value local to production
APP_ENV=production
Related
I'm using absolute_url function defined here in my twig email template that is triggered via symfony command but the path only returns localhost/route instead of the complete URL http://abc.local/route.
download
What am I missing here ?
Solution with Symfony-5.4
Generating URLs in commands works the same as generating URLs in services. The only difference is that commands are not executed in the HTTP context. Therefore, if you generate absolute URLs, you'll get http://localhost/ as the host name instead of your real host name.
The solution is to configure the default_uri option to define the "request context" used by commands when they generate URLs:
On config/packages/routing.yaml add the URL of the real host.
# config/packages/routing.yaml
framework:
router:
# ...
default_uri: 'https://example.org/my/path/'
The default_uri option was introduced in Symfony 5.1.
For reference please see the official documentation.
https://symfony.com/doc/5.4/routing.html#generating-urls-in-commands
I'm running a laravel project behind a reversed proxy which is why I need to force the root url and scheme:
URL::forceRootUrl($proxy_url);
URL::forceScheme($proxy_schema);
I've added this to the top of my /routes/web.php and it's working fine until I run:
php artisan optimize
It caches the routes in /bootstrap/cache without the forced url and scheme, so now all my urls are pointing to the wrong root url.
I've tried to move the code to /Providers/AppServiceProvider.php (both register and boot) in order to make it take effect when caching the routes but no luck.
I have to manually delete the routes cache file in /bootstrap/cache to make my routes work again.
Have do I make it take effect when caching the routes?
Edit:
I have also tried to create a global middleware where I do the force url and schema. Again it works fine before caching the routes, but when running php artisan optimize the routes are once again incorrect.
php artisan optimize removed since laravel 5.6 (source, source2)
Using URL::forceRootUrl and URL::forceScheme seems like a work-around for working with reverse proxies. The clean solution for it would be to add a trusted proxies in your configuration. This post explains the feature in full. But it comes down to:
Use the App\Http\Middleware\TrustProxies middleware
Edit the middleware $proxies property with the IP(s) of your load balancer
protected $proxies = [
'192.168.1.1',
'192.168.1.2',
];
Remove the following code from /routes/web.php
URL::forceRootUrl($proxy_url);
URL::forceScheme($proxy_schema);
In my Symfony2 project, I send email with a link to connect to my website, like
LOGIN
When I use this template in a controller, the link is good.
LOGIN
But if I use this template for my mail in a ContainerAwareCommand with a cron, it looks like
LOGIN
It's not good. How am I suppose to do to make it work ?
You should Configure the Request Context Globally, as described in the doc How to Generate URLs from the Console:
you can redefine the parameters it uses as default values to change
the default host (localhost) and scheme (http). You can also configure
the base path if Symfony is not running in the root directory.
Note that this does not impact URLs generated via normal web requests,
since those will override the defaults.
# app/config/parameters.yml
parameters:
router.request_context.host: example.org
router.request_context.scheme: https
router.request_context.base_url: my/path
hope this help
I am running a local server on port 4567. I am trying to make it so that when my database seeds I save a reference to the home page on my site in my db. However I noticed when I run URL::to('/') in my seeds it only includes "localhost" without the port, but if I include it in my view code it comes out as "localhost:4567". Why is this? How can I fix it, if possibly, without writing if statement conditionals about what production environment I am in? Thank you.
Seed File result of URL::to('/')
http://localhost
View File result of URL::to('/')
http://localhost:4567
Either set APP_URL in env file
APP_URL=http://localhost:4567
Or set url in config/app.php
'url' => env('APP_URL', 'http://localhost:4567'),
Many internal functions and third-party libraries use the APP_URL .env var directly or via config('app.url'). The better way is to use the URL generator classes that Laravel provides, eg. the Url facade.
Even so, you'll see different results in Views versus in the CLI, or in Jobs (eg. links in emails). In the web context most of Laravel's URL generation is based on the server/request URL. For example, the url() helper calls methods in Illuminate\Routing\UrlGenerator that ultimately use Illuminate\Http\Request's URL methods.
The CLI and Queued Jobs don't have the Request object, so they have to fall back to something else. That's right, configuration.
So, even though links, redirects, and other generated URL's will function perfectly in the web, these can be "broken" (misconfigured ;) outside the HTTP request lifecycle if APP_URL isn't set in your .env, or directly in the app config as #Sachin Kumar points out.
My app/config/app.php has
'url' => 'http://dev.domain.com/something/somethingElse'
Then I have a function that can be called from the application and also from an artisan command. But URL::route('myRoute') returns different results. When called from the application it returns http://dev.domain.com/something/somethingElse/myRoute, but in the artisan command http://dev.domain.com/myRoute.
URL::to has same behaviour.
Note: I do not have any other app.php file defined for other environments that could overwrite the global one.
Any ideas why this happens ?
Thanks!
A Laravel-generated URL consists of a number of parts:
Scheme: http://, https://, etc.
Host: dev.domain.com, localhost, etc.
Base: something/somethingElse (the subdirectory on the web server)
Tail: myRoute, (the Laravel route parameters)
These parts are then concatenated to form the URL.
Ultimately, Laravel generates the URL using the $_SERVER request variables. The function prepareBaseUrl() in Symfony\Component\HttpFoundation\Request is what is ultimately used to determine the base part of the URL.
When you make a request through your web browser, the request goes to ~/public/index.php and the necessary $_SERVER variables are populated with the correct information for Laravel to populate the base part of the URL.
However, when you make the request using Artisan on the command line, the request goes to the ~/artisan script. This means that the $_SERVER variables are not populated in the same way and Laravel is not able to determine the base part of the URL; instead, it returns an empty string ''.
From what I can find, it doesn't look like there is any appetite from the Laravel team to enable the application to function out-of-the-box in a subdirectory, e.g. Bugfix: domain routing for subfolder.
I ended up working around it in the way described by #medowlock for my scripts that would be called from the command line, e.g.:
Config::get('app.url') . URL::route('route.name', ['parameter'=>'value'], false)
This concatenates the application URL set in the app/config/app.php and the relative URL route.
If you use Laravel 4.2, you can call the URL::forceRootUrl function to explicitly define what the root url of your laravel application is.
URL::forceRootUrl( Config::get('app.url') );
Calls to URL::to will use the URL define in your app config file after forcing the Root URL.
Unfortunately, this isn't available in Laravel 4.1 or Laravel 4.0