client statefull server stateless

[ytrewqsm]

I read this on with several ocassions while reading about GWT.

Now can anyone clear this for me ?

1)What this means that on server side is recommended not to use
servlet session ?

2)How can i secure the application if the client only has state and
server is stateless ?

3)BTW Each time i pass credential on method calls ? Is that not
something insecure ?

4)How can those be passed securely ?

THX

[Thomas Broyer]

On 3 juil, 06:59, ytrewqsm <ytrew...@gmail.com> wrote:
> I read this on with several ocassions while reading about GWT.
>
> Now can anyone clear this for me ?
>
> 1)What this means that on server side is recommended not to use
> servlet session ?

To keep things simple: yes.

> 2)How can i secure the application if the client only has state and
> server is stateless ?

I don't understand... Read about "REST", it says it all.

> 3)BTW Each time i pass credential on method calls ? Is that not
> something insecure ?

How would you do it otherwise?
Having a stateless server doesn't mean you have to send username/
password on each request; you could very well establish a first
handcheck and then send an auth ticket on each call. I'd say that for
this handcheck you *could* use a servlet session (that would be the
only exception when you could use one), though I wouldn't recommend it
security-wise (search for CSRF, e.g. http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf
)

> 4)How can those be passed securely ?

See above.

But in a few words, when one talks about a stateless server, one
generally don't talks about authentication, as this requires some sort
of "shared state" to make it secure.

[Cristian Chiovari]

What do you mean by "shared mode " ?

Can you plz detail a little bit,with a use case or so ?

[ytrewqsm]

Shared mode ?
What is that ?

On 5 Iul, 04:16, Thomas Broyer <t.bro...@gmail.com> wrote:
> On 3 juil, 06:59, ytrewqsm <ytrew...@gmail.com> wrote:
>
> > I read this on with several ocassions while reading about GWT.
>
> > Now can anyone clear this for me ?
>
> > 1)What this means that on server side is recommended not to use
> > servlet session ?
>
> To keep things simple: yes.
>
> > 2)How can i secure the application if the client only has state and
> > server is stateless ?
>
> I don't understand... Read about "REST", it says it all.
>
> > 3)BTW Each time i pass credential on method calls ? Is that not
> > something insecure ?
>
> How would you do it otherwise?
> Having a stateless server doesn't mean you have to send username/
> password on each request; you could very well establish a first
> handcheck and then send an auth ticket on each call. I'd say that for
> this handcheck you *could* use a servlet session (that would be the
> only exception when you could use one), though I wouldn't recommend it

> security-wise (search for CSRF, e.g.http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

[brett.wooldridge]

It really depends on your application. If you have 100 simultaneous
users,
sure go ahead and use server sessions. If you are designing the next
gmail, ebay, or facebook, then server-side conversional state is a
HUGE
scalability mistake. Ebay, for example, is [almost] completely
stateless
(on the server).

For security there are many options. One of the most common is for
the
server to generate a security token of some sort during login that is
returned to the client.

Google (at least the Google Wave guys) would probably say using a
cookie
to pass it back to the server is a mistake -- pass it on every RPC
instead.
This can avoid some cross-site scripting attacks. Remember, cookies
are
automatically sent by the browser to the server. If you pass it by
RPC, then
YOU control when/if it is sent. But really, that part is your call.
The principal
is the same. The server can validate (yes, on every call) whether the
security
token is (still) valid. This is no costlier CPU-wise than a servlet-
session
lookup, and the memory reduction costs and fail-over advantages are a
big
win.

Using servlet-sessions is no more (and probably less) secure. With
typical
server-sessions when a user authenticates (presumably over SSL) a
cookie
is returned. That cookie is all that is required to access the
session-state
on the server. Unless every request is encrypted, it passes in the
clear.
So, in the end, the more "state" you can keep on the client, the less
susceptible it is to access by an attacker.

The only way to be *completely* secure is to encrypt all wire
traffic. Short
of that, there is no security advantage of server-sessions. There are
in fact
more disadvantages, as noted, due to the accessibility of server-state
given
knowledge of the session cookie.

As an aside, you can theoretically mutate the security token upon
every
request, this avoiding a "replay" attack and "out-of-sequence"
requests that
indicate a man-in-the-middle attack can be detected. In general, that
kind of
security is completely overkill. If you're writing a banking or
financial
application, just use SSL and be done with it -- rolling your own
security is
likely to have holes and attack vectors you never imagined.

-Brett

[Thomas Broyer]

On 5 juil, 09:31, ytrewqsm <ytrew...@gmail.com> wrote:
> Shared mode ?
> What is that ?

Did I say "shared mode"??? Reading my message again, I see "shared
state": some state shared by the client *and* the server.

[Kwhit]

I think ytrewqsm has a point.

If user X has authenticated, the server can know which user it is
(stateful) and refuse to change (for example) another user's profile
in response to a "Change user Y's password to xyz" request.

If the server is stateless and the logged in user state is held on the
client (recommended) then the server will innocently go ahead and
process the a spoofed change password request (and any other spoofed
request).

I think that is what ytrewqsm is getting at

[brett.wooldridge]

The server can still know who the user is, if the user passes a
security token back to the server. This token can either be in a
cookie, or passed programatically though the RPC call. Typically it
is generated when the user logs in. This is the same as when you set
your gmail account to "stay logged in". There is a cookie, generated
by Google when you logged in the first time that is served back to
Google when you revisit www.gmail.com. No other site can access your
site's cookie, even though JavaScript.

With respect to cross-site scripting, you simply have to code against
it in this scenario. Or, if you use RPC to pass the token rather than
relying on cookies, you don't have to worry about it at all.

The token can be anything from a meaningless identifier to something
sophisticated like a Blowfish encrypted version of the user's ID,
allowing the server to validate who is making the request and ensuring
it is against the correct account. This is not rocket science. It is
indeed possible to write a stateless server that is completely secure
and safe from cross-site scripting attacks. A stateless server will
allow your application to scale to millions of simultaneous users.
If, as I said in my first post, you have an application with only a
few hundred simultaneous users then sure, go right ahead and build a
stateful server. But you still have to guard against cross site
scripting attacks, because every almost every stateful server will
rely on cookies for session identification. Old-school URL-based
session identifiers are even a worse security problem.

-Brett

[ytrewqsm]

My plan is not no make another facebook :) is just a small erp.

that initially will run into a VPN but i would like to expose as a web
app in the near future.

I uderstood the advandatges of keeping the server
stateless ,security,failover since session are not going to be
replicated from fasiled server and so on.

BUT :"The only way to be *completely* secure is to encrypt all wire
traffic"

How can i do that ?

What are the drawback on this except a little bit slower application ?

Thx a lot for prev answers to all of u !


On 6 Iul, 10:23, "brett.wooldridge" <brett.wooldri...@gmail.com>
wrote:

> > THX- Ascundeţi textul citat -
>
> - Afişare text în citat -

[ytrewqsm]

Thx brett....

So stateless mean no usgae of servlet http session ?

Since assume the following scenario :

A user does some query that is based on some query paramter he has.
Then the result is dispalyed in pages on client side. in 100 / page.
(but the results are huge 10000)
On server side there has to be a cache or soemthing that "remember"
the results of that query to display the next 200 and so on
So a the server still has a state no ?

Do i miss somenthign ?

Or each time the server will execute a queryu to get first 100 then
next 100 and so on ?

> > - Afişare text în citat -- Ascundeţi textul citat -

[Thomas Broyer]

On 6 juil, 21:46, ytrewqsm <ytrew...@gmail.com> wrote:
> Thx brett....
>
> So stateless mean no usgae of servlet http session ?

Yes (or any other mechanism that stores values on the server-side
depending on a value given to a client and sent back in the requests).

Stateless means that the server state is entirely contained into the
resources and requests/response; in a word, a given request on a given
resource (URL) doesn't depend on a previous request having been done
before.

Imagine an document management webapp. It can be stateful if you store
the "current folder" on the server-side and use requests (probably
HTTP POST) similar to "cd subfolder", "cd ..", etc. to navigate int
the folder hierarchy. Or it can be stateless if you have an URL per
folder and use links to the other "folder URLs".
To create a new subfolder, in the stateful impl, you'd send an "mkdir
subfolder" and it would use the "current folder" to know where to
create the new folder; while in the stateless impl, you'd rather send
a request to the URL representing the "parent folder" to say "create a
folder named 'subfolder' as a child as *this* folder".

> Since assume the following scenario :
>
> A user does some query that is based on some query paramter he has.
> Then the result is dispalyed in pages on client side. in 100 / page.
> (but the results are huge 10000)
> On server side there has to be a cache or soemthing that "remember"
> the results of that query to display the next 200 and so on
> So a the server still has a state no ?

Not necessarily (in the "REST" sense): the server would store the
results "somewhere" with a bunch of URLs corresponding to the result
pages. If another user makes the very same request, the server might
be able to reuse the same resultset. To save resources, the server
would probably "expire" and drop the resultset. That doesn't mean the
server is stateful.

In "REST" parlance, the server is creating temporary *resources*; the
resources have their own state, but the server has no state by itself.

> Do i miss somenthign ?
>
> Or each time the server will execute a queryu to get first 100 then
> next 100 and so on ?

It is a possibility too; it depends on what is the most efficient:
making such "page" requests or storing results in a temporary resource
(could be hundreds of pages, where most of them won't ever be used in
the end).

You should really read about REST; it will answer most of your
questions about stateless vs. stateful.

[Dean S. Jones]

My recent experience was to not trust the client AT ALL. If you send
any info to the client ( Cookie, or a token to be sent back on RPC ),
someone with
knowledge enough could use a JS debugger and modify the memory
containing the token, and your busted.

Personally, I use multiple methods. Everything is over https, the
cookies are marked secure. The cookie is reset each request with a
value from initial sign in, plus a "next sequence number" that is...
non linear, and SHA-1 encoded. The SHA'd cookie value, a "state
token***" + IP address of the last request are recorded in "shared
memory" in the cluster(Terracotta) for the session ID. If the next
request does not match, or the source IP does not match, we refuse the
RPC, kill the session, and redirect them back to sign in. ( We don't
worry about the various cases when a source IP can change ( this is
banking software ), because the clients ID is associated with a
whitelist IP range for the clients registered sites/proxies/gateways),
each RPC IP then is also checked against the client whitelist. The
"state token***" is sort of a FSM key - for any given action/screen,
the "possible next request" is a known subset of all operations in the
system. The request must be in that set - or a "navigation" to another
higher level in the theoretical FSM. i.e. if you last request was
"fetch portfolio instruments", the next can only be portfolio
operations, or nav "higher", not an arbitrary "change user settings"
RPC, etc.

[Dean S. Jones]

to be clear - in the above post, we keep no "state" in the server
other than the info associated with the session ID, and that info is
NOT stored in the Session Context. As many have found in the past,
storing session state leads to performance issues in session
serialization and server sync cross-talk in J2EE clusters. Even tho
the data kept is like 128 bytes ( which would seem harmless ), it
still leads to significant I/O for a LARGE number of users. Terracotta
could be used to bypass this and store alot of data in the session,
but architecturally, we just don't do it as a rule.

We do cache certain expensive queries, some associated with user ID's,
but they are expired after a timeout or FSM root change. ( this is
used in the case of say... showing a table of hundreds/thousands of
instruments in a portfolio, but the table has paging and sorting )

[brett.wooldridge]

Nice. And as noted by Dean, this is a financial/banking application.
You have to go the extra mile and then some in that case. That said,
most of the "rest of us" (including the likes of gmail, ebay,
facebook) aren't overly concerned with user's messing with their
cookies.

-Brett

[brett.wooldridge]

Just to be clear, there is a difference between "server state" and
"per-user state". The former is generally an order of magnitude or
three smaller than the later.

Let's consider the example of ebay. While not intimately familiar
with the details of ebay's architecture, I've read their whitepapers
(google "ebay scalability" if interested). Anyway...

There are two options -- probably more -- but two basic options if you
think about a paged ebay search result.

First option, traditional "servlet session" style state management.
User performs a search, that search result (or a reference to it) is
stored in the user's session, along with a "current page" or "current
item" indicator. When the user "pages" forward, their session state
is updated to reflect the current page their on. This has two big
implications. One, search results are unique to each user -- a
massive storage requirement for millions of simultaneous users. Two,
session state is frequently updated and because it's replicated for
failover is creates massive "back channel" chatter. Ebay *used* to
have this architecture. It crushed them and they had to re-architect.

Second option, recognize that users search for the same kinds of
things: "ipod nano", "macbook", "oakley". Store/cache search results
and share them between users. Use a URL parameter to determine what
page to show a user, rather than keeping track on the server of what
page they are on. Go to ebay and perform a search for "ipod", you'll
get a URL that looks like this:

http://shop.ebay.com/items/__ipod?...&_pgn=1

First tip they are using a cache is the __ipod in the URL. Second,
you can see the "paging" parameter on the end of the URL. If you go
to the next page of the result, _pgn will be 2.

Clearly, ebay is not "completely stateless". It has to store/cache
search results. However, these are not "per-user". Ebay is stateless
with respect to "user state". "Who you are" is handled by a cookie.
But if you look at your ebay cookies you'll see one called
"nonsession". :-) Maybe a joke on their part, but it reflects the
reality. Certainly you can maintain a hash of "nonsession" to true
user identity in the server. Maybe you would consider this "user
state", but I don't. There is a big difference between that kind of
state (to validate identity) and storing navigation position, history,
preferences, etc. in the server. Ebay jams about 15 cookies down your
throat so they don't have to keep that stuff in their memory or
replication it across servers.

Hope that clarifies the approach somewhat.

-Brett


On Jul 7, 4:46 am, ytrewqsm <ytrew...@gmail.com> wrote:
> Thx brettt

[Dean S. Jones]

Yes, I work in banking, so I tend to see the world through "paranoid
color glasses", my above replies really only scratch the surface of
required precaution, but you get the idea. For most people, "state in
the client" + cookies or RPC tokens will do. Also, the GWT compiler/
optimizer/minimizer makes it damn hard to even have a chance of
understanding the generated JS, let alone hack it.

That said, if your site is public facing, you should take some
reasonable measures to protect it.

On Jul 6, 9:26 pm, "brett.wooldridge" <brett.wooldri...@gmail.com>
wrote:

[ytrewqsm]

Thx a lot...i got a lot of information...i try now to process all of
it.
Still after first reading ,REST like application is based on url's and
stuff
How can that be applied to a GWT app which is based on RPC.
This is like a one page application....so ?

> > > RPC, etc.- Ascundeţi textul citat -

[Kwhit]

I'm interested in Dean's comments on performance impact of session
data which seems counter intuitive to me (not that I doubt you at all
Dean, just want to understand!)

1/ The session is going to be stored anyway right. That's part of the
contract with the client. I don't know what this equates to in terms
of bytes but I guess it's not less than a 100.

2/ ytrewqsm's original problem would be solved by storing one single
long in the session: the user ID. The session is 'secure enough' for
many applications (banking, etc., excepted). Each service request made
by the client in the context of that session can be authenticated

3/ We can't, and don't need to avoid being platform specific - we are
talking GAE not WebSphere, WebLogic, JBoss, ... My guess is that the
session will be stored somewhere in BigTable and will be scalable.

4/ For all other state needs - throw them at the client. There's a
bunch of memory and CPU power out there that's free for the
application - use it but keep an eye on client performance

The alternative has a large impact on the design of the client raising
the entry barrier significantly and I don't think that's in line with
GAE's endgame.

[Thomas Broyer]

On 7 juil, 10:20, Kwhit <kwhitting...@gmail.com> wrote:
> I'm interested in Dean's comments on performance impact of session
> data which seems counter intuitive to me (not that I doubt you at all
> Dean, just want to understand!)
>
> 1/ The session is going to be stored anyway right. That's part of the
> contract with the client. I don't know what this equates to in terms
> of bytes but I guess it's not less than a 100.

No!
A session is only created when needed (in Java servlet land, with a
default config). If you never ever call getSession(), you'll never
have the session overhead (and cookie). (you can also use getSession
(false) to check the existence of a session without creating one)

> 2/ ytrewqsm's original problem would be solved by storing one single
> long in the session: the user ID. The session is 'secure enough' for
> many applications (banking, etc., excepted).

Provided you disable cookie-less sessions and renew the session at
login, yes (session-fixation CSRF attacks are soooooo easy otherwise).

CSRF should be taken into account seriously on every web application
(think web mail such as GMail or Yahoo! Mail, social apps such as
Facebook and Twitter, etc. if someone can read your mails or send
mails/tweet/etc. on your behalf!)

> Each service request made
> by the client in the context of that session can be authenticated

Er, let's just say "attached to a given user".

> 3/ We can't, and don't need to avoid being platform specific - we are
> talking GAE not WebSphere, WebLogic, JBoss, ... My guess is that the
> session will be stored somewhere in BigTable and will be scalable.

Oh, if we're only talking about GAE, then yes, using Google Accounts-
based auth is probably the best choice. But if you roll your own auth
mechanism, it's really easy not to use servlet sessions, and therefore
achieve better security and scalability (that's a problem of sessions
too, when you start using a cluster)

[brett.wooldridge]

GWT can support REST easily.

See:

http://code.google.com/webtoolkit/doc/1.6/DevGuideServerCommunication.html

The section on Making HTTP Request should help. Personally, I opt for
standard GWT RPC, but I'm a spoiled Java coder.

-Brett

[ytrewqsm]

Thx ... but RPC & REST is not possible.

I prefer using RPC as well.

On Jul 7, 2:50 pm, "brett.wooldridge" <brett.wooldri...@gmail.com>
wrote:

> GWT can support REST easily.
>
> See:
>

> http://code.google.com/webtoolkit/doc/1.6/DevGuideServerCommunication...

[ytrewqsm]

but RPC & REST is not possible. ???

i forget the ?

[Thomas Broyer]

On 7 juil, 10:18, ytrewqsm <ytrew...@gmail.com> wrote:
> Thx a lot...i got a lot of information...i try now to process all of
> it.
> Still after first reading ,REST like application is based on url's and
> stuff
> How can that be applied to a GWT app which is based on RPC.
> This is like a one page application....so ?

RPC by definition isn't RESTful; but you can just use in RPC what you
learned about statelessness of the server while reading about REST;
concepts are the same, just the messages exchanged over HTTP would be
different (and make you loose ability to cache responses at the HTTP
level and otherwise control "cachingness" of your data; but if all
your data has to be requested once authenticated, this isn't a big
lost; just that you have to code a client-side cache if you want some
caching, while with a REST approach you can just take advantage of
HTTP caching features).

[Cristian Chiovari]

For a finacial application ,which is not EBay or facebook

i think resusing HTTP caching features has very low chances of being used since

is not a common case and rarely it may happen to have that.