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
