Allow the use of the API token by adding `Authorization` header

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.

[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!

[jiblett1000]

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