Re: Restoring session after timeout.
Re: Restoring session after timeout.
- Subject: Re: Restoring session after timeout.
- From: Mahdi Mankai <email@hidden>
- Date: Fri, 02 Dec 2011 18:36:43 +0100
Thanks Guys for the helpful comments.
I think I was a bit misunderstood, I got my answer though :).
Actually, my application has a public website that is session less and relies on cookies to identify users using direct actions only. In this case, it's easy to keep users logged in.
However, when there is a session (Component actions and D2W) it gets more complicated. I was thinking may be there is an easy way to keep users doing logged in (even with a new session). Apparently, it's not obvious. So, I abandoned this idea.
Thanks again.
Mahdi
On 2011-12-02, at 6:17 PM, Ramsey Gurley wrote:
> I can see how this could work for simple CRUD stuff. It seems this would break down when it comes to complex backtracking/flow though.
>
> Let's say I query -> list -> edit list object -> confirm -> save -> return to list... that's a lot of backtrack state to maintain in the url/submitted form. Say I'm at save and need to direct back to the user's list page. I need to know the qualifier applied to the list, the list batch size, the list batch index, the list sort orderings, and the authenticated user if any. Hard, lots of work, but probably not impossible. By the time you get half way through implementing it, a fat stateful server with D2W isn't looking so bad.
>
> Or maybe I edit a relationship and create a new unsaved object related to the list object. I can't hand that new EO to the confirm page except by temp global id. If I restart the app on the confirm page... doom! :-)
>
> Stateless server is the new hotness and sounds great, but it becomes a lot of work very quickly. I'm sure ERRest helps a lot, but short of some unreleased fat client like Gianduia, you still end up having to invent all the state management on the client yourself AFAIK.
>
> [This is where Pascal points me to his newly released Dojo awesomeness or something to prove me wrong ;-)]
>
> Ramsey
>
>
> On Dec 2, 2011, at 9:06 AM, Pascal Robert wrote:
>
>>
>> Le 2011-12-02 à 11:03, Jean-Francois Veillette a écrit :
>>
>>>> I've seen this before !
>>>>
>>>> What you have to do is make sure every significant state can somewhat get back to the server on the next request.
>>>> For user-login you have the cookie.
>>>> For specific editing context information, you can get some back in having eo-id encoded within the form. Like having a text field with a name = 'Book_01_title' that way, you could deduce that you have a text-field on the title attribute of an eo of entity Book with 1 as the primary key.
>>>
>>> They did push the concept further ...
>>> they encoded (?bluefish?) those id so that they couldn't be forged.
>>>
>>> and further still ... but I do not remember it all !
>>
>> Or you use ERRest HTML routing :-)
>>
>>>
>>>> For persistency and be session independent, you have to make every action a direct-action and not require a session. You have to see Session as optional and not rely on it, just consider it as a cache that can boost request evaluation
>>>>
>>>> So with a combination of cookies, direct-action and special form encoded name you could reconstitute most (if not all) of your context.
>>>>
>>>> In fact I do not remember the implementation, but it must resemble what I just described.
>>>>
>>>> It was presented to me in 2000, it was a WO engineer that developed it for a client, and he showed us his application running, went to a form page, started to fill it and then stopped the application and restarted it (so obviously session id was no longer valid), he then submitted the form and the client did go along as if nothing happened server side. You can now imagine a farm of wo apps, if one of the instance goes down, no worries, another one will take the request and respond.
>>>>
>>>>
>>>> Le 2011-12-02 à 08:47, Mahdi Mankai a écrit :
>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for the reply.
>>>>>
>>>>> I don't really care about the timed out session. I am more looking for restoring my whole context even with a new session.
>>>>>
>>>>> Ajax won't be helpful for me, because I want to plug such a behaviour to an existing complex application. It won't be very convenient to review all the forms and components.
>>>>>
>>>>> Mahdi
>>>>>
>>>>> On 2011-12-02, at 1:54 PM, Jérémy DE ROYER wrote:
>>>>>
>>>>>> I dont think its possible, timeout is timeout
>>>>>>
>>>>>> May be you could auto save the form with ajax and restore it in the new session ?
>>>>>>
>>>>>> Jeremy DE ROYER
>>>>>>
>>>>>> Le 2 déc. 2011 à 12:11, Mahdi Mankai <email@hidden> a écrit :
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'd like to do something but I am not sure whether it's possible.
>>>>>>>
>>>>>>> I have a WO application that requires users to login.
>>>>>>>
>>>>>>> I am storing the user credentials in cookies to avoid having to login each time.
>>>>>>>
>>>>>>> I'd like to handle the situation where a user tries to continue working on the application after his session is timed out.
>>>>>>>
>>>>>>> Basically, whatever the request is (may be Direct Action or Component request, with or without form values), I want to get the appropriate response but with a new session (created using the credentials stored in cookies). i.e. process the same request but with a different session or (I don't know if it's possible) restore a timed out session.
>>>>>>>
>>>>>>> I don't want to extend the session timeout parameter.
>>>>>>>
>>>>>>> I tried to do something in handleSessionRestorationErrorInContext(WOContext aContext) in WOApplication class. But couldn't figure out how to reuse the same context with a different session. The only thing I was able to do is to redirect to a specific page.
>>>>>>>
>>>>>>> For example, I would like users to be able to fill a form, come back tomorrow, hit save and my application should be able to handle that smoothly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Mahdi
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden