ctx altered in route middleware is retained on subsequent calls

[Eli-Nathan]

Bug report

Required System information

• Node.js version: 18
• Strapi version: 4.9.2
• Database: MySQL
• Is your project Javascript or Typescript: JS

Describe the bug

A few months back I tried enriching an endpoints default populate behaviour using a route middleware and mentioned it in this comment on a Strapi forum thread.

I've since found an issue in which this request context is shared between subsequent api calls.

For example. If i wanted every request for books to return the author relation without having to worry about providing it in the query string:
Books Router config: /api/book/routes/book.js

module.exports = {
  routes: [
    {
      method: "GET",
      path: "/books",
      handler: "book.find",
      middlewares: ["populate-books"]
    },
    // ... more routes (with the same middleware if you want)
  ]
}

And then in /api/book/middlewares/populate-books.js:

const populateList = ["author"];

const enrichCtx = (ctx) => {
  if (!ctx.query) {
    ctx.query = {};
  }
  const currentPopulateList = ctx.query.populate || [];
  ctx.query.populate = [...currentPopulateList, ...populateList];
  return ctx;
};

module.exports = (config, { strapi }) => {
  return async (context, next) => {
    const newCtx = enrichCtx(context);
    context = newCtx;
    await next();
  };
};

This isn't too harmful for populate enrichment but when i try to set pageSize:

const enrichCtx = (ctx) => {
  if (!ctx.query.pagination) {
    ctx.query.pagination = {};
  }
  ctx.query.pagination = {
    ...ctx.query.pagination,
    pageSize: ctx.query.pagination?.pageSize || 100,
  };
  return ctx;
};

And then subsequently request a different endpoint like authors and provide pagination.limit in the request query, I get a 400 error because the request ends up with both limit and pagesize which isn't allowed.

Is it expected behavior to have the ctx retained between API calls?

Steps to reproduce the behavior

1. Add a middleware that enriches the ctx for a single endpoint
2. Add middleware to middlewares.js config file
3. Make a request to this endpoint
4. Make a request to another endpoint and log the ctx in the controller
5. Observe combined ctx for both requests

Expected behavior

Applying a middleware to a route only applies to that route

Screenshots

If applicable, add screenshots to help explain your problem.

Code snippets

If applicable, add code samples to help explain your problem.

Additional context

Issue briefly described here

[strapi-bot]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/discussion-regarding-default-population-of-rest/13395/33

[GregorSondermeier]

I cannot reproduce this. However I think the issue is because of this:

2. Add middleware to middlewares.js config file

By doing that, you're effectively registering your middleware globally to be executed on every request. You don't need to do that, and you actually don't want it in your case.
Your book specific middleware already exists and is ready for usage just because the file api/book/middlewares/populate-books.js exists. You can add it to your book route and that suffices already :)

[Eli-Nathan]

Ah okay! I'll try removing from there!

Wonder if the docs need an update as they state regarding custom middlewares:

Once created, custom middlewares should be added to the middlewares configuration file or Strapi won't load them.

[Eli-Nathan]

Actually just tried this and without the api::api-name.middleware-name middlewares in that file, they aren't applied on the request 🤔

[GregorSondermeier]

Wonder if the docs need an update as they state regarding custom middlewares:

Once created, custom middlewares should be added to the middlewares configuration file or Strapi won't load them.

Yeah that's definitely a false statement. Middlewares added to the middlewares configuration file are applied to all routes.

Actually just tried this and without the api::api-name.middleware-name middlewares in that file, they aren't applied on the request thinking

Provide the full identifier in your route definition and only there:

// /api/book/routes/book.js

module.exports = {
  routes: [
    {
      method: "GET",
      path: "/books",
      handler: "book.find",
      middlewares: ["api::book.populate-book"] // instead of just 'populate-book'
    },
  ]
}

[Eli-Nathan]

Just tried that and the middleware doesn't seem to run 😞

I've created a mini repo to reproduce
https://github.com/Eli-Nathan/strapi-ctx/

If I add the middlewares: ["api::author.enrich-author"], to the route, nothing happens and the middleware is never executed.

If I add it to the middlewares.js file and provide the global name in the route then it's like you said and it's applied across all requests.

[Eli-Nathan]

So the main branch on that repo has your last suggestion on it.

I've added a global-middleware branch where I've added it to the middlewares.js config file like I had originally.

I've found a solution that sort of works by following this guide and adding the function directly into the routes[0].config.middlewares array

I've added that to the direct-middleware branch. Is this the best way to do this?

Feels like it's not as extendible as being able to provide a middleware name and have it apply to any route you choose.

[GregorSondermeier]

@Eli-Nathan I wasn't fully paying attention when I was giving your my last code snippet (copy/paste^^). I just noticed: You have to wrap the middlewares property in config in your route definition:

// /api/book/routes/book.js

module.exports = {
  routes: [
    {
      method: "GET",
      path: "/books",
      handler: "book.find",
      config: {
        middlewares: ["api::book.populate-book"],
      },
    },
  ],
};

This explains why your routes[0].config.middlewares trick worked.

[Eli-Nathan]

Nice! I probably should have figured that out when I tried the config block 🤦

Thanks very much for your help!

I've submitted this PR to the docs to add some clarity around that in case it helps someone in the future

[GregorSondermeier]

yw