Yes, this was my point as well. But I think the question began more like
"If Restlet's doesn't offer something like Sessions someone will make
one of another framework will take it's place.". My answer was wouldn't
simple documenting a different method under Restlet's cover that issue.
I mean if you can still fill the session gap (so to speak) using a
different method the why would Restlet's need to mimic another systems
session method?
Adam Taft wrote:
I guess I was reading the question as more like: "Are sessions
secure?" or "Are cookies secure?" Not so much "is any generic
technology secure?"
My answer to the sessions/cookies question:
Cookies and/or sessions cannot ever be secure without SSL. Otherwise,
a man-in-the-middle can use the cookies (or other session information)
to easily spoof the identity of the user.
:)
Adam
John D. Mitchell wrote:
Re: Security
The underlying issue is always the need to answer the question:
What is the threat model that you're worried about?
Until there's clarity on that, all other considerations are irrelevant.
After there's clarity on that then it's a question of balancing the
tradeoffs (direct costs, user impact, unintended consequences, etc.).
One of the key "when do we know where to stop" criteria is the point
at which for any given threat vector when does it become
cheaper/easier/etc. to just go
trick/bribe/bully/break-in-and-steal/etc. the information rather than
trying to get it technologically -- i.e., the "rubber-hose" test.
Take care,
John
--
Justin Stanczak
Stanczak Group
812-735-3600
"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
