On 6/16/06, Otis Gospodnetic <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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 PROTECTED]&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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
