AuthzBackend::has_perm should accept &permission

[Enduriel]

Not sure why it doesn't, as far as I can tell this would be a breaking change but definitely worthwhile since there's no reason it would have to own the permission that I can think of, and this has added a clone to my code that didn't have to be there.

[maxcountryman]

Wouldn't it be better to take either a shared reference or an owned value?

Likewise with authenticate I would think (credentials don't need to be owned per se).

[Enduriel]

Good point about authenticate, missed that one. I'm not sure why a shared ref or owned value would be preferable in either case though. My mentality is to take the least amount of ownership possible in functions. Unless I'm missing something, in that case it's ref for both?

[maxcountryman]

Perhaps. It is a breaking change that requires every application to update their implementation. While this is (hopefully) a trivial update, it's churn that needs to be weighed nonetheless. It would be far better to make this change in a way that allowed current implementations to function without code changes. It's also not clear that it isn't useful for e.g. authenticate to own its arguments; for example, does this make it harder to accidentally share credentials in dangerous ways?

[Enduriel]

I agree this is an irritating change to make, and it should 100% be bundled with other breaking changes in the future, I don't necessarily think this is particularly high priority, but I do think the current setup is 'wrong'.

In the standard implementation authenticate is mostly just called by the axum_login backend, and it doesn't generally seem necessary for downstream applications to use it with the normal flow. I can't think of a way that ownership affects anything here in a useful manner, and believe it's just better to follow the rust principles for function signatures: I only need to read non-destructively -> I take a reference. This is especially true in the case of has_perm.

[maxcountryman]

In the standard implementation authenticate is mostly just called by the axum_login backend

I think you're confused: authenticate and login are together the primary public API of this crate. Virtually all applications would use these methods together.

More specifically because credentials are passed to authenticate it could make sense for authenticate to own this value as it provides some friction against frivolously sharing credentials elsewhere.