Document route_security pattern semantics (anchored, * only wildcard)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Domain
- documentation
Research direction
Read the route pattern semantics in the issue, then update content/4.api/04.users/3.access-control.md, content/4.api/03.configuration.md, and content/4.api/02.bundle-setup.md. Replace the outdated unanchored-regex explanation with the stated whole-path, wildcard, and case rules, and clarify that /user-area* and /admin* remain prefixes. Done when all three pages agree and the anywhere-match example uses /admin.
Written by the indexing model from the issue text.
Description
From components-web-app/api-components-bundle#537, fixed in components-web-app/api-components-bundle#538.
A route_security route pattern now means exactly what is written, on item access (RouteVoter) and collection filtering (GET /_/routes) alike:
- The pattern matches the whole path.
*is the only wildcard; every other character is literal (.,%,_included). /user-area*is a prefix:/user-area,/user-area/page,/user-areas. It no longer matches/other/user-area/x.*/user-area*matches the segment anywhere in the path./user-area(no wildcard) is that exact path only.- ASCII letters match regardless of case.
To update:
content/4.api/04.users/3.access-control.mdline 97 says item access uses an unanchored regex so/admin*also denies/foo/admin/bar. That is no longer true: replace it with the rules above and an example of*/admin*for the old anywhere match. This is a breaking change for sites relying on the anywhere match.content/4.api/03.configuration.md(around line 178) andcontent/4.api/02.bundle-setup.md(around line 125) use/user-area*and/admin*; these remain correct as prefixes, but the configuration reference should state the semantics or link to the access-control page.
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 1h 20m
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from components-web-app/docs
-
Browser Tests page: the template's tests no longer use the sample content (components-web-app#177)Open
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
components-web-app/docs#267 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
components-web-app/docs#265 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
components-web-app/docs#264 ·
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
components-web-app/docs#263 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
components-web-app/docs#262 ·
All issues in components-web-app/docs
Similar issues
-
area:workflow bug ready-for-human
Difficulty 1/5 Under an hour Newbie friendliness 78/100
fil-donadoni/tolaria#6108 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/rocketmq-dashboard#7234 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
vitest-dev/vitest#11656 ·
Maintainers usually reply within 1 day
-
e2e-failure ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
redhat-developer/rhdh-plugin-export-overlays#4460 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
ehmpathy/rhachet-roles-bhrain#655 ·
Maintainers usually reply within 1 day