Is the option api_token implemented ?

[bnbc]

Hello, i have read this issue : #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.

#318

[benjamincanac]

Hello @bnbc,

I've given feedback here #254 (comment) and here #326 (comment), 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.