Allow the use of the API token by adding Authorization header

[khawarizmus]

Is your feature request related to a problem? Please describe.

Allow the passage of an API token when using useStrapiX. this is related to #233 which provides a workaround but not an optimal solution.

Describe the solution you'd like

add an optional parameter to passed and used as an api token. ideally at the initialization phase.

const { find } = useStrapi4(token)

which would translate to useStrapiClient also having an optional token param as it's used under the hood

const client = useStrapiClient(token)

Which then leads to having to changing this part:

export const useStrapiClient = (apiToken?: string) => {
  const nuxt = useNuxtApp()
  const baseURL = useStrapiUrl()
  const version = useStrapiVersion()
  const token = apiToken ? apiToken : useStrapiToken()

Describe alternatives you've considered

another alternative is to pass it via the config object but then we will have to make a mechanism to switch between using the cookies or the api token and add a default behaviour which can also be controlled via the options

example:

// options
strapi: {
  url: process.env.STRAPI_URL || 'http://localhost:1337',
  prefix: '/api',
  version: 'v4',
  api_token: process.env.STRAPI_TOKEN,
  use_token: true, // default behaviour
  cookie: {},
}

Then instaid of passing a token argument to theuseStrapiClient or the useStrapi4 we would pass an argument to tell us if we should override the default behaviour of use_token

Additional context

Happy to hear feedback and create the necessary PR with the right guidance.

[TJacoob]

I think this would be a very helpful feature. For simple use cases, where one just wants to add some soft protection to the contents of the API, the described alternative proposed by @gimyboya would be perfect.

[khawarizmus]

@TJacoob would you prefer the first approach or the second one? I haven't put a PR in place because I am waiting for the maintainers to feedback to see which direction the effort should be

[TJacoob]

Personally I would use it as in the second approach, as a part of the module settings.

But I can see how some others could prefer to use it on a case-by-case basis, especially on more complex projects. I think your first suggestion is more flexible for such cases.

I think the ideal solution would be a merge of both. If I have the token on the settings I wouldn't need to pass it to the useStrapi4 function. If I just want to use it on specific requests I wouldn't need to specify it on the settings, but would be able to pass it as an argument when needed (or at least be able to override the "global" token to make a unauthenticated request for some reason).

[Psychokrameur]

Hello, I was also looking for a solution like this and I agreed with @TJacoob, both case can happen and would be usefull

[TJacoob]

@benjamincanac any opinion or update on this issue?

[jiblett1000]

I'm going to take a crack at implementing this. I'll post back if I get PR done.

[jiblett1000]

Hello again all,

I'm looking back at implementing this. Hoping to get some feedback. The more I think about it, I think it would make sense to just be able to pass an entire config object rather than just the token. Something like:

const client = useStrapi({
  url: process.env.OTHER_STRAPI_URL',
  prefix: '/other-prefix',
  version: 'v3',
  api_token: process.env.STRAPI_API_KEY,
  cookie: {},
})

Props would be optional and merged over options set in nuxt.config (and defaults). This would allow significantly more customization per useStrapi instance while maintaining the current behavior when called with no options.

I'm thinking the use of custom version will create the most issues and require the most refactoring within the module. I feel that it would be pretty uncommon to set this per useStrapi instance, but I can imagine a scenario where one client is accessing multiple strapi instances with varying versions.

This would mostly eliminate the need for useStrapiClient (at least for developer use), while allowing the use of the useStrapi methods { find, findOne, create, update, delete } on custom endpoints.

I'm wondering if any of this would be useful to others. At the same time, I also wonder if this is doing too much and at what point does it make sense to just use fetch directly. Overall, I think the module provides enough functionality that these changes would be worthwhile and perhaps ease some current pain points in terms of customization.

Anyways, hope to hear from you!

[TJacoob]

@jiblett1000, your solution seems elegant and should cover most use cases. I think it's very important to make the props optional to prevent clutering the code with unnecessary options. Whenever used, the options would override whatever was defined in the module configuration.

I understand the logic behind having the version as a prop, but don't know if it would very used or not. Personally I don't access multiple strapi instances in any project, but I can see it being useful for migrations (from v3 to v4) for example.

[jiblett1000]

@TJacoob Thanks for the response! Yes, the options would most definitely be optional. I don't want to create more work for anyone :) . Especially for simpler projects, setting defaults in nuxt.config should be enough.

[lobermann]

Would really need this feature and love to see it available. Are you still planning to PR this @gimyboya ?

[jiblett1000]

I'm back working on this again. If you have any thoughts, ideas, concerns, feel free to chime in. Particularly, if you have interest in being able to use any other custom config options per composable instance (e.g. baseUrl, prefix, version, etc). The most important is the apiKey, but I would like to open up the functionality to allowing easier access of multiple strapi instances from the same client or things of that nature if there is interest.

I would also appreciate feedback in this regard; The way I'm currently reworking things is to not use the user token by default (if the user is logged in). I feel this causes inconsistent behavior and passing the user token for requests you might not want to use that (or any) token on. For example, the user token doesn't need to be passed on public content (marketing pages for example). Instead, I currently have it so if the api token (key) is set in the module config, it will be used for requests unless a token is passed to the composable. This custom token could be the user token. For example:

const userToken = useStrapiToken()

const { findOne, update } = useStrapi({ token: userToken })

I feel this would be a better default and wouldn't require a significant increase in work to pass the user token. That being said, I've considered the possibility of adding another module config ("defaultToken" for example) that could essentially allow the current behavior of using the user token by default. This could be useful for an app where most of the requests are authenticated requests rather than public content.

Hoping to get this done fairly soon. So again, feel free to chime in. Cheers!

[benjamincanac]

A PR has been made by @jiblett1000 #326 to support this; however, as explained here #326 (comment) I don't see the point of using API tokens in the module as they will be visible to everyone through headers, so no longer private. If you expose an API token to your users, it comes down to the same thing as making your routes public.

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.

Does someone have a particular use-case to use API tokens client-side or am I missing something?

[benjamincanac]

Closing this because no answer was provided and it can be achieved easily doing this:

const client = useStrapiClient()
await client('/restaurants', {
  headers: {
    Authorization: process.env.STRAPI_API_TOKEN
  }
})