If i understand you correctly, you are saying that a
home-grown cookie "session" mechanism would be
insecure. I'd agree with you on this, I've seen this a
lot, especially in my early CGI days.
As for good ways of holding sessions, I'd recommend
making a standard way of managing server and client
sessions, and implement it either as a plug-in, code
templates, or document it as the recommended way. I
really have a hard time catching any It security
managers turning away from Restlets because it doesn't
send it's state over the wire in a cookie instead of
other ways. He or she probably would want to go over
the application to see if there's any security
implications, but there are quite a few ways of
ensuring security here.
--- serge <[EMAIL PROTECTED]> wrote:
> Stanczak Group <justin <at> stanczakgroup.com>
> writes:
>
> >
> > Good point. So far everything I've made uses Swing
> clients, so I haven't
> > really thought about the limitations of using
> cookies. I would have to
> > agree on the use of session. They shouldn't be
> included in Restlets. I
> > was always weary of using sessions in Servlets.
> Seemed like a lot of
> > people didn't mind just dropping anything in
> there, and most probably
> > just let whatever framework they use handle it.
> ...
>
> The sessions we are talking about are not real
> sessions. Real sessions are not
> possible with current Web protocols. We can talk
> only about session surrogates.
> Because of this, when I hear cookies I am thinking
> "sessions" - support for
> cookies is already support for those faked sessions.
> And of course this is not
> the only way to fake sessions (but most popular).
>
> The problem is that, most likely,
> home-grown-cookies-based-sessions will be
> really bad - there is one big problem that strangely
> missing in this discussion.
> Security. Yes, there are problems with scalability,
> memory management - but
> these, as strange as it may sound, are not immediate
> problems. The security is.
>
> My position on this issue though comes not from
> technical considerations but
> rather from business ones. As this point the lack of
> any *good* support for what
> is called HTTP session will be very damaging for the
> Restlet framework. I cannot
> predict to what extent it can damage this baby, but
> it will be very damaging.
> This purism in its belief in what is right and what
> is not usually does not end
> up in great successes. This reminds me of the
> "prohibition" experiments in
> America. Guess what, if you think you can prohibit
> alcohol by changing
> constitution (because it's bad and people sometimes
> DUIs) - people are not going
> to listen to you even if it's in the constitution.
>
> Same way, arguments about HTTP sessions that are bad
> because people put there
> stuff that should never be there are just out of
> place and time. The devil is
> there, the rest (I like this game of words!) cannot
> ignore its existence. What
> will happen is that the actual experience will put
> the REST (and Restful
> framework) into perspective - the market will decide
> through its systems of
> opportunity costs whether it wants it or not. I
> would also like to point out
> that software engineers and Web developers will not
> be the only judges. You will
> also have project managers and security folks and,
> at the end, users.
>
> Serge
>
------------------------------------------------------------
Kyrre Kristiansen
___________________________________________________________
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good
http://uk.promotions.yahoo.com/forgood/environment.html
