Seaside Sessions in a Blog Server

> Hi,
>
> there's this constant example of building a blog server with  
> whatever web framework. If you try to build a real webserver in  
> Seaside you've got to handle sessions somewhat properly. If you view  
> a post and have a comment input field then the session will be  
> started when you open the post. After reading through a very  
> lengthly post the session is probably times out. After writing a  
> lengthly comment it's certainly timed out. If the user submits the  
> comment after the session is timed out, his comment is lost.
>
> The easiest way to handle this is to set the session timeout to  
> maybe a day or so. However, i'd rather use a short session time to  
> not have tons of sessions in the image. What would be the right way  
> to handle that kind of situations? I guess this could be done in  
> initialRequest:, but how do you figure out which callback-numbers  
> match which input field?
>
> Kind Regards
> Karsten
>
>
>
>
>
> --
> Karsten Kusche - Dipl. Inf. - [hidden email]
> Georg Heeg eK - Köthen
> Handelsregister: Amtsgericht Dortmund A 12812
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Hi,
>
> there's this constant example of building a blog server with whatever web
> framework. If you try to build a real webserver in Seaside you've got to
> handle sessions somewhat properly. If you view a post and have a comment
> input field then the session will be started when you open the post. After
> reading through a very lengthly post the session is probably times out.
> After writing a lengthly comment it's certainly timed out. If the user
> submits the comment after the session is timed out, his comment is lost.
>
> The easiest way to handle this is to set the session timeout to maybe a day
> or so. However, i'd rather use a short session time to not have tons of
> sessions in the image. What would be the right way to handle that kind of
> situations? I guess this could be done in initialRequest:, but how do you
> figure out which callback-numbers match which input field?
>
> Kind Regards
> Karsten
>
>
>
>
>
> --
> Karsten Kusche - Dipl. Inf. - [hidden email]
> Georg Heeg eK - Köthen
> Handelsregister: Amtsgericht Dortmund A 12812
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Hi,
>
> there's this constant example of building a blog server with whatever web
> framework. If you try to build a real webserver in Seaside you've got to
> handle sessions somewhat properly. If you view a post and have a comment
> input field then the session will be started when you open the post. After
> reading through a very lengthly post the session is probably times out.
> After writing a lengthly comment it's certainly timed out. If the user
> submits the comment after the session is timed out, his comment is lost.
>

> Hi Karsten
>
> 2009/10/17 Karsten <[hidden email]>:
> > Hi,
> >
> > there's this constant example of building a blog server with whatever web
> > framework. If you try to build a real webserver in Seaside you've got to
> > handle sessions somewhat properly. If you view a post and have a comment
> > input field then the session will be started when you open the post. After
> > reading through a very lengthly post the session is probably times out.
> > After writing a lengthly comment it's certainly timed out. If the user
> > submits the comment after the session is timed out, his comment is lost.
> >
>
> This situation is very common in mobile environments, when the client
> moves at places outside the network connectivity range, and then need
> to reconnect many times.
>
> > The easiest way to handle this is to set the session timeout to maybe a day
> > or so. However, i'd rather use a short session time to not have tons of
> > sessions in the image.
>
> And another good reason for keep short session times is to prevent
> session hijacking. The longer session duration, the longer chances for
> a succesful sniffing.
>
> > What would be the right way to handle that kind of
> > situations?
>
> I would do this:
>
> -Separate a session in two objects: One for the proper Session
> Duration, and another one for the Data of the session.
> -Assign to the Session Duration object a common duration for a valid session.
> -Assign to the Session Data object a longer duration (it could be
> navigational information or data in forms).
>
> This way, when a client session expires, the data entered would still
> there available. Of course you will need two identifiers and link them
> to do a valid re-authorization.
>
> How difficult would be to do that in Seaside?

> Hmm... personally, if I was doing a blog, I wouldn't use the
> RenderLoop at all (or possibly even sessions) until the user logged in
> to edit the blog. I might also use it when they posted a comment, but
> not sure. Much better to have it RESTful at that point, I think...
>
> If I was going to use sessions and render loop, I'd just keep the
> sessions around - it seems like a nightmare to figure out what
> callbacks were supposed to be what once the session is gone. You could
> add some kind of hidden field to the form so that you knew what kind
> of submission it was, and then I guess you could look through the
> request to find appropriate fields. Kind of tacky though...
>
> I guess it would be nice to have a mechanism to move sessions out to
> disk after a certain period; somebody could probably do that...
>
> You can also use JavaScript to keep the session alive as long as the
> user has the page open...
>
> Julian
>
> On Sat, Oct 17, 2009 at 9:09 AM, Karsten<[hidden email]>  wrote:
>    
>> Hi,
>>
>> there's this constant example of building a blog server with whatever web
>> framework. If you try to build a real webserver in Seaside you've got to
>> handle sessions somewhat properly. If you view a post and have a comment
>> input field then the session will be started when you open the post. After
>> reading through a very lengthly post the session is probably times out.
>> After writing a lengthly comment it's certainly timed out. If the user
>> submits the comment after the session is timed out, his comment is lost.
>>
>> The easiest way to handle this is to set the session timeout to maybe a day
>> or so. However, i'd rather use a short session time to not have tons of
>> sessions in the image. What would be the right way to handle that kind of
>> situations? I guess this could be done in initialRequest:, but how do you
>> figure out which callback-numbers match which input field?
>>
>> Kind Regards
>> Karsten
>>
>>
>>
>>
>>
>> --
>> Karsten Kusche - Dipl. Inf. - [hidden email]
>> Georg Heeg eK - Köthen
>> Handelsregister: Amtsgericht Dortmund A 12812
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>      
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>    

> El sáb, 17-10-2009 a las 15:39 -0300, Hernán Morales Durand escribi
> ó:
>> Hi Karsten
>>
>> 2009/10/17 Karsten <[hidden email]>:
>>> Hi,
>>>
>>> there's this constant example of building a blog server with  
>>> whatever web
>>> framework. If you try to build a real webserver in Seaside you've  
>>> got to
>>> handle sessions somewhat properly. If you view a post and have a  
>>> comment
>>> input field then the session will be started when you open the  
>>> post. After
>>> reading through a very lengthly post the session is probably times  
>>> out.
>>> After writing a lengthly comment it's certainly timed out. If the  
>>> user
>>> submits the comment after the session is timed out, his comment is  
>>> lost.
>>>
>>
>> This situation is very common in mobile environments, when the client
>> moves at places outside the network connectivity range, and then need
>> to reconnect many times.
>>
>>> The easiest way to handle this is to set the session timeout to  
>>> maybe a day
>>> or so. However, i'd rather use a short session time to not have  
>>> tons of
>>> sessions in the image.
>>
>> And another good reason for keep short session times is to prevent
>> session hijacking. The longer session duration, the longer chances  
>> for
>> a succesful sniffing.
>>
>>> What would be the right way to handle that kind of
>>> situations?
>>
>> I would do this:
>>
>> -Separate a session in two objects: One for the proper Session
>> Duration, and another one for the Data of the session.
>> -Assign to the Session Duration object a common duration for a  
>> valid session.
>> -Assign to the Session Data object a longer duration (it could be
>> navigational information or data in forms).
>>
>> This way, when a client session expires, the data entered would still
>> there available. Of course you will need two identifiers and link  
>> them
>> to do a valid re-authorization.
>>
>> How difficult would be to do that in Seaside?
>
>
> Other option will be to use something like the autosave feature of  
> rich
> editors like TinyMCE so that at least with the comments you don't lost
> all the text. This also will keep the session open.
>
>>
>> Cheers
>>
>> Hernán
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Hi Julian,
>
> is there a demo for RESTful apps in Seaside available?
>
> Kind Regards
> Karsten
>
> Am 17.10.09 18:31, schrieb Julian Fitzell:
>>
>> Hmm... personally, if I was doing a blog, I wouldn't use the
>> RenderLoop at all (or possibly even sessions) until the user logged in
>> to edit the blog. I might also use it when they posted a comment, but
>> not sure. Much better to have it RESTful at that point, I think...
>>
>> If I was going to use sessions and render loop, I'd just keep the
>> sessions around - it seems like a nightmare to figure out what
>> callbacks were supposed to be what once the session is gone. You could
>> add some kind of hidden field to the form so that you knew what kind
>> of submission it was, and then I guess you could look through the
>> request to find appropriate fields. Kind of tacky though...
>>
>> I guess it would be nice to have a mechanism to move sessions out to
>> disk after a certain period; somebody could probably do that...
>>
>> You can also use JavaScript to keep the session alive as long as the
>> user has the page open...
>>
>> Julian
>>
>> On Sat, Oct 17, 2009 at 9:09 AM, Karsten<[hidden email]>  wrote:
>>
>>>
>>> Hi,
>>>
>>> there's this constant example of building a blog server with whatever web
>>> framework. If you try to build a real webserver in Seaside you've got to
>>> handle sessions somewhat properly. If you view a post and have a comment
>>> input field then the session will be started when you open the post.
>>> After
>>> reading through a very lengthly post the session is probably times out.
>>> After writing a lengthly comment it's certainly timed out. If the user
>>> submits the comment after the session is timed out, his comment is lost.
>>>
>>> The easiest way to handle this is to set the session timeout to maybe a
>>> day
>>> or so. However, i'd rather use a short session time to not have tons of
>>> sessions in the image. What would be the right way to handle that kind of
>>> situations? I guess this could be done in initialRequest:, but how do you
>>> figure out which callback-numbers match which input field?
>>>
>>> Kind Regards
>>> Karsten
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Karsten Kusche - Dipl. Inf. - [hidden email]
>>> Georg Heeg eK - Köthen
>>> Handelsregister: Amtsgericht Dortmund A 12812
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>>
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>>
>
> --
> Karsten Kusche - Dipl. Inf. - [hidden email]
> Georg Heeg eK - Köthen
> Handelsregister: Amtsgericht Dortmund A 12812
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>