Ticket #159 (WontFix)Fri Nov 23 21:19:49 UTC 2007
Hub login flashes can get included in fragment caches
| Reported by: | Andrew Hodgkinson (6) | Severity: | Normal |
| Part: | Web site: Hub (single sign-on mechanism) | Release: | 2nd public site release |
| Milestone: | 2nd public site release completed | Status | WontFix |
Details by Andrew Hodgkinson (6):
Typo was telling everyone they were logged in as me for a while, due to being redirected back to the main news page from Hub immediately after a login at a point where Typo felt it should update the cache.
The Hub use of the Rails flash mechanism has always been problematic (ignoring the nasty business of carrying the flash data from one application to another) ironically because heavily cached pages don’t show the flash. Now it turns out that the flash data may end up being cached. That’s a critical fault and a different cross-application notification mechanism is now urgently needed.
Changelog:
Modified by Andrew Hodgkinson (6) Wed, February 25 2009 - 19:38:03 GMT
- Severity changed from Critical to Normal
Downgrading severity. It sounds worse than it is; in practice, things seem to work out OK on average. It’s quite rare for someone to get returned back to Typo. If they are redirected back to Hub they’re safe. If they’re redirected back to another application, caching doesn’t seem to be a problem (probably because the locations from which a redirection through Hub can be prompted happen to not be cached anyway).
It would still be good to get a better idea of the underlying precise causes and possible fixes here. Ultimately though as long as other applications any content which includes parts of the Rails layout, rather than just a particular action’s fragment, no static in-page mechanism can be ‘truly’ safe since any data injected into the page by code in the layout is open to being included in a cache.
One solution would be to access flash data in the session cookie from JavaScript and write it dynamically into the page at the client side, so that the server side never sees it. This would work, but only if JavaScript were enabled and sufficiently capable in the client (it’ll fail with many RISC OS browsers since they don’t support JavaScript in the first place).
Given all the above discussion, this may well end up as a ‘WontFix’ entry.
Modified by Trevor Johnson (329) Mon, January 24 2011 - 13:24:35 GMT
- Status changed from Open to WontFix
Given all the above discussion, this may well end up as a ‘WontFix’ entry.
Let’s do that, then. Apologies for treading on people’s toes but I guesss this ticket can always be reopened again if desired.
