lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject Re: GData - Milestone 2
Date Fri, 16 Jun 2006 20:46:58 GMT

On 17/06/2006, at 6:36 AM, Otis Gospodnetic wrote:

> Hi Simon,
> - GData oversion page describes the auth with "send a cookie/token,  
> save in server-side, and then expect it from the client on  
> subsequent requests" (paraphrased).  That sounds fine to me.  I  
> don't think you need to worry about the client IP, as long as your  
> cookie/token is long and random enough (please correct me if I'm  
> wrong about this), although you might want to add the IP to the  
> string you base your MD5 checksum on.
> If you store the token in the session, it will automatically get  
> the TTL of the HttpSession.

if you are going to use the IP, and you only use the first 3 quartets  
(ie  218.214.209 instead of there are several proxy  
servers out there which load balance HTTP requests through different  

> Otis
> ----- Original Message ----
> From: Simon Willnauer <>
> To:
> Sent: Friday, June 16, 2006 12:48:59 PM
> Subject: GData - Milestone 2
> Hello everyone,
> it was quiet the last week, well I had a bad cold so Milestone 2
> starts a bit late...
> Milestone 2 is about client authentication. GData client auth is also
> defined (well kind of) in the gdata protocol reference on
> The client is supposed to support either a cookie
> base auth or just an auth token send back as an post response. The
> client authenticates itself via a post request to the servers auth
> interface sending following parameters:
> lp-CalGulp-1.05
> the email represents the account name which is associated with a
> service provided by the server. Each server can provides m services
> with n feeds. Each feed belongs to one account.
> As it is quiet hard to figure out whether a client does support plain
> token or cookie auth I will send both back to the client. after the
> client has received the auth token or cookie it will call some
> restricted resource on the server sending either the cookie or the
> auth token. The cookie contains  only the auth token.
> So these are facts, I will generate a MD5 key as the auth token using
> the email, password and a timestamp or something similar and save it
> on the server in a kind of a session storage. the session storage will
> hold the sessions for a certain time and will invalidate it if it is
> timed out. Additionally i will save  the client ip (at least the first
> 32 bits) within the session and check it on     subsequent   
> requests. So
> this is fine as long as the server is a stand alone server. What
> happens if there is a load balancer and a server farm with more than
> one gdata server instances?!
> I could define all gdata servers in the cluster / farm in each config
> file and if a session is created or modified the current server sends
> a notice to all other servers to replicate the session. (Session is
> not the HTTPSession). But this could be quiet a lot of work so
> synchronize all hosts and register / unregister them if the crash...
> I guess this should be done in a later state of development, I just
> have 2 month left... So this might be a task for development after the
> SoC program has finished.
> Any Ideas about that?
> yours simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message