Replies: 2 comments
-
|
Hey @darkons, don't worry at all, there's no such thing as newbie questions here 😀 I apologise because I haven't got around to fully documenting the Client Credentials grant - but from your message I assume that you've worked out the trait that you needed to get it to work. With regards to the separate connectors - this was a recommendation I came up with based on the fact that in my experience the URLs are different to authenticate, so I wanted to make it easy for people to use different URLs. That being said, if it shares the same URLs you don't need a separate connector. Additionally, you can provide the full request URLS in the OAuthConfig class if the URLs are different (so I probably don't need to recommend two different connectors!) Secondly around the retention of access tokens - it's recommended that you store the authenticator somewhere secure, like in a database column against your user. The authenticator can be serialised so you can easily convert it into a string and back into an object to be used. $serializedData = serialize($authenticator)
unserialize($serializedData)Are you using a particular framework like Laravel? If you are then there is a little suggestion in the documentation on how you can write the instantiating of the connector, pulling your authenticator from your storage, then checking if it has expired and then authenticating. See an example here: https://github.com/Sammyjo20/saloon-v2-spotify-example/blob/72112578e1dcc7e10fbebf4c9e6d2b4b93fee848/app/Models/User.php#L61 Please let me know if you can think of any ways to improve this - as I am currently working on version 3 of Saloon, so if there's anything I can improve I'd be happy to! Hope this helps so far :) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much for your help Sammy! You have helped me clarify many of the doubts I had. So far, the package seems pretty easy to use, but to be honest, the Authentication part can be a bit tricky when separating the Authenticator classes from the OAuth2 authentication. Perhaps merging together in a way that is simpler and more unified since both are referencing to Authentication concept. On the other hand, regarding the authenticator storage, storing in the User model is fine when using Authorization Code Flow because each user have his own credentials/token but not in Client Credentials since this grant is not user related. I am going to create a service class to handle this in a similar way to the user's example but storing in another table like Thank you! :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
First of all, congratulations for this great package @Sammyjo20 !
Sorry for the newbie question, but despite having read several times the official documentation, I can't find a way to properly implement a client credentials flow in a Laravel app.
The questions are:
At the moment, whenever I want to call the API, I use the following code but, as I said before, this generates a new token on each request. Also, it is a bit tedious to have to instantiate both the AuthConnector and the ApiConnector on each request.
Thank you very much and again I am sorry for these novice questions.
Beta Was this translation helpful? Give feedback.
All reactions