Sounds good. Let me know when/where and I'll help proof it or something.
Rob Heittman wrote:
Justin S: "If you don't want to have sessions, show us a pattern that
can fill the void."
Kyrre K: "...implement it either as a plug-in, code templates, or
document it as the recommended way."
I think the documentational path is the first approach, and I don't
know that the discuss list is the best way to do it, though I think
the discussion has gotten a lot more light than heat, and I'm grateful
for that. I'm thinking more along the lines of getting a starting
point out on the wiki somewhere, that gets called from the FAQ: "My
application relies on HttpSessions and Restlet doesn't seem to have
them. So what am I supposed to do instead?"
I'm working on an outline based on the input here thus far ...
- R
----- Original Message -----
From: "Stanczak Group" <[EMAIL PROTECTED]>
To: discuss@restlet.tigris.org
Sent: Friday, September 7, 2007 5:58:30 PM (GMT-0500) America/New_York
Subject: Re: sessions debate (was Re: some benchmarking)
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
--
Justin Stanczak
Stanczak Group
812-735-3600
"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
