Feature request: allow for more flexible middlewares #93

New Issue

GiteaMirror · 2025-11-13T11:49:49-06:00

GiteaMirror commented

2025-11-13 11:49:49 -06:00

Originally created by @renzos42 on GitHub (Feb 16, 2025).

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:

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

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.

Originally created by @renzos42 on GitHub (Feb 16, 2025). 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.

GiteaMirror closed this issue

2025-11-13 11:49:49 -06:00

GiteaMirror commented

2025-11-13 11:49:50 -06:00

@miloschwartz commented on GitHub (Feb 16, 2025):

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.

@miloschwartz commented on GitHub (Feb 16, 2025): 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: ```yaml 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.

GiteaMirror referenced this issue

2026-04-16 07:55:21 -05:00

[GH-ISSUE #93] Feature Request: Temp. Blacklist Source IP on X invalid login attempts for PIN/Password #1283

GiteaMirror referenced this issue

2026-04-20 07:08:38 -05:00

[GH-ISSUE #93] Feature Request: Temp. Blacklist Source IP on X invalid login attempts for PIN/Password #3225

GiteaMirror referenced this issue

2026-04-25 14:56:14 -05:00

[GH-ISSUE #93] Feature Request: Temp. Blacklist Source IP on X invalid login attempts for PIN/Password #6079

GiteaMirror referenced this issue

2026-04-30 03:28:56 -05:00

[GH-ISSUE #93] Feature Request: Temp. Blacklist Source IP on X invalid login attempts for PIN/Password #8047