You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Simon Willnauer <si...@googlemail.com> on 2006/06/16 18:48:59 UTC
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
code.google.com. 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:
Email=johndoe@gmail.com&Passwd=north23AZ&service=servicename&source=Gulp-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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: GData - Milestone 2
Posted by Simon Willnauer <si...@googlemail.com>.
Hello again,
the discussion went quiet well but there is no solution for the
problem using multiple gdata server instances behind a load balancer.
I will definitely stick to my own token, using the jsession id I will
tie myself to a particular server instance. Not all servers
replicate sessions such that they have the same ID by default.
Therefore I should use my own token rather then relying on
jsessionid.
As otis said preparing the server for use behind a loadbalancer
"sounds like a big bite for SoC" I will create my own session handling
for a single instance of the server. It might be a nice task
implementing a sessionhandling for multiple servers after the SoC has
finished. In my opinion the project should provide core functionality
and will be extended in further development.
If any of you have ideas for using a stateless approach for the
authentication component I really appreciate any suggestion!
regards simon
On 6/17/06, Simon Willnauer <si...@googlemail.com> wrote:
> On 6/17/06, Otis Gospodnetic <ot...@yahoo.com> wrote:
> > Simon,
> >
> > I don't fully understand your question, but if sessions are replicated, then the GData cluster doesn't care which GData server the client contacts, as they will all already have the token that was given to the client. On subsequent requests, the client will have to send the token. I am not sure if GData protocol specifies how that should be sent - via a query string param or perhaps even a HTTP request header (e.g. X-gdata-auth: SomeTokenHere). The jsessionId carries the HttpSession ID if the client doesn't support, and thus doesn't send back, cookies. If it does suppose cookies, they will be sent via Set-Cookie or some such HTTP request header.
>
> The client will send back the auth token either as a cookie or as
> Authorization: GoogleLogin auth=sessionid header.
>
> >
> > I think what you need to do is:
> > - client makes a request
> > - server says "you are not authenticated, here is a 401"
> > - client provides credentials
> > - server checks credentials, creates token, saves it to session, and says to client: "OK, eat this token". The client saves it
> > - client makes a new request and sends the token (via HTTP request header or via query string param)
> > - server takes the token and compares it to the one stored in the current session [1]
> > - if the tokens match, the server responds with the data, else goto line with 401 above
> >
>
> This is the common life cycle of a client - javaserver as we both
> know. But the client does not send back the sessionid if no cookies
> are supported. E.g. request.getSession(false) returns null. I tired
> this with the google data client api using the GoogleService which is
> a subclass of Serivce. Service is a base class to customize
> authorization and extensions. So this is the actual problem. :/
> I could provide a custom impl. which supports session id and cookies...
>
> simon
> >
> > [1] In order for your server (Jetty or Tomcat or whatever) to be able to associate a client with a session, the client must send back the session Id from the first request. This is normal Java webapp behaviour. The client will send it either as a cookie via HTTP headers, or via jsessionid (aka URL rewriting... not to be mixed with mod_rewrite). Regardless of the method, the server (Jetty/Tomcat) will know how to associate the request with an existing insntance of HttpSession, and that's that you'll get from request.getSession().
> >
> > Otis
> >
> > ----- Original Message ----
> > From: Simon Willnauer <si...@googlemail.com>
> > To: java-dev@lucene.apache.org; Otis Gospodnetic <ot...@yahoo.com>
> > Sent: Friday, June 16, 2006 4:53:21 PM
> > Subject: Re: GData - Milestone 2
> >
> > On 6/16/06, Otis Gospodnetic <ot...@yahoo.com> wrote:
> > > Hi Simon,
> > >
> > > I have a bit of experience with REST and authentication from my work on http://simpy.com .
> > > If you look at http://groups.yahoo.com/group/simpy-dev/messages you will see several recent messages about different authentication options that may give you some food for thought.
> >
> > --> good stuff, thanks for the link!
> > >
> > > As for GData auth:
> > > - 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.
> >
> > I already tried the HttpSession approach. Using the http session would
> > solve all my problems. The Session can be replicated as the most
> > containers support session repl. But how do i get the session id from
> > the client. The client sends a request parameter name: Auth value:
> > sessionid but the container does not recognize the session in this
> > case. As far as I know does the session parameter name has to be
> > "jsessionid" and I only get the session via the HttpServletRequest.
> > Any Idea about this?
> >
> > simon
> > >
> > > - Running GData server in a cluster might require session replication. It sounds like a big bite for SoC, but ... I never used WADI, but I _think_ that might be easiest way to get session replication going: http://incubator.apache.org/projects/wadi.html
> > > On the other hand, WADI might be an overkill if all you want is to share this token. If that's all you need, perhaphs, is JavaSpaces (e.g. http://www.dancres.org/blitz/ ).
> > >
> > > Otis
> > >
> > >
> > > ----- Original Message ----
> > > From: Simon Willnauer <si...@googlemail.com>
> > > To: java-dev@lucene.apache.org
> > > 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
> > > code.google.com. 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:
> > >
> > > Email=johndoe@gmail.com&Passwd=north23AZ&service=servicename&source=Gulp-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: java-dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: java-dev-help@lucene.apache.org
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: java-dev-help@lucene.apache.org
> > >
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: GData - Milestone 2
Posted by Simon Willnauer <si...@googlemail.com>.
On 6/17/06, Otis Gospodnetic <ot...@yahoo.com> wrote:
> Simon,
>
> I don't fully understand your question, but if sessions are replicated, then the GData cluster doesn't care which GData server the client contacts, as they will all already have the token that was given to the client. On subsequent requests, the client will have to send the token. I am not sure if GData protocol specifies how that should be sent - via a query string param or perhaps even a HTTP request header (e.g. X-gdata-auth: SomeTokenHere). The jsessionId carries the HttpSession ID if the client doesn't support, and thus doesn't send back, cookies. If it does suppose cookies, they will be sent via Set-Cookie or some such HTTP request header.
The client will send back the auth token either as a cookie or as
Authorization: GoogleLogin auth=sessionid header.
>
> I think what you need to do is:
> - client makes a request
> - server says "you are not authenticated, here is a 401"
> - client provides credentials
> - server checks credentials, creates token, saves it to session, and says to client: "OK, eat this token". The client saves it
> - client makes a new request and sends the token (via HTTP request header or via query string param)
> - server takes the token and compares it to the one stored in the current session [1]
> - if the tokens match, the server responds with the data, else goto line with 401 above
>
This is the common life cycle of a client - javaserver as we both
know. But the client does not send back the sessionid if no cookies
are supported. E.g. request.getSession(false) returns null. I tired
this with the google data client api using the GoogleService which is
a subclass of Serivce. Service is a base class to customize
authorization and extensions. So this is the actual problem. :/
I could provide a custom impl. which supports session id and cookies...
simon
>
> [1] In order for your server (Jetty or Tomcat or whatever) to be able to associate a client with a session, the client must send back the session Id from the first request. This is normal Java webapp behaviour. The client will send it either as a cookie via HTTP headers, or via jsessionid (aka URL rewriting... not to be mixed with mod_rewrite). Regardless of the method, the server (Jetty/Tomcat) will know how to associate the request with an existing insntance of HttpSession, and that's that you'll get from request.getSession().
>
> Otis
>
> ----- Original Message ----
> From: Simon Willnauer <si...@googlemail.com>
> To: java-dev@lucene.apache.org; Otis Gospodnetic <ot...@yahoo.com>
> Sent: Friday, June 16, 2006 4:53:21 PM
> Subject: Re: GData - Milestone 2
>
> On 6/16/06, Otis Gospodnetic <ot...@yahoo.com> wrote:
> > Hi Simon,
> >
> > I have a bit of experience with REST and authentication from my work on http://simpy.com .
> > If you look at http://groups.yahoo.com/group/simpy-dev/messages you will see several recent messages about different authentication options that may give you some food for thought.
>
> --> good stuff, thanks for the link!
> >
> > As for GData auth:
> > - 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.
>
> I already tried the HttpSession approach. Using the http session would
> solve all my problems. The Session can be replicated as the most
> containers support session repl. But how do i get the session id from
> the client. The client sends a request parameter name: Auth value:
> sessionid but the container does not recognize the session in this
> case. As far as I know does the session parameter name has to be
> "jsessionid" and I only get the session via the HttpServletRequest.
> Any Idea about this?
>
> simon
> >
> > - Running GData server in a cluster might require session replication. It sounds like a big bite for SoC, but ... I never used WADI, but I _think_ that might be easiest way to get session replication going: http://incubator.apache.org/projects/wadi.html
> > On the other hand, WADI might be an overkill if all you want is to share this token. If that's all you need, perhaphs, is JavaSpaces (e.g. http://www.dancres.org/blitz/ ).
> >
> > Otis
> >
> >
> > ----- Original Message ----
> > From: Simon Willnauer <si...@googlemail.com>
> > To: java-dev@lucene.apache.org
> > 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
> > code.google.com. 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:
> >
> > Email=johndoe@gmail.com&Passwd=north23AZ&service=servicename&source=Gulp-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: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: GData - Milestone 2
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Simon,
I don't fully understand your question, but if sessions are replicated, then the GData cluster doesn't care which GData server the client contacts, as they will all already have the token that was given to the client. On subsequent requests, the client will have to send the token. I am not sure if GData protocol specifies how that should be sent - via a query string param or perhaps even a HTTP request header (e.g. X-gdata-auth: SomeTokenHere). The jsessionId carries the HttpSession ID if the client doesn't support, and thus doesn't send back, cookies. If it does suppose cookies, they will be sent via Set-Cookie or some such HTTP request header.
I think what you need to do is:
- client makes a request
- server says "you are not authenticated, here is a 401"
- client provides credentials
- server checks credentials, creates token, saves it to session, and says to client: "OK, eat this token". The client saves it
- client makes a new request and sends the token (via HTTP request header or via query string param)
- server takes the token and compares it to the one stored in the current session [1]
- if the tokens match, the server responds with the data, else goto line with 401 above
[1] In order for your server (Jetty or Tomcat or whatever) to be able to associate a client with a session, the client must send back the session Id from the first request. This is normal Java webapp behaviour. The client will send it either as a cookie via HTTP headers, or via jsessionid (aka URL rewriting... not to be mixed with mod_rewrite). Regardless of the method, the server (Jetty/Tomcat) will know how to associate the request with an existing insntance of HttpSession, and that's that you'll get from request.getSession().
Otis
----- Original Message ----
From: Simon Willnauer <si...@googlemail.com>
To: java-dev@lucene.apache.org; Otis Gospodnetic <ot...@yahoo.com>
Sent: Friday, June 16, 2006 4:53:21 PM
Subject: Re: GData - Milestone 2
On 6/16/06, Otis Gospodnetic <ot...@yahoo.com> wrote:
> Hi Simon,
>
> I have a bit of experience with REST and authentication from my work on http://simpy.com .
> If you look at http://groups.yahoo.com/group/simpy-dev/messages you will see several recent messages about different authentication options that may give you some food for thought.
--> good stuff, thanks for the link!
>
> As for GData auth:
> - 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.
I already tried the HttpSession approach. Using the http session would
solve all my problems. The Session can be replicated as the most
containers support session repl. But how do i get the session id from
the client. The client sends a request parameter name: Auth value:
sessionid but the container does not recognize the session in this
case. As far as I know does the session parameter name has to be
"jsessionid" and I only get the session via the HttpServletRequest.
Any Idea about this?
simon
>
> - Running GData server in a cluster might require session replication. It sounds like a big bite for SoC, but ... I never used WADI, but I _think_ that might be easiest way to get session replication going: http://incubator.apache.org/projects/wadi.html
> On the other hand, WADI might be an overkill if all you want is to share this token. If that's all you need, perhaphs, is JavaSpaces (e.g. http://www.dancres.org/blitz/ ).
>
> Otis
>
>
> ----- Original Message ----
> From: Simon Willnauer <si...@googlemail.com>
> To: java-dev@lucene.apache.org
> 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
> code.google.com. 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:
>
> Email=johndoe@gmail.com&Passwd=north23AZ&service=servicename&source=Gulp-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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: GData - Milestone 2
Posted by Simon Willnauer <si...@googlemail.com>.
On 6/16/06, Otis Gospodnetic <ot...@yahoo.com> wrote:
> Hi Simon,
>
> I have a bit of experience with REST and authentication from my work on http://simpy.com .
> If you look at http://groups.yahoo.com/group/simpy-dev/messages you will see several recent messages about different authentication options that may give you some food for thought.
--> good stuff, thanks for the link!
>
> As for GData auth:
> - 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.
I already tried the HttpSession approach. Using the http session would
solve all my problems. The Session can be replicated as the most
containers support session repl. But how do i get the session id from
the client. The client sends a request parameter name: Auth value:
sessionid but the container does not recognize the session in this
case. As far as I know does the session parameter name has to be
"jsessionid" and I only get the session via the HttpServletRequest.
Any Idea about this?
simon
>
> - Running GData server in a cluster might require session replication. It sounds like a big bite for SoC, but ... I never used WADI, but I _think_ that might be easiest way to get session replication going: http://incubator.apache.org/projects/wadi.html
> On the other hand, WADI might be an overkill if all you want is to share this token. If that's all you need, perhaphs, is JavaSpaces (e.g. http://www.dancres.org/blitz/ ).
>
> Otis
>
>
> ----- Original Message ----
> From: Simon Willnauer <si...@googlemail.com>
> To: java-dev@lucene.apache.org
> 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
> code.google.com. 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:
>
> Email=johndoe@gmail.com&Passwd=north23AZ&service=servicename&source=Gulp-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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: GData - Milestone 2
Posted by Ian Holsman <li...@holsman.net>.
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 218.214.209.232) there are several proxy
servers out there which load balance HTTP requests through different
ip's.
regards
Ian
>
> Otis
>
>
> ----- Original Message ----
> From: Simon Willnauer <si...@googlemail.com>
> To: java-dev@lucene.apache.org
> 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
> code.google.com. 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:
>
> Email=johndoe@gmail.com&Passwd=north23AZ&service=servicename&source=Gu
> 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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: GData - Milestone 2
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hi Simon,
I have a bit of experience with REST and authentication from my work on http://simpy.com .
If you look at http://groups.yahoo.com/group/simpy-dev/messages you will see several recent messages about different authentication options that may give you some food for thought.
As for GData auth:
- 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.
- Running GData server in a cluster might require session replication. It sounds like a big bite for SoC, but ... I never used WADI, but I _think_ that might be easiest way to get session replication going: http://incubator.apache.org/projects/wadi.html
On the other hand, WADI might be an overkill if all you want is to share this token. If that's all you need, perhaphs, is JavaSpaces (e.g. http://www.dancres.org/blitz/ ).
Otis
----- Original Message ----
From: Simon Willnauer <si...@googlemail.com>
To: java-dev@lucene.apache.org
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
code.google.com. 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:
Email=johndoe@gmail.com&Passwd=north23AZ&service=servicename&source=Gulp-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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org