Support for Matching Multiple Paths Using Lists

[dadrus]

Preflight checklist

• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines."
• I have discussed this feature request with the community.

Describe the background of your feature request

While PR #1358 improved rule matching by making the configuration more versatile and enhancing performance, it left some open challenges. The new approach is flexible, but it can become cumbersome and inefficient when matching multiple distinct paths, leading to repetitive and verbose rule definitions. This issue can also impact performance, especially when complex glob patterns are involved.

Consider the following example:

match:
  path: /identity/**
  with:
    path_glob: >
      {/identity/.well-known/home,
       /identity/recovery,
       /identity/login,
       /identity/logout,
       /identity/register,
       /identity/activation_pending,
       /identity/activate_account,
       /identity/account_activated,
       /identity/**.css,
       /identity/**.js,
       /identity/**.ico}
    methods: [ GET, POST ]

While matching /identity/** benefits from the radix tree’s speed, the additional glob expressions can diminish this advantage.

Here another negative example:

match:
  path: /api/.ory/admin/**
  with:
    path_regex: api/.ory/admin/(?:(?:courier/messages(?:/?(?<id>[-0-9a-fA-F]+))?)|(?:identities(?:/?(?<id>[-0-9a-fA-F]+))?(?:/?sessions)?)|(?:sessions(?:/?(?<id>[-0-9a-fA-F]+))?))

which is not readable at all.

Describe your idea

Supporting multiple paths using a list format in the match section would be highly beneficial. This feature would enable users to define multiple distinct paths more concisely and efficiently, preserving the performance advantages of radix tree lookups while also improving the readability of the rules.

Possible implementation options

Option 1: Enhanced Path List with Inline Globs

This option allows defining paths directly as a list, with an inline glob expression where necessary.

Here an example based on the first example from above demonstrating the challenges

match:
  paths:
    - /identity/.well-known/home
    - /identity/account_activated
    - /identity/**<*.css,*.js,*.ico>
  with:
    methods: [GET, POST]

This approach keeps the configuration compact but can become unreadable with complex glob patterns. Additionally, it does not support regular expressions, as there's no straightforward way to specify whether to use regex or glob patterns.

The scope of the glob expression is limited to the scope of the wildcard.

Option 2: Path Object with Optional Configuration

This option uses a more verbose structure, where each path can optionally include a optional properties.

match:
  paths:
    - path: /identity/.well-known/home
    - path: /identity/account_activated
    - path: /identity/**
      with_glob: "*.css,*.js,*.ico" # or with_regex
  with:
    methods: [GET, POST]

While it’s more explicit and easier to understand at a glance, it may introduce unnecessary verbosity for simpler configurations. It is also harder to implement compared to option 1.

As with the first option the scope of the glob or regex expression is limited to the value matched by the wildcard.

Are there any workarounds or alternatives?

Use the current approach. :) Split rules with complex expressions into separate ones with simpler expressions. This would however lead to rule explosion.

Version

dev

Additional Context

No response