Closed fabriciojs closed 4 years ago
haha dang it, i almost implemented this but wasn't sure if people would even want to use this package. I'll dig around and get a nice solution implemented.
Thanks for mentioning this
hey @fabriciojs i'm pushing up a (hopeful) fix, testing it locally seems to do the trick.
Not sure if this applies to your use case, but i have it now use the user model that is also used as the authenticated user via the request get_class($request->user())
. So as long as you are trying to use this for the same user model that is being used by laravel via auth.php
you should be in business.
Feel free to take a look at the PR for reference https://github.com/JeffBeltran/sanctum-tokens/pull/9
:tada: This issue has been resolved in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Hello I am using Laravel sanctum on model different that the nova logged user. Is it possible to add a key in the config to specify wich model we want to using ?
I'm not sure i understand your question. But to clarify, if the model your nova resource is using is setup with the HasApiTokens
trait simply adding the SanctumTokens::make()
to your nova resources fields key will make it show up for that nova resource. if this doesn't work for you could you please expand on what you are trying to do?
https://github.com/JeffBeltran/sanctum-tokens/pull/9/commits/174aa23445cfce0888ecc2e650a0f40181192d9e You are relying on the nova logged user to manage the token. But in some cases (and mine) we attach the token to another entity
that's an older commit and how it was originally handled, it has since been changed via PR #16 to allow any model that is configured for sanctum. If you follow the steps above, does that not work for you?
i've got a 401 on the sanctum-token api route. But it may not come from the package itself then. thank you
no problem, i took a quick look to see if there is a reason this should happen but i don't recall adding any gates/policies for this tool... i would be curious why you are getting that though since the api route should be name spaced correctly and not have any collisions
Quick follow up.. we discovered what was causing this, it was a custom conf by our end that check nova path to logout some other guard. This conf wasn't taking into consideration the nova-vendor
path used by the package to create/get the tokens. So the route returned 401
.
ah ok cool, so if i understand this the issue was caused by the custom config you created and not associated with a change we made?
Yes exaclty
Currently the package assumes
App\User
is the user entity, breaking when we customize such class or namespace.Would be great to be able to customize this through configuration.
Currently there is a "hacky" workaround though, in case it helps someone: