authentication in GWT

[Litty Preeth]

Hi All,

What should be the best authentication ans session management in GWT apps? Currently I am having this idea:

• Have a method checkSession() which will check for a valid authenticated session and throws an Exception if no valid session is there.
• Call this method in the beginning of every ServiceImpl method.
• In the onFailure of the async call backs catch this Exception and display the login page.

But this method has the following weak points:

• Some developer may forget to call the checkSession method.
• There is code duplication in the onFailure implementation (Every onFailure shud handle the authentication exception)

So any of you have any better ideas?

Regards,
Litty Preeth

[olivier nouguier]

Hi Litty,

I've played with Spring security && GWT at
http://code.google.com/p/net-orcades-spring/

If you're confident with Spring (Security) && GWT the lack of
documentation won't block you :-/

--
Si l'ignorance peut servir de consolation, elle n'en est pas moins illusoire.

[Schimki86]

Is there an example how to start up with Spring (ACEGI / Spring Security) & GWT? What and where I have to configure Spring? I want to implement a User- Login too. Can someone attach an example here in Google Groups?

2008/11/18 olivier nouguier <olivier....@gmail.com>

[Litty Preeth]

But I am not using Spring... :(

So any other ideas???

[olivier nouguier]

On Tue, Nov 18, 2008 at 1:08 PM, Schimki86 <schi...@googlemail.com> wrote:
> Is there an example how to start up with Spring (ACEGI / Spring Security) &
> GWT?

Yes there is a war sample and the project that generate that war
(net.orcades.spring-gwt-sample).
All is provided in the checkout.
It's maven driven.

[Lothar Kimmeringer]

Litty Preeth schrieb:

> But this method has the following weak points:
>

> * Some developer may forget to call the checkSession method.

>
> So any of you have any better ideas?

You can overwrite
public String processCall(String payload) throws SerializationException
and do the following:
RPCRequest rpcRequest = RPC.decodeRequest(payload, this.getClass(), this);
if (!rpcRequest.getMethod().getName().equals("login")){
if (!validSession()){
return RPC.encodeResponseForFailure(null, new InvalidSessionException());
}
}
return super.processCall(payload);

So all methods except the login-method will lead to the check
of a valid session. If there is none, a special exception is
thrown, otherwise the standard-way is performed.

> * There is code duplication in the onFailure implementation (Every

> onFailure shud handle the authentication exception)

Implement an AsyncCallback that checks the exception in onFailure
to be InvalidSessionException and react accordingly. Use this
implementation instead of the interface for creating your inner
classes when calling RPCs.

Regards, Lothar

[walden]

You could try the simplest thing that could possibly work...HTTP
Authentication: let the existing security stack earn its keep.

Walden

On Nov 18, 6:52 am, "Litty Preeth" <preeth.h...@gmail.com> wrote:
> Hi All,
>
> What should be the best authentication ans session management in GWT apps?
> Currently I am having this idea:
>

>    - Have a method checkSession() which will check for a valid authenticated

>    session and throws an Exception if no valid session is there.

>    - Call this method in the beginning of every ServiceImpl method.
>    - In the onFailure of the async call backs catch this Exception and

>    display the login page.
>
> But this method has the following weak points:
>

>    - Some developer may forget to call the checkSession method.
>    - There is code duplication in the onFailure implementation (Every

[olivier nouguier]

I agree with walden in most case ... if classic HTTP auth is enough
let HTTP do the job !!

But there is IMHO somes points hard to deal with only HTTP (and GWT
component of course):
* session expiration, because the GWT RPC will fail soon (401).
* forbiden because the GWT RPC will fail soon (403).
* activation of widget when authority is granted.
* logout (not possible with HTTP Basic).

[Litty Preeth]

Actually my applications authentication is done by a third party. I need to call their API to authenticate. So I wont b able to use the HTTP authentication. But I think, Lothar's idea is worth trying. Thnx Lothar.

If anybody has any better suggestions plz post it here.

- Litty

[olivier nouguier]

You could use basic HTTP authentication with a Jaas Module, but it's
much much pain then integrating Spring :)

[Ian P. Christian]

2008/11/18 olivier nouguier <olivier....@gmail.com>:

> Yes there is a war sample and the project that generate that war
> (net.orcades.spring-gwt-sample).
> All is provided in the checkout.
> It's maven driven.

This sample doesn't appear to work correctly 'out of the box'.

I did a 'source:jar install' on the 3 components, and then tried to
run the gwt-sample app:

pookey@fork:~/net-orcades-spring-read-only/orcades-spring-gwt-sample$
mvn gwt:gwt

URL: http://localhost:8888/springsample.SampleModule/SampleModule.html
"Cannot find resource 'SampleModule.html' in the public path of module
'springsample.SampleModule' "

Regards,

Ian

[Ian P. Christian]

2008/11/18 Ian P. Christian <poo...@pookey.co.uk>:

>> Yes there is a war sample and the project that generate that war
>> (net.orcades.spring-gwt-sample).
>> All is provided in the checkout.
>> It's maven driven.
>
> This sample doesn't appear to work correctly 'out of the box'.

Sorry, perhaps this would have been more useful:

[INFO] establishing classpath list (buildClaspathList - scope = COMPILE)
[INFO] google.webtoolkit.home (gwtHome) set, using it for GWT
dependencies - /home/pookey/src/gwt-linux-1.5.3
Loading module 'springsample.SampleModule'
Loading inherited module 'com.allen_sauer.gwt.log.gwt-log-INFO'
[ERROR] Unable to find
'com/allen_sauer/gwt/log/gwt-log-INFO.gwt.xml' on your classpath;
could be a typo, or maybe you forgot to include a classpath entry for
source?
[ERROR] Line 9: Unexpected exception while processing element 'inherits'
com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)

[walden]

Let's hear a bit more about that third party API for authentication.
Can you post the interface? Is it used for managing the login form,
or does it just handle the mapping of usernames to passwords and
roles? Depending on your answer, this may not preclude using HTTP
authentication *protocol*, which is where the simplicity/economy is to
be had.

Walden

On Nov 18, 10:40 am, "Litty Preeth" <preeth.h...@gmail.com> wrote:
> Actually my applications authentication is done by a third party. I need to
> call their API to authenticate. So I wont b able to use the HTTP
> authentication. But I think, Lothar's idea is worth trying. Thnx Lothar.
>
> If anybody has any better suggestions plz post it here.
>
> - Litty
>
> On Tue, Nov 18, 2008 at 9:04 PM, olivier nouguier <
>
>
>
> olivier.nougu...@gmail.com> wrote:
>
> > I agree with walden in most case ... if classic HTTP auth is enough
> > let HTTP do the job !!
>
> > But there is IMHO somes points hard to deal with only HTTP (and GWT
> > component of course):
> >  * session expiration, because the GWT RPC will fail soon (401).
> >  * forbiden because the GWT RPC will fail soon (403).
> >  * activation of widget when authority is granted.
> >  * logout (not possible with HTTP Basic).
>

> > On Tue, Nov 18, 2008 at 3:53 PM, walden <wmath...@aladdincapital.com>

> > wrote:
>
> > > You could try the simplest thing that could possibly work...HTTP
> > > Authentication: let the existing  security stack earn its keep.
>
> > > Walden
>
> > > On Nov 18, 6:52 am, "Litty Preeth" <preeth.h...@gmail.com> wrote:
> > >> Hi All,
>
> > >> What should be the best authentication ans session management in GWT
> > apps?
> > >> Currently I am having this idea:
>
> > >>    - Have a method checkSession() which will check for a valid
> > authenticated
> > >>    session and throws an Exception if no valid session is there.
> > >>    - Call this method in the beginning of every ServiceImpl method.
> > >>    - In the onFailure of the async call backs catch this Exception and
> > >>    display the login page.
>
> > >> But this method has the following weak points:
>
> > >>    - Some developer may forget to call the checkSession method.
> > >>    - There is code duplication in the onFailure implementation (Every
> > >>    onFailure shud handle the authentication exception)
>
> > >> So any of you have any better ideas?
>
> > >> Regards,
> > >> Litty Preeth
>
> > --
> > Si l'ignorance peut servir de consolation, elle n'en est pas moins

> > illusoire.- Hide quoted text -
>
> - Show quoted text -

[walden]

Olivier,

>  * session expiration, because the GWT RPC will fail soon (401).
>  * forbiden because the GWT RPC will fail soon (403).
>  * activation of widget when authority is granted.

I'm scratching my head wondering what those mean. In my app, RPC's
are secure and they don't fail. As for widget activation, you're
talking authorization, and I don't see any difference among the
proposals on that.

>  * logout (not possible with HTTP Basic).

And yet I have it. Go figure.


Walden

[Rick]

To logout from HTTP authentication use:

public void logout() {
HttpSession session = this.getThreadLocalRequest().getSession();
session.invalidate();
}

You can do this in your ServiceImpl class.


I kind of agree with Reinier, but might have used language that was
less strong.

[Johan Lundberg]

http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ

/johan

On 18 Nov, 12:52, "Litty Preeth" <preeth.h...@gmail.com> wrote:
> Hi All,
>
> What should be the best authentication ans session management in GWT apps?
> Currently I am having this idea:
>

>    - Have a method checkSession() which will check for a valid authenticated

>    session and throws an Exception if no valid session is there.

>    - Call this method in the beginning of every ServiceImpl method.
>    - In the onFailure of the async call backs catch this Exception and

>    display the login page.
>
> But this method has the following weak points:
>

>    - Some developer may forget to call the checkSession method.
>    - There is code duplication in the onFailure implementation (Every

[Litty Preeth]

Actually my app is a web interface to another backend app. So while logging into my app you are actually authenticating with the other backend app. The username/password, roles etc are maintained by the other app.

[Reinier Zwitserloot]

@Rick:

Ahh, that makes sense. However, its not logging out of HTTP Basic. Its
just invalidating a session ID. I also doubt that it'll work properly
if done in one browser session - the browser will keep re-sending the
Authorization header regardless of your invalidated session. The
browser doesn't know anything about the way sessions are stored on
your computer. You can perhaps do some hackery by generating a random
realm everytime but now you're hacking an inferior system - what's the
point?

For 'proof', see RFC2616. It specifically does not mention anything
about keeping the username/password entered around, however it is
quite specific about suggesting (which in RFC speak, is a strong
encouragement to do it) that you save this information, as a
webbrowser, because the browser may assume that all URLs 'below' the
URL that needed authentication also need authentication, and thus the
browser may pre-emptively send the header.

Most browsers don't store this information beyond a single session,
but in this day and age, people can go for many weeks without ever
closing their browser, so that is of little comfort. There's also no
rule that states that browsers aren't allowed to do it. The RFC, as I
mentioned, is deliberately low on detail, which is really bad for
security purposes. The followup RFC (2617) is also fairly specific
about never using HTTP-Basic to do serious authentication and strongly
suggests that you generate passwords for the user. Riiight - that's
going to go over real well in today's world.

Let's recap:

- Its such a weird and rarely used device that your average user will
flip out, and
- It is far more insecure than cookies and has dubious logout
capability.
- The official web standard urges you not to use it for what we're
talking about.

Ah, yes. That's why nobody uses it.

[olivier nouguier]

Walden
Sorry for your head ;).

On Tue, Nov 18, 2008 at 7:29 PM, walden <wmat...@aladdincapital.com> wrote:
>
> Olivier,
>
>> * session expiration, because the GWT RPC will fail soon (401).
>> * forbiden because the GWT RPC will fail soon (403).

When session is expired, the RPC will fail soon with a 401 (Auth
required status), before GWT 1.5 it was not (easily ) possible to
detect such failure. But session expiration is not an issue for HTTP
basic.

>> * activation of widget when authority is granted.
>
> I'm scratching my head wondering what those mean. In my app, RPC's
> are secure and they don't fail. As for widget activation, you're
> talking authorization, and I don't see any difference among the
> proposals on that.
>

About widget activation && authorization, I my proposal the widget are
aware of the authentication events so they can activate/desactivate
when login/logout occurs.

>
>> * logout (not possible with HTTP Basic).
>
> And yet I have it. Go figure.
>
>
> Walden
>
> >
>

[olivier nouguier]

gwt-log-2.5.2 is not available on public repository, did you install
by hand in yours ?

PS: as mentioned on
http://code.google.com/p/net-orcades-spring/wiki/Installation

[olivier nouguier]

Hi
It work for me...
* what is your environnement ? (OS, GWT version, java etc ...)
* did the war works out of hosted mode ?

[Ian P. Christian]

2008/11/19 olivier nouguier <olivier....@gmail.com>:

>
> gwt-log-2.5.2 is not available on public repository, did you install
> by hand in yours ?

Ohh... opps... I think this is the problem. I forgot that because
2.5.2 wasnt' available, I downgraded it to 2.5.0.....

sorry for the noise ;)

[walden]

Olivier,

I'm still a little perplexed, see below.

> >>  * session expiration, because the GWT RPC will fail soon (401).
> >>  * forbiden because the GWT RPC will fail soon (403).
>
> When session is expired, the RPC will fail soon with a 401 (Auth
> required status), before GWT 1.5 it was not (easily ) possible to
> detect such failure. But session expiration is not an issue for HTTP
> basic.>>  * activation of widget when authority is granted.

Originally, I thought your points were against HTTP auth, but now it
looks like they were for it?

>
> About widget activation && authorization, I my proposal the widget are
> aware of the authentication events so they can activate/desactivate
> when login/logout occurs.

This doesn't come up for me. I secure my site in such a way that you
don't get any widgets until you're authenticated and authorized. I
thought you were referring to a more fine grained authorization scheme
where certain widgets appear only for certain users. That sort of
entitlement management goes beyond authorization, and the point I was
making was that it seems somewhat orthogonal to what protocol you use
for auth.

Walden

[walden]

That's what I thought, and it does not exclude the possibility of
using HTTP auth at all. For example, JBoss ships with some
configurable authentication plug-ins for using back-end stores for
your realm data (JDBC, e.g.). In the worst case, you can roll your
own realm component (one Java class) and plug it in to the container's
security stack. What is your application server?

Walden

On Nov 18, 11:14 pm, "Litty Preeth" <preeth.h...@gmail.com> wrote:
> Actually my app is a web interface to another backend app. So while logging
> into my app you are actually authenticating with the other backend app. The
> username/password, roles etc are maintained by the other app.
>

> > > - Show quoted text -- Hide quoted text -

[olivier nouguier]

Walden,

See below, please.

On Wed, Nov 19, 2008 at 2:29 PM, walden <wmat...@aladdincapital.com> wrote:
>
> Olivier,
>
> I'm still a little perplexed, see below.
>
>> >> * session expiration, because the GWT RPC will fail soon (401).
>> >> * forbiden because the GWT RPC will fail soon (403).
>>
>> When session is expired, the RPC will fail soon with a 401 (Auth
>> required status), before GWT 1.5 it was not (easily ) possible to
>> detect such failure. But session expiration is not an issue for HTTP
>> basic.>> * activation of widget when authority is granted.
>
> Originally, I thought your points were against HTTP auth, but now it
> looks like they were for it?
>

I'm not talking of HTTP Basic Scheme where AFAIK there is no
expiration. I'm talking of Session Base mecanism like Acegi or Form
Based authentication.

What I was (trying) to explain is that when relying on a previous
authentication, then the GWT application is in fact unaware of being
under a restricted access. That might be a good (as it simple). But
when an error (security errors Auth Required (401) when session has
expired , a forbidden access (403)) occurs on a GWT-RPC call the GWT
application has to handle this error (much simpler under GWT >= 1.5).

So the GWT application has to handle some security concern (Auth
required && Forbidden).

>
>>
>> About widget activation && authorization, I my proposal the widget are
>> aware of the authentication events so they can activate/desactivate
>> when login/logout occurs.
>
> This doesn't come up for me. I secure my site in such a way that you
> don't get any widgets until you're authenticated and authorized. I
> thought you were referring to a more fine grained authorization scheme
> where certain widgets appear only for certain users.

I do ! Some GWT element may be notified for the authentication event
(granted authorities) and then they can do what they want ...

>That sort of
> entitlement management goes beyond authorization, and the point I was
> making was that it seems somewhat orthogonal to what protocol you use
> for auth.

Definitively !
>
> Walden

Regards
Olivier.

[Litty Preeth]

I am using Apache Tomcat 5.5

[Sumit Chandel]

Hello everyone,

Just a note that I've removed a couple of posts from this thread due
to inappropriate comments. This also seems like a good time to remind
everyone that we're here to collaborate and help each other, not to
curse or antagonize anyone.

One of the posts did contain some useful content aside from the
inappropriate bits, which I've posted below to keep the value of the
post on this thread.

Thanks,
-Sumit Chandel

---- Pasted from previous post ---

HTTP Authentication? Don't make me laugh - it's ridiculous design, and
more importantly, users don't get it. at all. They think your app is
broken and try to browse away (only they can't, that authentication
dialog box is modal). There's also no better security there than what
you can do with cookies, as it boils down to sending the username and
password in plain text to the server. I know, I know, its base64
encoded so it doesn't look like it on first glance, but -any- sniffer
-
anywhere- can see that its a Authorization header and de-base64 it.
It's the same thing from a security perspective.

There really is no problem here. If your developer can serve the
content without knowing the user's session information (which
presupposes that the session ID was checked and validated in the first
place), then its rather unlikely to be relevant,security wise. In
corporate settings there are some exceptions (downloading static
files / global uncustomized information which is still not meant for
outside eyes), but not too many.

On Nov 19, 5:54 am, "olivier nouguier" <olivier.nougu...@gmail.com>
wrote:

> Walden,
>
> See below, please.
>
>
>
> On Wed, Nov 19, 2008 at 2:29 PM, walden <wmath...@aladdincapital.com> wrote:
>
> > Olivier,
>
> > I'm still a little perplexed, see below.
>
> >> >>  * session expiration, because the GWT RPC will fail soon (401).
> >> >>  * forbiden because the GWT RPC will fail soon (403).
>
> >> When session is expired, the RPC will fail soon with a 401 (Auth
> >> required status), before GWT 1.5 it was not (easily ) possible to
> >> detect such failure. But session expiration is not an issue forHTTP
> >> basic.>>  * activation of widget when authority is granted.
>

> > Originally, I thought your points were againstHTTPauth, but now it

> > looks like they were for it?
>

> I'm not talking ofHTTPBasic Scheme where AFAIK there is no

> expiration. I'm talking of Session Base mecanism like Acegi or Form
> Based authentication.
>
> What I was (trying) to explain is that when relying on a previous
> authentication, then the GWT application is in fact unaware of being
> under a restricted access. That might be a good (as it simple). But

> when an error (security errorsAuthRequired (401) when session has

[walden]

In answer to the criticisms of HTTP authentication:

1. The generalilzations above about user experience don't click with
my experience with users. No one ever reported a broken application
on seeing the login dialog. THey really don't care if it's modal, if
the background is grey, or any of that stuff that seems to drive
developers to reinvent the authentication wheel in cookie-based
sessions.

2. It's not that HTTP Auth is better than what you can build with
cookies. I don't know if it is or it isn't. It's about not
reinventing a stack that's already there and functioning. A decade
ago HTTP auth was not well implemented across browsers, but that was a
decade ago.

3. Digest Authentication does not send plain text, and is as easy to
setup as Basic.

The last paragraph, Reinier, the one that starts "There really is no
problem here...", I'm not getting your meaning. HTTP Auth is just
another session that the developer doesn't have to program. But it's
also a session that's maintained on the client, so it's consistent
with the "stateless server" constraint of REST, and general network
application scaleability.

My application has a "logout" feature. It's a nice-to-have,
especially for me if I have to troubleshoot the appliation from a
user's terminal. But as a real security feature, it doesn't get much
use. If a user has to leave her work area and is concerned about
someone gaining unauthorized access, she is more likely to "CTL-ALT-
DEL,k" (which locks the entire computer) than to start logging out of
individual applications. It's easy to implement logout properly in
IE, harder with other browsers because they don't support a "clear
identity cache" function, but still possible. In fact, I wonder why
it is that the other browsers are not better in this respect.

Best,

Walden

On Nov 19, 1:40 pm, Sumit Chandel <sumitchan...@google.com> wrote:
> Hello everyone,
>
> Just a note that I've removed a couple of posts from this thread due
> to inappropriate comments. This also seems like a good time to remind
> everyone that we're here to collaborate and help each other, not to
> curse or antagonize anyone.
>
> One of the posts did contain some useful content aside from the
> inappropriate bits, which I've posted below to keep the value of the
> post on this thread.
>
> Thanks,
> -Sumit Chandel
>
> ---- Pasted from previous post ---
>

> HTTPAuthentication? Don't make me laugh - it's ridiculous design, and

> > >> aware of theauthenticationevents so they can activate/desactivate

> > >> when login/logout occurs.
>
> > > This doesn't come up for me.  I secure my site in such a way that you
> > > don't get any widgets until you're authenticated and authorized.  I
> > > thought you were referring to a more fine grained authorization scheme
> > > where certain widgets appear only for certain users.
>
> > I do ! Some GWT element may be notified for theauthenticationevent
> > (granted authorities) and then they can do what they want ...
>
> > >That sort of
> > > entitlement management goes beyond authorization, and the point I was
> > > making was that it seems somewhat orthogonal to what protocol you use
> > > forauth.
> > Definitively !
>
> > > Walden
>
> > Regards

> > Olivier.- Hide quoted text -

[Reinier Zwitserloot]

walden, please, pretty pretty please, stop confusing GWT users with
your very bad advice. You just restated your earlier arguments without
taking into consideration anything I wrote. Sticking your fingers in
your ears and singing loudly doesn't really work, and I request the
common courtesy that you stop doing that. Thanks.

Just in case you are clueless to the ways of HTTP standardization,
I'll get this out the way up front:

"RFC" Stands for Request for Comments, and a large stack of RFCs form
the standards of the internet. This includes HTTP, which is where HTTP
Basic Authentication is defined. Thus, anytime I say 'RFC', you can
replace that with 'the official standard', and it'll be semantically
correct, even though technically, HTTP does not really have a
universally recognized official spec that is called 'the official
spec'. The RFC is as close as you can get. And now, with no further
ado... replies inline.

On Nov 20, 3:40 pm, walden <wmath...@aladdincapital.com> wrote:
> In answer to the criticisms of HTTP authentication:
>
> 1. The generalilzations above about user experience don't click with
> my experience with users.

My experience is different. Perhaps more pointedly, name me 1 public
web app that uses HTTP-Basic.

When experiences conflict, go with what is most common.

> 2. It's not that HTTP Auth is better than what you can build with
> cookies.  I don't know if it is or it isn't.

I do know. It's worse. And I've explained, in lengthy detail, why HTTP
Auth sucks. I even mentioned that the authors of HTTP Auth (or as
close as you can get - the RFC) strongly suggest you don't actually
use it for authentication, just for identification. Please reread the
thread for the complete treatment about why HTTP Auth is technically
pretty bad.

>  It's about not
> reinventing a stack that's already there and functioning.  

There is no stack. Specifically, HTTP Auth doesn't let you keep your
login across browser restarts, which is something that every single
webapp that has any sort of success actually has, and is something
users obviously want. Even the security sensitive apps do this, just
so they can at least customize the things you see pre-login with non-
sensitive personal data, such as your username. (why the heck are you
using the security-broken HTTP Auth, again, according to the RFC
itself, if security is important enough to force re-logging in that
often anyway?)

Thus, you have to 'implement' a session ID anyway. You're still not
spilling the beans on how you log out with HTTP Auth, which is quite
interesting, because the RFC specifically says that you CANNOT log
out. Going with what another poster kindly explained, you're actually
invalidating the session, which means you've 'reinvented the wheel'
according to your own definition just the same.

I also find it insulting to say that the standard session management-
via-cookies principle is 'reinventing the wheel' somehow. If every
webapp this decade has been using it, then calling that 'reinventing
the wheel' is frankly facetious. You can't toss out terms with a
negative connotation when they don't apply.

>A decade
> ago HTTP auth was not well implemented across browsers, but that was a
> decade ago.

Actually, absolutely nothing changed in the way browsers implement
HTTP Basic Auth. The reason nothing changed is twofold:

1) HTTP Basic Auth was so extremely broken that it isn't fixable.
There' a new standard (HTTP Digest Auth), but it sees absolutely zero
use. I have no idea which browsers, if any even implement it. It
doesn't matter, because....

2) Everyone and their uncle was using forms instead of http basic
auth to relay user/pass to the server, so by the time either the
slowish RFC process, or the even slower browser evolution process in
the 6 years after IE6 was released, caught up with the notion that
HTTP Basic Auth totally sucked - it was no longer relevant.

>
> 3. Digest Authentication does not send plain text, and is as easy to
> setup as Basic.

it isn't even remotely as simple to set up. No one uses this. Browser
support dubious.

>
> The last paragraph, Reinier, the one that starts "There really is no
> problem here...", I'm not getting your meaning.

That wasn't in reply to you, that was in reply to the original post.
He was worried that a servlet wouldn't check the authentication and in
that way leak data. I merely mentioned that this can't usually even
happen, because there is no data to leak without first knowing who
requested the information. And the only way to do that is to check the
session data, which implies the session data was deemed valid,
security-wise. If his setup does not work that way, he's doing
something very weird, and he's doing it very wrong.

I also mentioned there are some exceptions to the rule - for example,
non-personalized data which is nevertheless only meant for people with
login credentials. This only applies if the app isn't a public webapp
that anyone can create an account for, obviously.

>  HTTP Auth is just
> another session that the developer doesn't have to program.

HTTP Auth isn't a session at all. Sessions are server-side constructs.
HTTP Auth is a client side thing. Your argument appears to be stuck in
a Salvador Dali painting.

If you meant that HTTP Auth is a session *TRACKING* system that a
developer doesn't have to program, then you're right. Fortunately,
cookies are also a tracking system that a developer doesn't have to
program. It's also safer, security-wise. It's also far more common.
It's also far more flexible. It also survives shutting down the
browser. You can also log those out.

>  But it's
> also a session that's maintained on the client, so it's consistent
> with the "stateless server" constraint of REST, and general network
> application scaleability.

There you go throwing about negative words that have absolutely no
relationship to the topic at hand again. Please don't do that.

Re-checking username/password for every request is as hard on the
database (and therefore just as hard to scale), or -harder- than
session IDs.

>
> My application has a "logout" feature.  It's a nice-to-have,
> especially for me if I have to troubleshoot the appliation from a
> user's terminal.

It's called 'public terminal'. Like, say, an internet café. Or a
friends computer. You could lock those, perhaps, until you return, but
someone is bound to get mad at you.

> In fact, I wonder why
> it is that the other browsers are not better in this respect.

Because nobody uses HTTP Auth. It has been effectively abandoned by
the developers first, and then both the RFC community and the browsers
followed suit. If you listen to the browser wars, absolutely nobody
gives a crap about HTTP Auth. Because nobody uses it. Simple, isn't
it? General rule about browsers: Don't use what nobody is using if
there's an alternative that works just as well or better using systems
that everybody uses.

From here on out I'll only rebut new facts. Please don't bother
reposting the same flawed arguments a third time.

[Sumit Chandel]

Hello everyone,

I think all arguments that can be made on this thread have been made.
Let's keep it friendly. I'm locking this thread; please take the time
you would have spent replying and spend it on thinking about how much
better this forum would be if we kept it positive and focused on the
technology.

Cheers,
-Sumit Chandel