Weird wildcard route behaviour when specifying methods
See original GitHub issueHi,
while working on a new personal project, I’ve noticed a strange behaviour for wildcard routes:
I’ve configured the following route:
{
"routes": [
{
"route": "/api/*",
"methods": [
"PUT",
"POST",
"DELETE"
],
"allowedRoles": [
"admin"
]
}
]
}
In addition, in the project I have the following C# API:
- GET /api/books (gets all books in Database)
- GET /api/books/{id} (gets the book with {id} from the db)
- POST, PUT and DELETE for the books are only mocked via proxies.json
The behaviour I’d expect from my understanding is that the GET requests should be available to all users, while POST, PUT and DELETE should require a logged in user with the admin role.
However, when activating this route, I get a 403 error for all methods when I’m unauthenticated. Once i remove the route again, every method returns their backend success code.
I’m testing on Windows with azure/static-web-apps-cli@0.3.0
.
Am I missing something or is there a better way to imlement such a authentication requirement?
I’d appreciate any help!
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Is there a way to catch all non-matched routes with Backbone?
Depending on routes enumerating in any particular order is just asking for it. The only way to be sure is to use route()...
Read more >Non-wildcard routes that share a prefix with a ... - GitHub
Non-wildcard routes that share a prefix with a wildcard route should take priority over the wildcard route #73.
Read more >Different approaches to HTTP routing in Go - Ben Hoyt
Each router should handle the specified method ( GET or POST ) and reject the others with a 405 Method Not Allowed response....
Read more >Skipper Predicates - Zalando Open Source
Example route with a Host, Method and Path match predicates and a backend: ... The simple wildcards behave similar to the Path predicate....
Read more >Using wildcards in commands with zsh - Super User
There are many ways to bypass this behavior, here are some of them: ... By setting an alias in .zshrc for example: alias...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This should be fixed with #208 and released in v0.5.0.
@manekinekko While the rule now blocks requests correctly, it seems to return the wrong HTTP status code (returns 404 when not authenticated/authorized, instead of 401 or 403).
Repro: https://github.com/anthonychu/20210601-swa-cli-issue-190
swa start --api api
If you click the button and look at the browser dev tools, you’ll see the POST request returns 404 instead of 401.
@manekinekko I think this is a bug in the swa cli, can you take a look?