File upload over https fails signature verification

[danilogiacomi]

Fille uploads doesn't work over https, whereas it works perfectly over http

Set up livewire file upload, then use https (e.g. with ngrok) the upload fails with the request to

Request URL: https://XYZ.ngrok.io/livewire/upload-file?expires=1593877850&signature=0c0b334969966e642854a730fdb78accd3c7332648291fc2449530f15cea7035
Request Method: POST
Status Code: 401 Unauthorized

Following the flow with the debugger the problem arises, in the vendor/livewire/livewire/src/Controllers/FileUploadHandler.php, in the handle method.

In particular in the

abort_unless(request()->hasValidSignature(), 401); line.

Commenting it out works around the problem (the uploads works) but of course is not optimal,

Context

• Livewire version: 1.3.0
• Laravel version: 7.10.0
• Browser: [Firefox, Vivaldi]

[selfeky]

I have the same problem!
@danilogiacomi did you find a solution?

[danilogiacomi]

I have the same problem!
@danilogiacomi did you find a solution?

No, at the moment I've commented that line out, but that's not a solution at all...

[dennisvandalen]

@danilogiacomi @selfeky

This is because the traffic is proxied. You can set the trusted proxy in the TrustProxies middleware as per the Laravel docs.

The simplest way is to trust all proxies if you don't know them:

protected $proxies = '*';

If you're behind Cloudflare or some kind of load balancer this also applies.

[divoto]

It doesn't work when you have Reverse proxy. No matter what header i put. Any other options???

[caglardursunn]

In Laravel 10, it worked. Thanks! 🍻

[abdouchamkha]

thanks, its workin for laravel 10 but is there is other method to allow the peroxy of livewire upload only ?

[IonutMindrescu]

Thanks, you're the real MVP :D I never thought about CloudFlare.

[flameblue59]

I follow it but its still 401 error

[selfeky]

@dennisvandalen Thanks! It works!

[alexpgates]

In my case, the upload was working, but the temporaryUrl() method wasn't working. I'm on a Forge-provisioned Ubuntu 20.04 server.

Adjusting the trusted proxies didn't work, but commenting out:

abort_unless(request()->hasValidSignature(), 401);

in /vendor/livewire/livewire/src/Controllers/FilePreviewHandler.php worked.

Not ideal, but wanted to add this in case anyone else is having issues with the temporaryUrl() method.

[CodeWithKyrian]

Here's a better alternative. THe hasValidSignature() is a macro on the Request class not a method, so it can be overridden by defining your own macro in your AppServiceProvider or something similar. In my case, I check if we're in the local environment and return true if so, else, revert to the default implementation.

Request::macro('hasValidSignature', function ($absolute = true) {
    if (config('app.env') === 'local') return true;
    return URL::hasValidSignature($this, $absolute);

});

Request::macro('hasValidRelativeSignature', function () {
    if (config('app.env') === 'local') return true;
    return URL::hasValidSignature($this, $absolute = false);
});

Request::macro('hasValidSignatureWhileIgnoring', function ($ignoreQuery = [], $absolute = true) {
    if (config('app.env') === 'local') return true;
    return URL::hasValidSignature($this, $absolute, $ignoreQuery);
});

[muath-ye]

thanks, it worked for me

[bretvanhorn]

This solution worked for me as well. I tried all the others, and short of having to manually comment lines out in vendor files after each deployment, this one did the trick on a more permanent basis. FWIW, our issue only happens on production under our AWS load balancer, so my code below is adapted to that, and also specifically only applies to the livewire/upload-file URL:

$checkValidSignature = (config('app.env') === 'production' && str_contains(\URL::current(), 'livewire/upload-file'));

	  \Request::macro('hasValidSignature', function ($absolute = true) use ($checkValidSignature) {
		  if ($checkValidSignature) {
		return true;
		  }
	return \URL::hasValidSignature($this, $absolute);

	  });

	  \Request::macro('hasValidRelativeSignature', function ()  use ($checkValidSignature) {
		  if ($checkValidSignature) {
		return true;
		  }
		  return \URL::hasValidSignature($this, $absolute = false);
	  });

	  \Request::macro('hasValidSignatureWhileIgnoring', function ($ignoreQuery = [], $absolute = true)   use ($checkValidSignature) {
		  if ($checkValidSignature) {
		return true;
		  }
		  return \URL::hasValidSignature($this, $absolute, $ignoreQuery);
	  });

[bagwaa]

@alexpgates thanks for this, this whole issue cropped up for us when we were behind a load balancer and forcing https, just can't seem to get a valid signature under those circumstances.

Ended up commenting out the above code in the vendor directory as @alexpgates mentioned, but also on FileUploadHandler which has a similar check.

[frasermurraysco]

It also fails with the 401 if the upload takes more than 5 minutes. Maybe this could be configurable? Currently it's hard coded in GenerateSignedUploadUrl:

forLocal:

        return URL::temporarySignedRoute(
            'livewire.upload-file', now()->addMinutes(5)
        );

forS3:

        $signedRequest = $adapter->getClient()->createPresignedRequest(
            $command,
            '+5 minutes'
        );

[mokhosh]

Same problem using cloudflare for ssl

[mvnobrega]

Hi,

In my case the same route but the issues is about request the url in http over https. I receve the message:

This request has been blocked; the content must be served over HTTPS.

[coolsam726]

@danilogiacomi @selfeky

This is because the traffic is proxied. You can set the trusted proxy in the TrustProxies middleware as per the Laravel docs.

The simplest way is to trust all proxies if you don't know them:

protected $proxies = '*';

If you're behind Cloudflare or some kind of load balancer this also applies.

I am running my app in Docker, behind an apache proxy. I have tried this but it doesn't work for me. @calebporzio please shed some light on this issue. Thanks.

UPDATE: The error for me only occurs when I am proxying the app and running it on a sub-directory. For apps running on the root of the domain there is no issue.

[squishythejellyfish]

👋 Oh Hi! I'm Squishy, the friendly jellyfish that manages Livewire issues.

I see this issue has been closed.

Here in the Livewire repo, we have an "issues can be closed guilt-free and without explanation" policy.

If for ANY reason you think this issue hasn't been resolved, PLEASE feel empowered to re-open it.

Re-opening actually helps us track which issues are a priority.

Reply "REOPEN" to this comment and we'll happily re-open it for you!

(More info on this philosophy here: https://twitter.com/calebporzio/status/1321864801295978497)

[ijpatricio]

REOPEN

[ijpatricio]

@coolsam726 I'm having the exact same scenario: docker, behind reverse proxy, and using a subdomain

any chance that you solved it further, and still didn't post more updates here??

[divoto]

same problem with reverse proxy. any solution

[manusiakemos]

did you solve that. i am using laravel sail and octane with reverse proxy nginx

[gazzoy]

+1

[coolsam726]

I finally got my project working behind a reverse proxy and in a sub-directory. I achieved this by combining a couple of solutions:

Problem 1: livewire/update route was ignoring my sub-path:

This is the easier part to fix.

Solution:

Thanks to Livewire 3, it is now possible to specify your own livewire/update path using Livewire::setUpdateRoute(). I set the update route and the script route as follows:

My .env

# .env
APP_SCHEME='https'
APP_PATH='/my-subpath'
APP_BASE_HOST=mydomain.com
APP_URL=${APP_SCHEME}://${APP_BASE_HOST}${APP_PATH}
ASSET_URL=${APP_URL}

My app config:

// config/app.php
[
    'asset_url' => env('ASSET_URL'),
    'scheme' => env('APP_SCHEME','http'),
    'path' => env('APP_PATH', ''),
]

My AppServiceProvider boot() method:

// app/Providers/AppServiceProvider.php boot() method
        \Livewire::setUpdateRoute(function ($handle) {
            $path = config('app.path').'/livewire/update';
            return \Route::post($path, $handle)->middleware('web');
        });
        \Livewire::setScriptRoute(function ($handle) {
            $path = config('app.path').'/livewire/livewire.js';
            return \Route::get($path, $handle)->middleware('web');
        });
        \URL::forceRootUrl(config('app.url'));
        \URL::forceScheme(config('app.scheme','http'));

This setup got my project working under https://mydomain.com/my-subpath

Problem 2: File Uploads were still failing at request()->hasValidSignature()

This is because request()->hasValidSignature() under the hood gets the current absolute url from request()->url(), which for some reason does not factor in the forced root url or scheme above.

The Solution

Thanks to Macros, I extended both the Request and UrlGenerator classes to minimally modify the request()->hasValidSignature() method, keeping the logic intact but using the url() helper to ensure it takes into account the root Url with the subpath. Here are my macros:

// in app/Providers/AppServiceProvider.php register() method
        UrlGenerator::macro('alternateHasCorrectSignature', function (Request $request, $absolute = true, array $ignoreQuery = []) {
            $ignoreQuery[] = 'signature';

            // ensure the base path is applied to absolute url
            $absoluteUrl = url($request->path()); // forceRootUrl and forceScheme will apply
            $url = $absolute ? $absoluteUrl : '/'.$request->path();
            
            $queryString = collect(explode('&', (string) $request->server->get('QUERY_STRING')))
                ->reject(fn ($parameter) => in_array(Str::before($parameter, '='), $ignoreQuery))
                ->join('&');
            $original = rtrim($url.'?'.$queryString, '?');
            $signature = hash_hmac('sha256', $original, call_user_func($this->keyResolver));
            return hash_equals($signature, (string) $request->query('signature', ''));
        });

        UrlGenerator::macro('alternateHasValidSignature', function (Request $request, $absolute = true, array $ignoreQuery = []) {
            return \URL::alternateHasCorrectSignature($request, $absolute, $ignoreQuery)
                && \URL::signatureHasNotExpired($request);
        });

        Request::macro('hasValidSignature', function ($absolute = true, array $ignoreQuery = []) {
            return \URL::alternateHasValidSignature($this, $absolute, $ignoreQuery);
        });

With the two hacks above, I have my projects both containerized and hosted in sub-paths and working smoothly. I hope this saves somebody's three years.

[scharala]

@coolsam726 Thank you sooo much for this solution. I also serve laravel from a sub directory and i really didn't want to comment out the file in vendor (abort_unless line) as was suggested.
The problem with my project was not the directory returned from request->url(), but that for some reason my querystring had the same parameters twice, when i run it with ssl in a production server and it didn't match. I added this line in your code and it now works for me (hope it helps somebody as well)
$queryString = explode('&',$queryString)[0];
Thanks again

[ijpatricio]

so i can confirm, "solution" here https://forum.laravel-livewire.com/t/file-upload-over-https-fails-signature-verification/1242
makes it work!

TLDR = comment out abort_unless(request()->hasValidSignature(), 401)
in vendor/livewire/livewire/src/Controllers/FileUploadHandler.php @ handle method.

[ijpatricio]

Thank you @danilogiacomi ! Sorry that just now realised you must be Dan from the livewire forum, so it was you opening the issue originally!

[klrkdekira]

Just to ping somehow setting TrustProxies with the following doesn't work for me, it resulted with route generated with a :80 suffix.

protected $proxies =  '*';

Or I might be missing something here.

[up2top]

I faced the file upload signature verification problem when uploading user avatars via Livewire component in Laravel. The preview images of freshly uploaded files were not displayed by the $file->temporaryUrl() function.

Setting TrustProxies middleware to trust all the proxies didn't solve the problem.

Earlier I added the following lines to the Nginx site configuration of the Forge service to improve browser caching of static assets:

    location ~*  \.(jpg|jpeg|png|gif|ico|css|js|pdf)$ {
        expires 7d;
    }

Removing all image extensions from this setting fixed the problem. So, the final working setting is the following:

    location ~*  \.(ico|css|js|pdf)$ {
        expires 7d;
    }

Now preview images of uploaded files are displayed correctly. As for caching of images, I moved all of them to the separate CDN server.

[corbinjurgens]

I may have spotted the cause for my situation. Nginx as reverse proxy to apache. Passing scheme header as X-Forwarded-Proto in Nginx

EVEN if you use

\URL::forceScheme( request()->header('X-Forwarded-Proto', 'https') );

or similar in your AppServiceProvers boot,

the requsests url will still technically be http, by that I mean calling request()->url(), which is how hasValidSignature is verified.

My trusted proxy and proto seems to be configured correctly. This is how the symphony works to create url with https or not. I know that my proto header is working, but sympony may be getting a variation of it like looking for 'X_FORWARDED_PROTO' when it should be 'HTTP_X_FORWARDED_PROTO'

    public function isSecure()
    {
        if ($this->isFromTrustedProxy() && $proto = $this->getTrustedValues(self::HEADER_X_FORWARDED_PROTO)) {
            return \in_array(strtolower($proto[0]), ['https', 'on', 'ssl', '1'], true);
        }

        $https = $this->server->get('HTTPS');

        return !empty($https) && 'off' !== strtolower($https);
    }

Anyway. What fixed it for me was adding this code alongside the normal 'forceScheme'

request()->server->set('HTTPS', request()->header('X-Forwarded-Proto', 'https') == 'https' ? 'on' : 'off');

As can be seen in the isSecure() function, if the first part fails it looks to see if HTTPS is anything (except off)

[DRN88]

+1 Only this worked for me with nginx.
Added TrustedProxies

AppServiceProvider

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        URL::forceScheme('https');
        request()->server->set('HTTPS', request()->header('X-Forwarded-Proto', 'https') == 'https' ? 'on' : 'off');
    }

[iamgoodbytes]

This was the solution for me in Laravel 10 + Dokku on Ubuntu

[allanmarzuki]

awesome @DRN88

[xcesaralejandro]

 /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        URL::forceScheme('https');
        request()->server->set('HTTPS', request()->header('X-Forwarded-Proto', 'https') == 'https' ? 'on' : 'off');
    }

This works for me using docker with traefik as reverse proxy. Love you 🥰

[lnfel]

Apparently the trusted proxies answer did not work.
What worked for me is adding Content-Security-Policy upgrade-insecure-requests, simply add it so the head element below title tag:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

This will upgrade any request that is sent over http to https instead, note by default most browsers to this automatically if the page being viewed is served over https but sometimes it would overlook other requests over http and simple do nothing, just like livewire upload. In this case we tell the browser to upgrade-insecure-requests all request instead.

sources:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests
https://web.dev/fixing-mixed-content/

[tpaksu]

I fixed this with this middleware, in my case the querystring contained the path and because of that, the signature didn't match. So I intervened with a middleware to fix the querystring:

1. Create the file \app\Http\Middleware\QueryStringFixer.php with this content:

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Str;

class QueryStringFixer
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle(Request $request, Closure $next)
    {
        if (isset($_SERVER['QUERY_STRING']) && Str::startsWith($_SERVER['QUERY_STRING'], "/")) {
            $parts = explode('&', htmlspecialchars_decode($_SERVER["QUERY_STRING"]));
            array_shift($parts);
            $new = [];
            foreach ($parts as $v) {
                $x = explode('=', $v);
                $key = array_shift($x);
                $value = implode('=', $x);
                $new[$key] = $value;
            }
            $_SERVER['QUERY_STRING'] = http_build_query($new);
            $request->server->set("QUERY_STRING", $_SERVER['QUERY_STRING']);
        }
        return $next($request);
    }
}

2. Add this line to the beginning of the web middleware list in app/Http/Kernel.php

\App\Http\Middleware\QueryStringFixer::class,

This will fix the $_SERVER['QUERY_STRING'] and request()->server->get('QUERY_STRING') which is used by:

https://github.com/illuminate/routing/blob/6e4eae42bae76606d7ff5664c75bf7a1c86c4df4/UrlGenerator.php#L382-L405

[perstnev]

We had the same issue with Linux web server on nginx behind nginx based reverse proxy and load balancer. Https traffic is terminated on LB so when forwarded to web server it is already http. And as described by [corbinjurgens] Laravel/Symphony determines if request isSecure() by checking x-forwarded-proto header. Knowing this we were able to fix issue by setting x-forwarded-proto header to “https” on reverse proxy when it proxys requests to web server. In that case Laravel treats request as secure. I believe such solution is more elegant (and independent of Laravel/Livewire code) in comparison to disabling isSecure() check in FileUploadHandler or by adding additional middleware inside application.
Good luck!

[paubikas]

I guess you also should read this blog. Then running laravel behind proxy you should not force https

[kocoten1992]

My problem was https://laravel.com/docs/9.x/octane#serving-your-application-via-https (I forgot set OCTANE_HTTPS to true).

[wadehuangtw]

I had the same issue with Cloudflare + load-balancer + laravel 9.

Here are what I did solving this problem:

1. edit laravel .env file

- TRUST_PROXIES=null
// set your load balancer ip to TRUST_PROXIES, I set * for my staging environment
+ TRUST_PROXIES='*'

2. edit load-balancer nginx configs ex: site-enable/your_website.conf

    location / {
        proxy_pass http://YOUR_WEBSITE;

        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+      proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Host $host;
        proxy_buffering off;
        proxy_cache off;
        proxy_http_version 1.1;
        #proxy_set_header X-Forwarded-Port 443;
    }

then file can be upload successfully.

[msalehipro]

Very very thanks for your solution, you made my day!
it's been a long time for me that i did a lot of searching and doing multiple solutions, but this one line solved my problem properly!
proxy_set_header X-Forwarded-Proto https;

Thanks a lot man.

[ajoaespinola]

In my case (Nginx reverse proxy + Apache + Laravel 8) this was the solution!. Thanks!

[SakNoelCode]

Hello, I had the same problem, I put you in context, I have a liveware application running on an apache server that has Cpanel, it has the JetStream package installed. I got the error on the console every time I tried to upload the profile photo, with the error message: The :attribute field could not be uploaded. I tried all the previous solutions without any success, until I started to check the network status and preview the exception that I was getting. There I found the following error:
Class 'finfo' not found but the module is in php.ini
I found the solution at : https://stackoverflow.com/questions/32811014/file-info-php-error-class-finfo-not-found-but-the-module-is-in-php-ini
I just had to activate the fileinfo package, he left this answer in case someone else experiences something similar.

[togrul]

Hello, I had same problem and fixed it, modify nginx .conf file as following

server {
    listen 80;

    server_name www.domain domain;

    access_log /var/log/nginx/domain.access.log;
    error_log /var/log/nginx/domain.error.log;

    root   /var/www/html/domain;
    index index.php index.html;

    # serve static files directly
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # removes trailing slashes (prevents SEO duplicate content issues)
    if (!-d $request_filename)
    {
        rewrite ^/(.+)/$ /$1 permanent;
    }

    # enforce NO www
    if ($host ~* ^www\.(.*))
    {
        set $host_without_www $1;
        rewrite ^/(.*)$ $scheme://$host_without_www/$1 permanent;
    }

    location ~* \.php$ {
        try_files $uri = 404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
      }
}

[sinasaeedi]

I'm using Filament 3, nginx reverse proxy and apache in a docker container.

This worked for me:

1. Run a2enmod headers in docker container
2. Create a new apache config file at /etc/apache2/conf-enabled/https-headers.conf and this line into it RequestHeader set X-Forwarded-Proto https, which is automatically detected by apache (IncludeOptional conf-enabled/*.conf)
3. Add these lines to AppServiceProvider boot function:

if (app()->isProduction()) {
    URL::forceScheme('https');
    request()->server->set('HTTPS', request()->header('X-Forwarded-Proto', 'https') == 'https' ? 'on' : 'off');
}

[mauriciovictor]

worked for me, thanks bro

[coolsam726]

@coolsam726 I'm having the exact same scenario: docker, behind reverse proxy, and using a subdomain

any chance that you solved it further, and still didn't post more updates here??

I finally got my project working behind a reverse proxy and in a sub-directory. I achieved this by combining a couple of solutions:

Problem 1: livewire/update route was ignoring my sub-path:

This is the easier part to fix.

Solution:

Thanks to Livewire 3, it is now possible to specify your own livewire/update path using Livewire::setUpdateRoute(). I set the update route and the script route as follows:

My .env

# .env
APP_SCHEME='https'
APP_PATH='/my-subpath'
APP_BASE_HOST=mydomain.com
APP_URL=${APP_SCHEME}://${APP_BASE_HOST}${APP_PATH}
ASSET_URL=${APP_URL}

My app config:

// config/app.php
[
    'asset_url' => env('ASSET_URL'),
    'scheme' => env('APP_SCHEME','http'),
    'path' => env('APP_PATH', ''),
]

My AppServiceProvider boot() method:

// app/Providers/AppServiceProvider.php boot() method
        \Livewire::setUpdateRoute(function ($handle) {
            $path = config('app.path').'/livewire/update';
            return \Route::post($path, $handle)->middleware('web');
        });
        \Livewire::setScriptRoute(function ($handle) {
            $path = config('app.path').'/livewire/livewire.js';
            return \Route::get($path, $handle)->middleware('web');
        });
        \URL::forceRootUrl(config('app.url'));
        \URL::forceScheme(config('app.scheme','http'));

This setup got my project working under https://mydomain.com/my-subpath

Problem 2: File Uploads were still failing at request()->hasValidSignature()

This is because request()->hasValidSignature() under the hood gets the current absolute url from request()->url(), which for some reason does not factor in the forced root url or scheme above.

The Solution

Thanks to Macros, I extended both the Request and UrlGenerator classes to minimally modify the request()->hasValidSignature() method, keeping the logic intact but using the url() helper to ensure it takes into account the root Url with the subpath. Here are my macros:

// in app/Providers/AppServiceProvider.php register() method
        UrlGenerator::macro('alternateHasCorrectSignature', function (Request $request, $absolute = true, array $ignoreQuery = []) {
            $ignoreQuery[] = 'signature';

            // ensure the base path is applied to absolute url
            $absoluteUrl = url($request->path()); // forceRootUrl and forceScheme will apply
            $url = $absolute ? $absoluteUrl : '/'.$request->path();
            
            $queryString = collect(explode('&', (string) $request->server->get('QUERY_STRING')))
                ->reject(fn ($parameter) => in_array(Str::before($parameter, '='), $ignoreQuery))
                ->join('&');
            $original = rtrim($url.'?'.$queryString, '?');
            $signature = hash_hmac('sha256', $original, call_user_func($this->keyResolver));
            return hash_equals($signature, (string) $request->query('signature', ''));
        });

        UrlGenerator::macro('alternateHasValidSignature', function (Request $request, $absolute = true, array $ignoreQuery = []) {
            return \URL::alternateHasCorrectSignature($request, $absolute, $ignoreQuery)
                && \URL::signatureHasNotExpired($request);
        });

        Request::macro('hasValidSignature', function ($absolute = true, array $ignoreQuery = []) {
            return \URL::alternateHasValidSignature($this, $absolute, $ignoreQuery);
        });

[atomicptr]

For Laravel 11.x this worked for me: https://laravel.com/docs/11.x/requests#trusting-all-proxies (should probably add the correct proxy instead though!)

[Capevace]

I've been facing this exact issue. It appears to do with the proxying from NGINX to the Octane daemon.

I'm using Forge and Swoole and forcing HTTPS inside the NGINX location @octane block worked for me:

proxy_set_header X-Forwarded-Proto "HTTPS";

[mrfelipemartins]

I am using Forge + FrankenPHP and I can confirm this solved my issue with temporary file uploads.

Thanks @Capevace

[ThaKladd]

I got this problem and tried a few solutions without luck. I use ddev in my local development, and the following finally worked:

Add to .ddev/nginx_full/nginx-site.conf:

location ^~ /livewire {
    try_files $uri $uri/ /index.php?$query_string;
}

The gotcha is, I tried this and it did not work, because ddev removed it as ddev owns the file and overwrites it. So, you have to remove line 3, which says: #ddev-generated, and ddev will overwrite it no more.

Thanks to @mvnobrega