supportsToken is tied to a specific implementation detail about sanctum HOT 7 CLOSED

Hi there,

Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels:

• Laracasts Forums
• Laravel.io Forums
• StackOverflow
• Discord
• Larachat
• IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!

Thanks.

from sanctum.

@driesvints

Not sure how this can be mistaken for a support question.

from sanctum.

Hi @nicoqh. You seem to be asking questions about how things work in Sanctum. That's a support question. This issue tracker is only for reporting bugs. There's also no bug template filled in here.

from sanctum.

Hi, @driesvints

No, I questioned the guard's implementation. And I assumed it was a good idea to ask a question about the design decisions before possibly submitting a PR. I'd open a discussion, but there's no such feature enabled on the repo.

from sanctum.

@driesvints I totally agree with @nicoqh. This does belong here as its not so much a support question, but a technical question in regards to the code it self. We know what the issue is and we know how to fix it, but we need some input from the maintainers before doing anything like suggesting a change through a PR. I believe the need to take issues to zero is taking precedence over actually carefully reading the issue.

But in any case this is why I landed here:

I came here after I was reading Sanctum's code, because I have a specific case where the users would be on 1 connection (server a) and the tokens on another (server b) and I was unpleasantly surprised to see this unnecessary tight coupling preventing me from otherwise easily implementing this.

Sanctum also provides a Laravel\Sanctum\Contracts\HasApiTokens-interface, but that is surprisingly only used in DocBlock annotations!?

Using the "trait" check is probably done to prevent users from also having to add an implements HasApiToken interface besides adding the trait.

Ideally the supportsTokens should check wether it supports tokens by checking if $tokenable implements the interface and not the very specific trait. This might be a to large of a change to do without a version bump perhaps?

Another solution might be to make it possible to "overwrite" the supportsTokens logic by perhaps giving us the option to set a callable that would be used instead if set. I have seen this pattern used more within the Laravel code base (don't have an example on hand, but I know they are there).

edit:

So all it takes is this small change: 4.x...Ilyes512:sanctum:update-supports-token-logic-by-checking-contract

Funny thing is, I was expecting one or more tests to fail, but it didn't because the model that is used with the tests already explicitly implements the HasApiTokens-interface. See https://github.com/laravel/sanctum/blob/4.x/workbench/app/Models/User.php#L9

from sanctum.

I believe the need to take issues to zero is taking precedence over actually carefully reading the issue.

I wouldn't be too quick to judge. It's easy to judge another if you're not in their shoes. We definitely welcome PR's if there's something to be improved here which is what you've done. So let's see how it goes.

from sanctum.

I wouldn't be too quick to judge. It's easy to judge another if you're not in their shoes.

True, I can only imagine you and the rest of the Laravel team are quite busy maintaining existing code and delivering awesome new stuff. And I am thank full of that!

It's just sometimes it feels like tickets get closed to quick, but I also understand you need to prioritise stuff.

Also I actually don't need the change anymore... but I still think it's better to check against the interface if you want to enable people changing the specific implementation detail.

from sanctum.