[MAGNOLIA-1726] Make LoginFilter.resetSessionAttributes protected Created: 06/Sep/07 Updated: 09/Jul/08 Resolved: 09/Jul/08 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | security |
| Affects Version/s: | 3.1 M3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Anthony Ogier | Assignee: | Magnolia International |
| Resolution: | Obsolete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| 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: |
| Description |
|
For some obscure reason(s), the current LoginFilter calls resetSessionAttributes(HttpSession) when one LoginHandler has succeded (LoginHandler.STATUS_SUCCEDED). It seems to be a workaround, and currently refers to I'm trying to implement CAS on Magnolia, and as the CASFilter (which is called by a custom LoginHandler) sets some parameters in session to remember the current user has logged in, it is destroyed by this reset function. Thanks ! |
| Comments |
| Comment by Magnolia International [ 09/Jul/08 ] |
|
Can't fix this anymore, as said method is gone. The equivalent code is now in UserContext, and as far as I can tell, session attributes are not removed anymore. |
| Comment by Magnolia International [ 09/Jul/08 ] |
|
(this should also be fine with 3.5, actually) |