Authorization - 404 instead of 403.

When trying to access a page for which I don't have access I get 404 instead of 403. Why is that so?

Solution:

Ah.. here we go. I got this bit of code on my resource. ```php public static function getEloquentQuery(): Builder { return parent::getEloquentQuery()->where('user_id', auth()->id());...

Jump to solution

15 Replies

Dennis Koch•5mo ago

You don't have access to the page or the record?

reppairOP•4mo ago

I do, I don't. What does it matter. My test is simple, access a page I don't have access for, and I expected 403 response, but instead Filament returns 404. Which is probably fine and designed this why for a good reason.

$this->get(DomainResource::getUrl('view', ['record' => $anotherUsersDomain->getKey()]))
  // ->assertForbidden() // 403 Forbidden - fails
  ->assertNotFound(); // 404 Not Found - passes

$this->get(DomainResource::getUrl('view', ['record' => $anotherUsersDomain->getKey()]))
  // ->assertForbidden() // 403 Forbidden - fails
  ->assertNotFound(); // 404 Not Found - passes

As my orginal question goes. Do you know why is that so?

toeknee•4mo ago

So filament will give a 404 if you do not have access to the resouce for that tenant because that has not been registered because that tenant doesn't have access. You will get a 403 if trying to access a resource record. A page doesn't exist unless they have access, that's not a 403 otherwise that would allow someone to try and find all possbile resources that the tenants doesn't have access too. you get a 403 when trying to edit a record directly but have access to the resource for example.

reppairOP•4mo ago

I see. Makes sense. Cheers! Now that I think of it, attempting to directly edit a record and getting 403, that request can also be done without having access to the edit page. As a stand alone request. No?

toeknee•4mo ago

How can it? The routes won’t exist unless the tenant has access. If your not using tenancy, then the route will exist but.. trigger a 403

reppairOP•4mo ago

No I am not using tenancy. I was wondering why you would involve tenancy. I was talking just a regular authenticated user.

toeknee•4mo ago

Ahh ok, so if the resource isn't accessible by the user then they won't be registered in the panel and so it's a 404. If the resource is accessible, but the record isn't it's a 403.

reppairOP•4mo ago

Exactly, the resource is accessible to all users, some records belong to a said user others don't. Accessing another user's record should return 403, not 404.

Tim van Heugten•4mo ago

Unless you don’t want them to be discoverable. There are scenarios where you don’t want a user to be able to try random identifiers/slugs to check if some other user already created it / owns it. I think thats basically what @toeknee tried to say when referring to tenancy.

awcodes•4mo ago

Agreed, it’s been an argument of contention for a while now, a 403 proves the record exists from a hacker’s POV. But understandable that it may not be desired behavior for the app or business goals.

Tim van Heugten•4mo ago

Whenever you use incremental IDs this most likely isn’t an issue as that gives away existing IDs anyway. Or you should rethink using them right now. Hacking can be one reason, but it can also be competitors checking out your apps usage / user base.

reppairOP•4mo ago

Currently I am buildling a client facing panel. So it is actually prefferable to be 404 I'd say. Just trying to understand the reasoning behind it and if it is normal. Makes sense. Is there a way to tweak configuration somehow when it makes sense to do so?

awcodes•4mo ago

I think there’s a Response::denyWithStatus(404) you could use in either a gate or the policy. Might be better to override the exception handler globally though. But that could get tricky if you actually want to return a 403, depending on use case.

Solution

reppair•4mo ago

Ah.. here we go. I got this bit of code on my resource.

    public static function getEloquentQuery(): Builder
    {
        return parent::getEloquentQuery()->where('user_id', auth()->id());
    }

    public static function getEloquentQuery(): Builder
    {
        return parent::getEloquentQuery()->where('user_id', auth()->id());
    }

So that probaly is taken into account for the route model binding for the view page and other custom pages. Or any other route uner that resource which resolves the {record}.

reppairOP•4mo ago

That is why I get 404, not 403. 🙂 Without it, I get the expected 403 status code.

Gaming

Programming

Authorization - 404 instead of 403.

Did you find this page helpful?