Thank you everyone for your thorough responses, they are of great help.
In the interest of keeping the conversation going...
My applications undergo auditing to meet strict security protocols,
therefor I generally stay away from BASIC auth due to the in-the-clear
nature of the Authorization header unless the entire session is
planned to be delivered over SSL. With the exception of Eric's
implementation where a crypted version is stored on the server and
referenced by a session id, how are others dealing with these inherent
security risk in a production environment?
-- Mike
Without session affinity
On Sep 17, 2009, at 8:51 AM, Vidar Ramdal wrote:
On Thu, Sep 17, 2009 at 5:29 PM, Eric Norman
<[email protected]> wrote:
Well, my project doesn't currently have enough load to require more
than one
server node, so I haven't thought much about that yet. If your
cluster can
be configured to use sticky sessions, it would probably work fine
without
any further changes. Otherwise your app server would need to be
configured
to perform session replication to avoid the login prompt when you
get routed
to a different server node.
Does that make sense?
Yes, thanks. That's what I thought.
I realize that authentication must be hard in any truly REST-based
system.
--
Vidar S. Ramdal <[email protected]> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
:: mike moulton
:: meltmedia
:: [email protected]
