[MAGNOLIA-8232] Intercept login redirects to reduce bypasses for the login-CSRF filter Created: 19/Nov/21 Updated: 27/Oct/22 |
|
| Status: | Accepted |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Michael Duerig | Assignee: | Michael Duerig |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | artt, csrf, foundation_team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||
| Date of First Response: | |||||||||
| Team: | |||||||||
| Description |
|
There is a number of configured bypasses for the CSRFTokenFilter. Within
Implementation note: may we can use security callbacks? |
| Comments |
| Comment by Mikaël Geljić [ 07/Dec/21 ] |
|
The more relevant quote might be this one:
—emphasized what it boils down to imo. originalURI is available in AggregationState, but we might not need it. If the response status is unauthorized (and we forwarded to the login screen instead), we might as well stop bypassing the login-csrf almost entirely, and token generation would only occur for protected resources. |