Feature request: allow for more flexible middlewares

[renzos42]

Hi, I'd like the ability to not apply all optional middleware to all sites. There are cases like ForwardAuth which will be very site specific. There is no good way to achieve this at the moment. I think this feature would add a great deal of flexibility.

Atm I can think of two ways to solve this:

1. Define middlewares in the UI (name and textfield config), store them in the database, write them out to the dynamic dir, and provide a list in the resource settings (and hide the badgerMiddlewareName name).

• Pro: Very user friendly
• Con: More involved to implement
• Con: Error prone due to user errors

2. Scan the dynamic dir for extra files (maybe with a naming convention), and provide these in a list in the resource settings (and hide the badgerMiddlewareName name).

• Pro: Pretty easy to implement
• Neutral: It would be a somewhat more 'advanced' hidden feature (if there are no extra middlewares, there would be nothing to select).
• Con: File detection based on naming conventions or on expected values, is a bit jank.

The new access control rules cover some of the use-cases (which look super nice btw), but can never really cover the full flexibility of traefik itself (nor should it). For our case, having this missing means I cannot migrate due to some sites special config rules.

Would be great to hear any opinions on this.

[miloschwartz]

Hi, I think you're right this would be easy to implement and useful for some advanced users. What do you think about being able to define them in the config.yml instead of the UI for now?

Every resource has an ID which can be easily found in the URL: https://pangolin.domain.com/my-org/settings/resources/2/connectivity (resource ID is 2 in this example). We could add a section to the config.yml that lets you define middleware per resource based on the ID. Maybe something like:

resources:
  2:
    middleware: ["geoblock"]
  3:
     ...

Let me know what you think. Obviously a slick UI implementation would be best but this would expose the functionality and be quite easy for us to get out there and then improve upon later.