Unlimited token or no token for read-only?


#1

regarding this question How to deal with expiring tokens
I have a similar issue:
I’d like squidex to serve data for my client-side JS. Since I can’t let secrets inside the JS client, I would require to have another server to oauth for my client…

So my question is: is it possible to have an unlimited token for readonly or an option to GET data without any token at all?

Thx


#2

Hi @goldo,

writing a proxy sounds like a good idea for me. So far there is no token that is valid forever but you can request the token as often as you want.

The .NET client library has a custom http client handler that removes the token on 401:


#3

Thanks for your answer, but this seems a bit too much for simple, small apps, blogs or static websites


#4

I am still not sure myself about this point. Permanent api keys have been requested several times. Squidex uses openid connect for authentication, which is a proven a secure model and I wanted to avoid it to create a second authentication flow. I don’t know which backend technology you use but if you just cache the token in memory and delete in on a 401 you can create a helper function with a few lines of code. I give you a professional plan for free for a month if it is more than 20 lines of code :wink:

Unfortunately there is also no simple solution for the javascript problem. As an alternative you can create a client with read permissions only and just expose the client secret in your webapp.


#5

That’s the point, I wasn’t planning on using a backend.
Exposing the client secret inside the client is equivalent to giving read/write access to all the DB.
It means I have to make a backend which generates an api key and redeploy my static website with that kay inside everymonth. Way more than 20 lines :slight_smile:
But what if you added an option to open selected datas in read-only, so they wouldn’t require an access token to get ?
From my side, I’ll think about making a backend…


#6

Why do you have to generate a new api key manually?

Squidex distinguishes between clients and api tokens. A client is valid forever and you acquire a token in the name of a client. So you can write a helper method like this in your server or frontend:

var cache = new MemoryCache();

public string MakeRequest(string url)
{
    var accessToken = cache.GetOrAddAsync("Token", TimeSpan.FromDays(20), () => {
         return GetAccessToken();
    });

   var response = MakeRequest(url);

    if (response.StatusCode == 401)
       cache.Remove("Token");
       throw ...;
    }

    return response.ReadAsString();
}

If you create a client you can also define the role. The default role Reader has permissions to read all contents and assets, but cannot create, update or delete content or assets.

Futhermore you can create a custom role, e.g. if you only need read permissions to articles, and blog, you can give this role the following permissions:

  • schemas.blog.read
  • schemas.articles.read

More about permissions in the docs: https://docs.squidex.io/concepts/permissions


#7

My client is my frontend website. I don’t want it to have to renew its token. Since its client-side JS only, it means it has to get a token for every visitor.
If I manage to generate the token server side, it would be no problem, but currently I can’t use squidex without another backend to handle the client token


#8

Sry, I cannot help you more at the moment. Personally I do not see a big problem to get the token in the frontend. It is a small performance impact for sure, but I think it is acceptable.


#9

So If my website has 100K unique users/browser per month, it will generate 100k token, right ? That seems a lot :frowning:


#10

From which perspective? The tokens are not stored anywhere, they are just generated. And it is only one token every 30 seconds :wink: