Is the option api_token implemented ?

[bnbc]

Hello, i have read this issue : https://github.com/nuxt-modules/strapi/issues/254

And i want to know if an option to set Strapi api token is now available ? i don't see it in the documentation.

Meanwhile i will use useStrapiClient, like that (not tested) :

const client = useStrapiClient()

await client('/articles', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer ' + token,
  }
})

[jiblett1000]

@bnbc I've opened a PR. Still waiting to hear back.

https://github.com/nuxt-modules/strapi/pull/318

[benjamincanac]

Hello @bnbc,

I've given feedback here https://github.com/nuxt-modules/strapi/issues/254#issuecomment-1457993508 and here https://github.com/nuxt-modules/strapi/pull/326#discussion_r1127657814, could you please explain your use-case for this feature?

[bnbc]

Hello @benjamincanac

Instead of doing that :

const runtimeConfig = useRuntimeConfig()
const client = useStrapiClient()

const articles = await client<Strapi4Response<Article>>('/articles?populate=*', {
    method: 'GET',
    headers: {
        'Authorization': 'Bearer ' + runtimeConfig.strapiToken,
    }
})

I just feel better to have possibility to set a api_token option:

strapi: {   
        url: process.env.STRAPI_URL,
        apiToken: process.env.STRAPI_TOKEN,      
},

And use basic calls of your module like that :

const { find } = useStrapi()
const response = await find<Article>('articles')

Nice job !

[benjamincanac]

@bnbc Why would you use an api token to fetch your articles? Can't you just set the articles.find permission to Public?

[bnbc]

Ok i'm new on Strapi (v4) and i just see how to put permissions to Public like you say.

But is not the default configuration, one of the first steps is to create an api token to protect data access. I think is a good practice, i don't want anyone can access my data api (for security reason, performance reason)

So that why i was suprised when i dont see token params in the options of your module, cause for me is mandatory (but no)

Maybe is just my opinion and my concepts but it feels logic for me :)

[benjamincanac]

We're not implementing this api token feature because if we do, your api token will be leaked and accessible to all users as it will show up in the browser request headers.

[bnbc]

Oh yes il feel stupid :/ i dont realize was so easy to get the token.

So i will protect my API access with IP rules.

Thks

[gwynhokkers]

I'm a bit confused as to why you wouldn't use the API tokens in this way? You can create them as read only - which is fine, plus how else are you meant to restrict access other than doing what @bnbc suggests and restrict by IP address? On some web app hosting we don't have access to restrict the api by ip address, plus if you dont have static ip addresses for the frontend how are you meant to do so?

[benjamincanac]

@gwynhokkers Do you have a use-case where you need an API token that won't be leaked? Maybe I'm missing something here

[wanxe]

If i'm not wrong, the API token is not exposed when use static builds. So unless the API is used to make the call at runtime, the token is not exposed. But of course... if it is restricted by IP it is much safer.

[philipimperato]

Use case:

You don't want public access to your API unless it's you who is querying it for static builds.

Isn't that what you would always use an API key?

This more or less renders this entire package useless for those who want to use an API token, unless I'm missing something.

[ChinYoung]

All entries have to be "public access" without the support for API token, as @philipimperato has metioned, at some case we need the token to authenticate before the query. And for the leaking problem, SSR is necessary when query with API token, to make the query happens at the server side.

[Mackeul]

I believe I may have a use case for implementing this feature.

We use static site generation + server-side dynamic routes for 3rd party APIs that the user would interact with (ie. Stripe payments). However, we don't want the site to have any dependencies on Strapi when it is live, hence SSG. We would also prefer to lock down Public access to Strapi completely and only allow API access via API token for security reasons.

This all works great once deployed, however to run a new build when something changes, we have no way to provide the build with the api token so that it can fetch the data to create the static pages. The only way for the build to work is to have Public access to the data it tries to retrieve enabled. I've tried adding apiToken to the strapi section of nuxt.config.ts, but that didn't seem to make any difference and given this discussion, it doesn't seem to be possible? Maybe there is a way to do this that I haven't found yet?

So the desired behaviour I am looking for is to have a way to provide the build with the necessary API token for it to fetch Strapi data and populate the static page, and then once deployed the token information is not part of the static page at all and therefore not at risk. Hope this all makes sense.