Is it possible to avoid URL update in the browser with Inertia::get() ?

Best Answer

Level 102

Inertia does this to ensure that if you hit F5 you get the exact same result. A solution I personally use is to send a POST request to an endpoint which sets something in session, and then in the normal get route, I check if that session exists and change what is sent to the frontend based on that.

1 like

Level 63

@Sinnbeck Ok thank you.

I have this problem when I need to filter datas in a datatable for example, and the URL is updated, showing several ids and other filter datas that aren't so useful for the users and I think that it's not so clean.

For the moment I got around this problem using an axios request to get the data and it works fine.

But the idea to write the filters into a session is a very good idea, it allows the users to visit another page and when returning to the initial page, they recover their previous filters.

Level 102

@vincent15000 Be aware that most users dont care that much. An example. Go to google.com and do a search for "foo". Notice the url? Is that useful to you? Do you care? What I care about is that I can give that url to someone and they get the exact same result as me. So if I want to filter a list of users, and show the result to a colleague, I can just copy the link into an url and they will see the same result :)

1 like

Level 63

@Sinnbeck That's a good argument to let InertiaJS do its job with updating the URL with all filters. That's true only if the code retrieves the URL parameters ... for the moment I don't do this, but I will think about this.

I don't know why, but it has always disturbed me to see the ids in the URL (for an edit route or for filters for example). I had used slugs to get around this, but some people use UUID instead. Does UUID primary key become the new standard (I mean the new pratice for quite all apps) ?

Level 102

@vincent15000 Dont think its the new standard, but adding a secondary column with uuid, and using that for route model binding is very popular. This way you can still use the ID for relationships and foreign keys :)

1 like

Level 63

@Sinnbeck Is it really a bad idea to display the ids in the URL ? Does it really prevent from any bad experience with security ?

Level 102

@vincent15000 Only if you make mistakes in your code. Say you dont want a user accessing the next id, and you didnt block it properly. Then they can easily find it. Same goes for updating or deleting. If you can just add +1 you an ID and they know the next record, you can in theory exploit the system

1 like

Level 63

@Sinnbeck Ok ... so your are saying that if the code is secured with middlewares and policies for example, even if you can exploit the system, there is probably very few bad luck that your datas are vulnerable.

I also understand that it's a better security to use UUID so that primary keys aren't N, N + 1, ...

Level 102

@vincent15000 Its security by obfusaction which on its own doesnt do much. If your policies does not work, a hacker can still find some uuid and exploit, it just takes more work and the damage wont be as big (as they need to find one at a time)

1 like

Level 63

@Sinnbeck Ok so UUID is always a good pratice.

Level 102

@vincent15000 It can be. But notice that even here on laracasts id is used (check the url &replyId=828415)

1 like

Level 63

@Sinnbeck It doesn't work for me ... what's the URL ? with which route ?

For the UUID, I meant that it's always a good pratice if you handle sensitive datas. For a social network like Laracast, sure it would be a shame if datas were lost, but there are no secret datas here ;).

Level 102

@vincent15000 Here is an example: https://laracasts.com/discuss/channels/inertia/avoid-url-update-in-the-browser-with-inertiaget?page=1&replyId=828418

And yes true. But I assume laracasts has tests ensuring I cannot delete your comment and similar :)

1 like

MohamedTammam

Level 51

That's the default browser behavior in monolith apps which Inertia follows. So far I didn't see a way to do what you're asking for. As a workaround, you can store your query inputs as a session and then redirect back to the default link.

Example

public function main_page(Request $request)
{
	if(session()->has('search_query')) {
		$data = json_decode(session()->get('search_query'))
		session()->forget('search_query'); // clear session
		// ...
	}
}

public function search(Request $request)
{
	$request->validate([
		// ...
	]);
	session()->put('search_query', json_encode($request->validated()));

	return redirect()->route('main_route');
}

That approach will clear the URL, however I don't recommend it since I don't see any issue adding GET request data in the URL. That's how it should be to get the information again when you refresh or sending it to someone else. If it's sensitive data, it should be in POST request.

1 like

Level 63

@MohamedTammam It's only to filter a datatable, that's why it's useful to add data in the URL.

Perhaps I use the bad way to filter : I send a GET request with the filters as params in the URL (like axios does with a GET request).

Is it better to use a POST request to filter ? I don't think so, but perhaps I'm wrong.

MohamedTammam

Level 51

@vincent15000 If it's just a search I use GET for the reasons I mentioned before.

1 like