Should unauthorized_handler really trigger before not_found_handler?

[kjrocker]

I was going through the documentation, and this didn't make sense to me:

If both an :unauthorized_handler and a :not_found_handler are specified for load_and_authorize_resource, and the request meets the criteria for both, the :unauthorized_handler will be called first.

Why would I care if a user is unauthorized for a resource if that resource doesn't exist? And how can authorization status be determined against a nil resource? A cursory glance at the code shows some checking to get around this, so it's possible I'm missing something.

Before I put the time in to refactor this, I'm curious to hear your thoughts.

[JamieREvans]

If a user requests resources by random identifiers and gets a mix of :forbidden and :not_found for each request, they are technically getting access to information they shouldn't be able to get.

For example, if the platform had groups and used a slug for the identifier, a user may be able to try these combinations:

forbidden: "groups/nike"
not_found: "groups/xrdkow"
forbidden: "groups/us_gov"

The intention here, I'm assuming, is to obfuscate this information by defaulting to :forbidden, rather than having split results.

[cpjk]

Thanks for the answer @JamieREvans!