Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow authenticating auth routes with existing token instead of requiring a clientId and clientSecret #58

Open
colin-oos opened this issue May 18, 2023 · 2 comments

Comments

@colin-oos
Copy link

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch @boxcast/boxcast-sdk-js@2.0.2 for the project I'm working on. I wanted to be able to use the sdk in node.js but I am using OAuth tokens rather than a clientId:clientSecret pair to authenticate. Currently your SDK only accepts a clientId and clientSecret to authenticate and generate a token, however since I already have a token I want to be able to just pass my existing token as the first argument. I expect this would be something others would need to be able to do as well so I decided to create this issue for further review.

Here is the diff that solved my problem:

diff --git a/node_modules/@boxcast/boxcast-sdk-js/src/api/auth_routes.ts b/node_modules/@boxcast/boxcast-sdk-js/src/api/auth_routes.ts
index 13600b7..1714ae3 100644
--- a/node_modules/@boxcast/boxcast-sdk-js/src/api/auth_routes.ts
+++ b/node_modules/@boxcast/boxcast-sdk-js/src/api/auth_routes.ts
@@ -21,7 +21,13 @@ export default class AuthenticatedRoutes {
     STATE.lastAuthToken = null;
   }
 
-  async authenticate(clientId, clientSecret) {
+  async authenticate(clientId, clientSecret?) {
+    if (clientId && !clientSecret) {
+      STATE.lastAuthToken = clientId;
+      return {
+        access_token: clientId,
+      }
+    }
     try {
       const body = new URLSearchParams({
         'grant_type': 'client_credentials',

This issue body was partially generated by patch-package.

@hutch78
Copy link

hutch78 commented May 23, 2023

@colin-oos Hi Colin! My pleasure, it has been a fun project so far ^_^.

I like your suggestion of enabling the SDK to use a passed-in token instead of being forced to grab a new one just to store it in STATE. That said, rather than modifying the authenticate() method, I think we should keep authenticate() doing just that, and adding a setToken method that can be called when we already have a token. How does that sound?

If you like the idea, we can look at getting it into the next release of the SDK. In the mean time, feel free to submit a PR.

Thanks for the feedback!

@colin-oos
Copy link
Author

Yeah that makes sense. I'll submit a PR when I get a chance. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants