Once the model is cached, auth is neglected

[divyagowda]

Hi,

I integrated the strapi middleware cache to my project and added the model like categories. Below is my cache settings in middleware.js under config
cache: {
enabled: true,
type: 'redis',
maxAge: 3600000,
models: [
{
model: 'Categories',
maxAge: 1000000,
}
],
populateStrapiMiddleware: true,
logs:true
}
First time when GET /Categories api is invoked it asked for bearer token. Next time when it is cached authentication is totally ignored. If I remove auth header no forbidden message is shown instead data is returned giving access to anybody with api. Am I missing any steps? How to overcome this problem so that cache middleware is not invoked before auth is verified.

[patrixr]

Hi @divyagowda

The middleware was historically used to cache public data, so an authentication feature did not exist.

Some external contributions have added header-based cache key, (e.g on the bearer token) for their own usage (feels weird to me as it would create one cache key per user).

The theoretical approach to this problem would be to use middleware ordering to make sure the authentication middleware are triggered before the cache one.

The users-permissions plugin actually exposes a middleware, which could be placed before the cache. However upon inspection of that middleware, all it does is add policies. And policies, sadly, are triggered after all the middlewares take effect.

I wish it would work, in the meantime I've experimented with actual authentication myself before, I've just pushed that experiment here : https://github.com/patrixr/strapi-middleware-cache/compare/authentication
It basically triggers the policy manually. I'm considering releasing it, but it's a bit hacky. Inputs are welcome

[patrixr]

Note you can try the branch above by running npm install strapi-middleware-cache@1.5.0-beta.0

[divyagowda]

Note you can try the branch above by running npm install strapi-middleware-cache@1.5.0-beta.0

cache: {
      enabled: true,
      type: 'redis',
      maxAge: 3600000,
      models: [
        {
          model: 'Categories',
          maxAge: 1000000,
        }
      ],
      // models: ['Category'],
      populateStrapiMiddleware: false,
      checkPermissions:true,
      logs:true
    }

I tried this. But still I see same behavior. "http://localhost:1337/categories" this I can access without any authentication. Am I missing any steps?

[derrickmehaffy]

I'm guessing in this case it's due to the middleware being executed before the users-permissions is being run. I have in the past tried to load the cache middleware before the users-permissions middleware here: https://github.com/strapi/strapi/blob/master/packages/strapi-plugin-users-permissions/middlewares/users-permissions/index.js

I'll have to try and do some more testing, but effectively the cache middleware returns values before users-permissions can run (it's middleware and the policies which are effectively scoped middleware) the end goal would be to run the cache response after all the users-permissions actions.

[patrixr]

@derrickmehaffy you're spot on

It feels to me like the middleware load order configuration should be the way to handle this.
But the users-permissions middleware doesn't actually behave like a middleware, rather it looks more like plugin initialization code.

Could we create another middleware that triggers the policies ?

When trying to call the policies, I noticed they require ctx.request.route, currently looking for the code that sets this, I faked it by creating it myself in the branch I posted above

[derrickmehaffy]

I've always had trouble with that too while working on some small custom middlewares.

Let me tag @alexandrebodin just to get his thoughts, but if he has a little free time on Monday or Tuesday I'll try and pull him into a call and pick his brain.

[derrickmehaffy]

The policies make it difficult simply because they are only called once the route is parsed and the users permissions plugin is called. In this case we want the cache to intercept what normally would be the controller (then service, then query, then database) and return what the controller would.

In this way both the before and after actions of the policies would run (those two differences are based on if code falls before or after the next() function of a policy)

[divyagowda]

So there is no way to get through this for now? I mean I cannot use if I need caching with authentication?

[patrixr]

@divyagowda For the meantime I'm afraid it can only be used for public data

[stafyniaksacha]

Hello there, this issue is related to the hitpass point that I speak about in the #43 PR

[stafyniaksacha]

@derrickmehaffy @divyagowda you can test the beta branch with strapi-middleware-cache@beta package tag !

[derrickmehaffy]

Tested with the latest release (of the middleware and Strapi) and the issue still exists even with that PR @stafyniaksacha.

The main issue is due to how to middlewares are loaded, will need to play around and see if there is a way to load this middleware after the users-permissions one. The alternative would be to have this middleware check the incoming JWT (if exists), parse the user, then check the permissions but that is quite complex and will be even more so with the Strapi v4 since we are making the users-permissions plugin optional in the v4 (the default will become the API tokens)

[stafyniaksacha]

@derrickmehaffy I think we can achieve the goal with two steps:

• handle Cache-Control header content from response
• be able to alter cache key, so we can add user ID/Token (or a flag to distinguish logged from anonymous content)

With this way, I think it will be OK with Strapi V4

Concerning Strapi V4, is a closed alpha is scheduled for partners/plugins developers?

[derrickmehaffy]

@derrickmehaffy I think we can achieve the goal with two steps:

• handle Cache-Control header content from response
• be able to alter cache key, so we can add user ID/Token (or a flag to distinguish logged from anonymous content)

With this way, I think it will be OK with Strapi V4

Concerning Strapi V4, is a closed alpha is scheduled for partners/plugins developers?

Yes there will be a closed Alpha starting most likely after next week. Send me an email at community@strapi.io.

I'll be on vacation next week but the following if the alpha is released I can loop you in.

[derrickmehaffy]

Hey all, just a heads up. I've been talking with some of the backend engineers about auth with this middleware and we have some ideas but it will have to wait for v4 to be implemented.

I am certainly going to put a bit of a focus on seeing how we can implement auth with this as I really thing this package could be very popular and useful to all Strapi users.

Once we have a bit more information I can share my thoughts for the future.

---

Regarding the reasons why it currently doesn't work I need to explain how the current auth system works:

Effectively the way we handle auth on all routes is via this middleware: https://github.com/strapi/strapi/blob/master/packages/strapi-plugin-users-permissions/middlewares/users-permissions/index.js

This middleware is designed to automatically inject this policy into every route: https://github.com/strapi/strapi/blob/master/packages/strapi-plugin-users-permissions/config/policies/permissions.js

The reason why auth is not functioning is because the middlewares are called before the policies get executed. The original suggestion from my backend eng team is to replicate this method and have the core middleware build a policy that is used and push that after the users-permissions one.

However in the v4 our policy system will change and we will also introduce a new middleware system with a call stack basically like this:

• Core Koa Middlewares
• Global Strapi Middlewares
• Route Policies
• Route Middlewares

Effectively in the future this middleware should inject on that route middleware so that it's called at the right time. Once Strapi v4 goes into public beta we can start playing with this a bit more.