fix: allow * usage in endpoint pattern

[eminaktas]

Hello,

I noticed that the current regex pattern does not allow the use of the * character. This PR aims to enable the usage of *. In the Gin framework, the /endpoint/*any pattern allows routing traffic to the same endpoint regardless of the rest of the path.

If there is a specific reason for disallowing this usage, please let me know. However, I believe that allowing this flexibility would be beneficial.

Thank you.

[alombarte]

Thank you very much for your contribution.

We will not be able to merge this feature request into the main codebase as it is, but we are open to doing it with a different approach. The reason for disallowing the asterisk was an architectural decision we took in the early days.

The primary reason for this decision is that allowing wildcards in endpoints introduces compatibility issues with middleware. The current architecture and middleware setup assume that all routes are explicitly defined, which is key to ensuring the highest levels of performance and security.

Moreover, implementing wildcard endpoints would lead us to treat all incoming requests as potential proxies with a no-op behavior, which significantly deviates from our design principles and the explicit routing control that Lura offers. This change could inadvertently open up security vulnerabilities, as it makes it more challenging to enforce strict access controls and validate request paths, leading to potential security risks.

We have also planned to remove the routing part from Lura because it has small adoption and it is a huge effort in the maintenance (there are routers for gin, mux, gorilla, chi, negroni...).

Lura project is committed to maintaining integrity and ensuring that we deliver a secure, efficient, and reliable API Gateway.

That said, we are always open to exploring new ideas and solutions that align with our project's objectives and architecture. The course of action to implement this feature would be to allow the invalidPattern to be overwritten in a function. Doing it this way has two immediate benefits: 1) This change would not affect current users of the library without breaking changes, and 2) opens the door to any implementor of the Lura project to set any random pattern they would consider.

If you have other suggestions or enhancements, please don't hesitate to share them. We value your contributions and look forward to possibly collaborating on other improvements in the future.

[github-actions]

Hi @eminaktas, thanks for having spent the time to code and send an improvement to Lura.

When deciding what to accept and include in our product, we are cautious about what we add, and the time our team needs to spend to have it done exemplary, considering all edge cases. As a result, we rarely add features, make changes that a tiny number of users need, or are out-of-scope of the project. For example, we might choose safety over having a specific additional feature that adds complexity we don't see crystal clear. Sometimes "less is more" because we can focus better on crucial functionality.

Although it's never nice to reject someone's work, after evaluating your code, we think it's better not to merge it or continue putting effort into it on both sides. If this PR is to solve what you considered a bug, our understanding of the functionality does not need to match your thinking. So while this pull request is now closed, this is not a definitive decision. You are free to provide additional information that would help us change our minds.

Lura is indirectly used in millions of servers every year, and the slightest change has an impact. We are doing it for all community users' benefit and to keep the code's simplicity, philosophy, and maintainability for the long run.

---

This is an automated comment. Responding to the bot or mentioning it won't have any effect

[eminaktas]

Thank you very much for your contribution.

We will not be able to merge this feature request into the main codebase as it is, but we are open to doing it with a different approach. The reason for disallowing the asterisk was an architectural decision we took in the early days.

The primary reason for this decision is that allowing wildcards in endpoints introduces compatibility issues with middleware. The current architecture and middleware setup assume that all routes are explicitly defined, which is key to ensuring the highest levels of performance and security.

Moreover, implementing wildcard endpoints would lead us to treat all incoming requests as potential proxies with a no-op behavior, which significantly deviates from our design principles and the explicit routing control that Lura offers. This change could inadvertently open up security vulnerabilities, as it makes it more challenging to enforce strict access controls and validate request paths, leading to potential security risks.

We have also planned to remove the routing part from Lura because it has small adoption and it is a huge effort in the maintenance (there are routers for gin, mux, gorilla, chi, negroni...).

Lura project is committed to maintaining integrity and ensuring that we deliver a secure, efficient, and reliable API Gateway.

That said, we are always open to exploring new ideas and solutions that align with our project's objectives and architecture. The course of action to implement this feature would be to allow the invalidPattern to be overwritten in a function. Doing it this way has two immediate benefits: 1) This change would not affect current users of the library without breaking changes, and 2) opens the door to any implementor of the Lura project to set any random pattern they would consider.

If you have other suggestions or enhancements, please don't hesitate to share them. We value your contributions and look forward to possibly collaborating on other improvements in the future.

Thank you for the explanation. I understand your stand. Adding a feature to allow the overwriting of the invalidPattern function in Lura, which would enhance the extensibility of the project. I would like to contribute this feature voluntarily.

[github-actions]

This pull request was marked as resolved a long time ago and now has been automatically locked as there has not been any recent activity after it. You can still open a new issue and reference this link.