-
Notifications
You must be signed in to change notification settings - Fork 81
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
feat: api token, default token #326
Conversation
✅ Live Preview ready!
|
headers.Authorization = `Bearer ${options.token}` | ||
} else if (config.strapi.defaultToken === 'user' && userToken.value) { | ||
headers.Authorization = `Bearer ${userToken.value}` | ||
} else if ((config.strapi.defaultToken === 'api' && config.strapi.apiToken) || config.strapi.apiToken) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure defaulting to the config.strapi.apiToken
is the right thing to do here? For example if I set an apiToken
to use in a specific section of my app, I might not want to use it all the time when a user is logged out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benjamincanac I wan't entirely sure which way to go with it. My thinking with it this way was trying to avoid cluttering the module config with too many options considering that a token can always be passed to the composable(s).
But, I was considering maybe adding an additional boolean config (privateApi
) or something) to allow someone to set whether to use the apiToken
in their config as the fall back if the jwt isn't set. This might be beneficial to someone who doesn't want their API public. I'm not against that, if that works for you. It could be this instead:
headers.Authorization = `Bearer ${options.token}`
} else if (config.strapi.defaultToken === 'user' && userToken.value) {
headers.Authorization = `Bearer ${userToken.value}`
} else if ((config.strapi.defaultToken === 'api' && config.strapi.apiToken) || (config.strapi.privateApi === true && config.strapi.apiToken) {
I'm not sure that privateApi
is the best name for that, but just a spur of the moment idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering, why would you use an api token in your app instead of just using a public endpoint? As this http call will be client-side, all users will be able to see this token so it comes to the same thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, yeah. Potentially, a bit of a misconception on my part. I'm sure you would know better than I. Most of my understanding is just from some articles rather than a wealth of experience. Such as:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry it took so long to catch up, but the only use-case I see to use api tokens in nuxt is if it's used server-side as these tokens are private. However, as mentioned here #320 (comment), the module does not export server functions as of right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries. I appreciate you bearing with me as I get up to speed myself :) What you're saying makes total sense. I think there might still be something of value here in terms of customizing the default behavior of the composables. Not in relation to api tokens, but rather maybe not passing the jwt to particular instances of useStrapi
and useStrapiClient
? Or maybe not, lol. It's super late here and I think my brain is giving up for the night. I'll close this PR for now and give it another think tomorrow. Thanks again!
Types of changes
Description
This is just a redo of my previous PR (#318) which I somehow managed to completely bork.
Checklist: