[MAGNOLIA-633] save the session Created: 10/Feb/06 Updated: 03/Dec/13 Resolved: 03/Dec/13 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 3.0 Beta 1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Philipp Bärfuss | Assignee: | Ondrej Chytil |
| Resolution: | Outdated | Votes: | 1 |
| 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)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
We must save the session by reloading a hidden image perodically. Else |
| Comments |
| Comment by Philipp Bracher [ 10/Feb/06 ] |
|
since we are using form based login now |
| Comment by Sameer Charles [ 10/Feb/06 ] |
|
Do we really have to do that? isn't it enough to increase the session timeout. perhaps not by calling an image because of unneccesary network trafic, what about a html request mapped |
| Comment by Boris Kraft [ 10/Feb/06 ] |
|
Does that mean an editing session no longer survives a server restart? That would be a rather stupid trade imho. Can't we have the cake and eat it, too? |
| Comment by Michael Aemisegger [ 11/Feb/06 ] |
|
Are you talking about http session or jcr sessions or both? Did JCR sessions ever survive a server restart? Don't you mix up http session, which can be recovered, and jcr sessions, which have never been recoverable (unless I missed something). I agree, that it would be desirable to have recoverable jcr sessions. In the absence of a session timeout and if no session is lost without explicit logout, wouldn't that mean that orphelan sessions get accumulated over time and hence unnecessarily occupy resources? A configurable session timeout would be ideal, IMO. For both, http and jcr sessions. |
| Comment by Philipp Bracher [ 13/Feb/06 ] |
|
I'm talking about the servlet session. Magnolia is an editing system and you can never increase the session enough. And you don't like to have to many unused sessions. Therefore I would say that increasing the session timeout is not a good solution. What one does in such cases is to run a javascript which reloads a hidden image (or similar) in the background with a smaller timeout than the session has (called a session saver). This avoids unused sessions and keeps the session running if you write a text or drink a coffee with you college The result is that you have a session as long as the admin central is used. If you close it, the session gets lost. There is no othere solution. Remark: With the basic authentication mode the session was lost too but the browser made a relogin (some would call this a security risk). |
| Comment by Sameer Charles [ 13/Feb/06 ] |
|
Yes and Boris is right no matter what we do, either background image reloading or anything there is no chance that you can survive a server restart - its only possible by BASIC Authhentication when Authentication headers are sent by the browser everytime. I guess we should let the decision on the user of a system, I will make it configurable so its your choice what you want. there are always pros and cons |
| Comment by Philipp Bracher [ 13/Feb/06 ] |
|
I would say no because the session does NOT survive if we use basic authentication. The browser re-logins and then it creates a new one. If we start to have other session information in the admin interface (JSF, ...) you would get the troubles again. I would say: basic authentication is used only for request from other applications. Nearly every Web App in the world is working this way why not magnolia? |
| Comment by Sameer Charles [ 13/Feb/06 ] |
|
agreed but still its the decision of a user |
| Comment by Philipp Bracher [ 13/Feb/06 ] |
|
OK |
| Comment by Andreas Brenk [ 13/Feb/06 ] |
|
Tomcat saves the active sessions serialized on disk during a shutdown and restores them during restart IIRC. |
| Comment by Markus Strickler [ 13/Feb/06 ] |
|
Yes session persistence is a function of the container. If you need sessions to survive restarts, you should be able to serialize them to disk or database, or whatever by configuring your container accordingly. |
| Comment by Alexandru Popescu [ 14/Feb/06 ] |
|
Sorry to jump in so late. IMO there are a few things that are important in this context:
./alex |
| Comment by Philipp Bracher [ 14/Feb/06 ] |
|
> HTTP Session: keep open the session; this can be achieved with small networking using ajax with DWR This is exactly what the reloading of an image does. Attention: keeping the session during runtime (avoid a timeout) and the serialization of a session (survive a restart, clustering) is something completely different. The first saves the session during editing if you type longer than the defined session timeout. That's what this issue is about. Having a small session timeout without loosing the session if you have open the admincentral during an inactive peroid. The serialization of the session: stop & start of container, clustering is something different. |
| Comment by Alexandru Popescu [ 14/Feb/06 ] |
|
Thanks for the clarifications Philipp. I thought to deal with those too, because they were mentioned. While speaking about the session timeout and pinging the server to keep the session alive, I guess we may also think about auto-save ./alex |
| Comment by Magnolia International [ 15/Nov/06 ] |
|
IMHO, reloading an image or basically using js for this is quite ugly. |
| Comment by Sean McMains [ 18/Aug/10 ] |
|
Here's a patch that should add this functionality. It loads adminCentral.html every 5 minutes in the background. (Please feel free to tweak this to point to something more appropriate if there is a better target.) |
| Comment by Sean McMains [ 30/Aug/10 ] |
|
And here's another patch (to be applied on top of the original one) that will prevent IE7 from caching the content it's supposed to be fetching, rendering the keep alive functionality inoperable on that browser. |
| Comment by Philipp Bärfuss [ 01/Sep/10 ] |
|
Thanks for the patches! We will apply them. |
| Comment by Ondrej Chytil [ 10/Sep/10 ] |
|
Thanks for patch Sean but due to security concerns this patch won't be applied to the trunk. |
| Comment by Sean McMains [ 10/Sep/10 ] |
|
No sweat. We had some spirited discussions over the security issues as well, but decided the benefits outweighed the disadvantages for us. With clients like the US Navy, I could see where that might not be the case for the core product. |
| Comment by Philipp Bärfuss [ 03/Dec/13 ] |
|
Hi, Thanks for reporting and/or commenting on this issue. We are currently reviewing issues that have had no or minimal activity for several years. Magnolia has evolved tremendously since this issue was reported; in order to focus our work, we are closing such issues. We realize that some of these might still be valid today - and we ask for your cooperation here. In some cases, we will be linking to overarching stories, or simply more up-to-date similar issues. If you believe this issue is still relevant today, please leave a comment below and we will get back to you. Cheers, |