Replies: 1 comment
-
|
I just found that Trakt API supports the PKCE workflow and I'll try to authenticate using that flow which doesn't require any client secret to be maintained and hence the no. 2 way is possible. I am still open to any suggestions if any better approach is possible. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I am currently developing a CLI tool completely in Bash which will utilize the Trakt API. I would like to know how I should handle the client secrets (Client ID and Client Secret) in this script.
I've thought of two approaches:
1. User is responsible for providing the secrets
This approach is already being used by this project which is a CLI tool written in Go. It asks the user to create a Trakt app and then provide the client secrets.
2. User just authorizes
In this approach, there is only a single Trakt app which is created by the developer (i.e. me) who is responsible for maintaining these secrets. With this approach, the problem lies in the fact that how do we manage these credentials in our Bash script.
I mean the script will be publicly visible (and so our credentials).
I would like to know everybody's opinion on which approach I should use and the pros and cons for each of them.
Beta Was this translation helpful? Give feedback.
All reactions