Document in the InertiaJS the importance of avoid to use "no-referrer" as meta "referrer" parameter #477

juanparati · 2021-02-02T13:34:03Z

juanparati
Feb 2, 2021

Laravel detects the last visited page reading the "referrer" header for GET requests.

I observed that Laravel redirect to the previous page when meta "referrer" parameter is equal to "no-referrer" and a form is posted without pass the validation. This is an issue because the user maybe redirected to different page without receive the validation error message.

I propose to add in the links page (https://inertiajs.com/links) a mention about that post requests may redirect to a wrong page when validation fails when meta "referrer" is equal to "no-referrer".

Note: This is not an InertiaJS issue but the default Laravel behavior.

RobertBoes · 2021-02-02T14:10:35Z

RobertBoes
Feb 2, 2021

From what I can tell, Laravel already handles this the way it's supposed to. The base FormRequest validation calls previous() on the UrlGenerator (see FormRequest->getRedirectUrl()). If the referrer header is not set, the previous URL that's stored in the session is then used (see UrlGenerator->previous()).
For manual validation (when a ValidationException is thrown) this is also the case, see Handler->invalid()

Maybe there's a bit more at play with Inertia, but it looks like Laravel always uses a fallback to the previous URL that's stored in the session when no referrer is present.

6 replies

RobertBoes Feb 3, 2021

I just did some testing using inertiajs/pingcrm, I made the following changes:

In app.blade.php I added <meta name="referrer" content="no-referrer">, verified that the referrer is not sent with the request. Go to the edit page of an organization (/organisations/1/edit), remove the title and click update, the response is a 303 and the follow up request is redirected back to the edit page, same as when the referrer is sent with the request. The previous URL is fetched from the session by Laravel because a referrer was not sent with the request.

I also tried this using a form request (php artisan make:request UpdateOrganizationRequest), moved the rules from the controller to the request class and returned true in authorize(). The controller method then looks like this:

public function update(UpdateOrganizationRequest $request, Organization $organization)
{
    $organization->update(
        $request->validated()
    );

    return Redirect::back()->with('success', 'Organization updated.');
}

This also works as above, since the referrer is fetched from the session.

I might be missing something, but from what I can tell this is the default and desired behavior, right?

juanparati Feb 4, 2021
Author

@RobertBoe: I can reproduce this issue.

I enclose a video and also the steps to reproduce with the PingCRM demo.

Environment:
Os: Mac Os Big Sur (11.1)
Browser: Firefox 84.0.2

Steps to reproduce:

User visits PingCRM login page.
User login.
User clicks on the organizations link.
User clicks on the "Create organization" button.
User attempts to submit the organization form without to complete the required fields.

Expected behavior:
Web browser redirects to the organization form and display the form errors.

Received behavior:
Web browser redirects to the dashboard page.

reinink Feb 4, 2021
Maintainer

This is very strange. I cannot reproduce this, nor have I ever experienced this. I just tried those exact steps at https://demo.inertiajs.com, and could not reproduce it. 🤔

I've tried this in Chrome, Firefox and Safari.

juanparati Feb 4, 2021
Author

@reinink: Did you added the "" to the app.blade.php?

Example:


<!DOCTYPE html>
<html class="h-full bg-gray-200">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0">
    <meta name="referrer" content="no-referrer">
    <link href="{{ mix('/css/app.css') }}" rel="stylesheet">

    {{-- Inertia --}}
    <script src="https://polyfill.io/v3/polyfill.min.js?features=smoothscroll,NodeList.prototype.forEach,Promise,Object.values,Object.assign" defer></script>

    {{-- Ping CRM --}}
    <script src="https://polyfill.io/v3/polyfill.min.js?features=String.prototype.startsWith" defer></script>

    <script src="{{ mix('/js/app.js') }}" defer></script>
    @routes
</head>
<body class="font-sans leading-none text-gray-700 antialiased">

@inertia

</body>
</html>

reinink Feb 4, 2021
Maintainer

Ahhh, silly me, that's what I get for only reading part of this thread. 🤣

juanparati · 2021-02-04T15:08:20Z

juanparati
Feb 4, 2021
Author

Note: It is not an InertiaJS bug, it's how Laravel works, so this is the reason by I think that is important to add a mention in the documentation about the "no-referrer" policy.

3 replies

reinink Feb 4, 2021
Maintainer

While I totally appreciate your desire to try and help other Inertia users, I think this is really a Laravel specific "problem", and doesn't really fit in the Inertia.js docs.

juanparati Feb 4, 2021
Author

The issue that the fact that we use inertia-links instead of normal links that doesn't perform ajax request will cause this problem. I think that many people will have this issue and will raise bug tickets without reason. If you appreciate your time you can add a mention in the documentation you are going to avoid many of those bug tickets.

claudiodekker Feb 4, 2021
Collaborator

@juanparati From what I can tell, this is honestly the first time I've seen anyone raise this concern/problem with Inertia, so I don't really agree with the added value of placing this in our documentation: The more non-essential/edge-case details we add to the documentation, the less people will actually read the documentation (tl;dr), which in my experience causes more issue tickets to be opened needlessly.

I believe that the better approach here is to simply let search engines do their job of leading people to results that best fit their queries, which will sooner or later lead them to this exact discussion or a similar StackOverflow/Github issue. 👍

davzie · 2021-06-27T23:01:03Z

davzie
Jun 27, 2021

I've stumbled across this thread because it's the only thing that comes close to a similar issue I'm having which is Inertia specifying the wrong Referer header but only on my production sites. Locally referer is set correctly and this is the case even if using exactly the same built production-ready file (assets are compiled and put into version control).

If I have no referer meta set in the HTML layout, the form will, no matter what the scenario redirect back to the root.

If the meta no-referrer policy is set, the referer header specified is whatever page I hit first. Navigating using an Inertia Link to a second page and using a form there will force a redirect to the first page I visited (if the result of that request on Laravel is a redirect back to the previous page for example). This is happening because if Laravel doesn't see a referer header, it will use the last known page to redirect back to which in this scenario is the first page I hard visit. Subsequent Inertia requests do not register on Laravel as URL visits.

Absolutely no idea why this is happening as I can't understand if it's an Inertia specific thing I need to dive further into, an Axios specific thing, a HTTP thing etc. Any pointers would be great!

2 replies

davzie Jun 27, 2021

I was going to delete this but I will leave it up incase others have something similar. I had manually, many weeks ago added a referrer policy within the Nginx block itself:

add_header Referrer-Policy "strict-origin" always;

This was breaking it all. Removing it solved it. Apologies but leaving for posterity!

reinink Jul 1, 2021
Maintainer

Thanks for sharing this! It could definitely help someone in the future. 👍

jonagoldman · 2021-06-28T11:09:37Z

jonagoldman
Jun 28, 2021

Not the same issue at all but I had a somewhat similar thing with the session flash data not persisting between redirects.
This was because one middleware triggered a redirect to another route, and that route had another middleware that redirected again. It might be related. I fixed it by persisting the flash data in the session using
$request->session()->reflash(); or $request->session()->keep() depending on the situation.

https://laravel.com/docs/8.x/session#flash-data

1 reply

reinink Jul 1, 2021
Maintainer

Yeah, when redirecting flash data isn't preserved unless you specifically tell it to. Again, this is more of a Laravel issue than an Inertia issue, but you do run into it from time to time in Inertia apps. You can see here that we even do this in the Laravel adapter when assets change.

keroth- · 2022-08-02T12:51:07Z

keroth-
Aug 2, 2022

I have a very similar issue than @juanparati.
On a staging server, the referer is not set on the headers.

I am on the homepage.
I go with Inertia <Link> on the login page.
I submit the login form with Inertia with wrong credentials.
A ValidationException is thrown.
The previous URL used is from the session because the referer is null.
Check the previous function from Illuminate\RoutingUrlGenerator.php class. The URL is set like this:
$url = $referrer ? $this->to($referrer) : $this->getPreviousUrlFromSession();
I am redirected to the homepage.

The problem is that the previous URL from the session is not the URL who sent the POST request (aka the login page).
It's the first URL visited (aka the homepage).
So it could work if we visited the login page directly.

On my local server, the referer is well defined and I am redirected to the login page with the errors displayed.

What can we do to fix this (except add the referer in the headers) ?
The URL who sent the POST request should'nt be defined to the session previous URL?

Thank you!

0 replies

Document in the InertiaJS the importance of avoid to use "no-referrer" as meta "referrer" parameter #477

Uh oh!

juanparati Feb 2, 2021

Replies: 5 comments · 12 replies

Uh oh!

RobertBoes Feb 2, 2021

Uh oh!

RobertBoes Feb 3, 2021

Uh oh!

Uh oh!

juanparati Feb 4, 2021 Author

Uh oh!

reinink Feb 4, 2021 Maintainer

Uh oh!

juanparati Feb 4, 2021 Author

Uh oh!

reinink Feb 4, 2021 Maintainer

Uh oh!

juanparati Feb 4, 2021 Author

Uh oh!

reinink Feb 4, 2021 Maintainer

Uh oh!

Uh oh!

juanparati Feb 4, 2021 Author

Uh oh!

Uh oh!

claudiodekker Feb 4, 2021 Collaborator

Uh oh!

Uh oh!

davzie Jun 27, 2021

Uh oh!

davzie Jun 27, 2021

Uh oh!

reinink Jul 1, 2021 Maintainer

Uh oh!

jonagoldman Jun 28, 2021

Uh oh!

reinink Jul 1, 2021 Maintainer

Uh oh!

keroth- Aug 2, 2022

juanparati
Feb 2, 2021

Replies: 5 comments 12 replies

RobertBoes
Feb 2, 2021

juanparati Feb 4, 2021
Author

reinink Feb 4, 2021
Maintainer

juanparati Feb 4, 2021
Author

reinink Feb 4, 2021
Maintainer

juanparati
Feb 4, 2021
Author

reinink Feb 4, 2021
Maintainer

juanparati Feb 4, 2021
Author

claudiodekker Feb 4, 2021
Collaborator

davzie
Jun 27, 2021

reinink Jul 1, 2021
Maintainer

jonagoldman
Jun 28, 2021

reinink Jul 1, 2021
Maintainer

keroth-
Aug 2, 2022