14:24
> À : discuss@restlet.tigris.org
> Objet : Re: sessions debate (was Re: some benchmarking)
>
> Adam,
>
> My rant about load balancing and cookies was intended
> to be a point in the case against session state on the
> server. I just got carried away, and din't get my
&
Adam,
My rant about load balancing and cookies was intended
to be a point in the case against session state on the
server. I just got carried away, and din't get my
point across very well :-)
I've never used Terracotta, but have heard of one
project using it, and they're quite happy with it.
Pro
That's cool. The memcached looks like it has a Java client. I was
thinking you could also make a JMS or Javaspaces setup to handle session
clusters.
Kyrre Kristiansen wrote:
Yes, you are right.
You really have two options for this,
1. Use the database. This might not be a good solution
for s
You should check out Terracotta. http://www.terracotta.org/ It does
shared cross-JVM memory management pretty seamlessly. It's open source.
Being the good REST programmer that I am :), I don't keep session state
on the server. But, if I had to do it, they have a really slick way to
manag
From: "Kyrre Kristiansen" <[EMAIL PROTECTED]>
To: discuss@restlet.tigris.org
Sent: Wednesday, September 12, 2007 11:00:42 AM (GMT-0500) America/New_York
Subject: Re: sessions debate (was Re: some benchmarking)
Yes, you are right.
You really have two options for this,
1. U
Yes, you are right.
You really have two options for this,
1. Use the database. This might not be a good solution
for short-length, time-based session data.
2. Use some sort of cluster-sharing, eg memcached
(which is C++, but I believe there's a Java-version
for it as well), or other solutions.
3
Kyrre Kristiansen wrote:
simple round-robin of a cookie-less system. And, if
you want to make quick, highly reliable services, load
balancing is almost as king as cache...
Kyrre, thx for pointing me to this,
I read this as the intrinsic point that 'resource-state' should be
shared in the s
- 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
et.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
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 i
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
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, use
On the point of session security, it can be only as secure as the
network connection. So if you encrypt the communication channel does the
session matter that much? The session just becomes a part of the
software. If you look at it based on security from logged in users then
you still have to e
Rob Heittman solertium.com> writes:
>I genuinely don't fully understand the distinction of a "surrogate" or "fake"
session versus a "real" one in this context. This is probably a failure of my
education. Can you (or someone else who gets this) give me a reference to some
reading material?
=
Hi Serge,
> 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 tho
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
kout process,
> your Step 3 page could actually contain all the
> carried over data from Step 1 and Step 2 (e.g.
> hidden fields), or it could contain some kind of
> identifier pointing to a server-side resource that
> held previously entered data
> (/app/v1/orderforms/{id}), or your brow
Stanczak Group 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
want multiple browser windows to
always point to the same resource). In any of these ways, the server
has sufficient information to understand the request and act on it.
/rant
:-)
- R
- Original Message -
From: "Stanczak Group" <[EMAIL PROTECTED]>
To: discuss
le browser windows to always point to the
same resource). In any of these ways, the server has sufficient information to
understand the request and act on it.
/rant
:-)
- R
- Original Message -
From: "Stanczak Group" <[EMAIL PROTECTED]>
To: discuss@restlet.tigris.org
For sure: keep all "application" state all you want and where you
want. I dont think that what Roy F. wrote in his dissertation goes
against that at all (And I dont think the Restlet framework forces you
to do that either).
The only thing I read from that quote is that REST is stateless with
respe
Really I had planned on creating an interface that uses something like
XStream with Cookies.
Stanczak Group wrote:
So why do cookies not fill this session gap? Is that to much client
side dependence?
Rob Heittman wrote:
There's a massive amount of er, what did you say, "dry theory and
volu
So why do cookies not fill this session gap? Is that to much client side
dependence?
Rob Heittman wrote:
There's a massive amount of er, what did you say, "dry theory and
voluntary speak" on the question of sessions and continuations
vis-a-vis REST. Unashamed, I'll add more.
The rub here
There's a massive amount of er, what did you say, "dry theory and voluntary
speak" on the question of sessions and continuations vis-a-vis REST. Unashamed,
I'll add more.
The rub here is adherence to Fielding's "Stateless" constraint (5.1.3: "each
request from client to server must contain a
Rob Heittman wrote:
Great article, Serge!
I would offer this viewpoint on the Session concept. The transparent
instant availability of an general-purpose Session, as in JSP/Servlet,
is ridiculously convenient for about a billion reasons, and therefore a
powerful seduction to not really en
25 matches
Mail list logo
