gmane.comp.java.dwr.user

basic authentication (the right way)

Hi,

We’re using basic authentication for our GI app. Before we started using DWR, we passed login credentials via the open() method on GI’s jsx3.net.Request object. With DWR, I expected something similar to be required. However, we ended up hacking engine.js like this:

if (DWREngine.USER_NAME != undefined) {

batch.req.open(batch.httpMethod, request.url, batch.async, DWREngine.USER_NAME,

DWREngine.USER_PASSWORD);

}

else

batch.req.open(batch.httpMethod, request.url, batch.async);

We would set DWREngine.USER_NAME and DWREngine.USER_PASSWORD after logging in successfully. This works, but I’ve never felt comfortable with it. It’s messy etc. etc. etc.

What is the recommended way for doing this? Something like options to be set for the engine?

Regards

Johan Hoogenboezem

No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1445 - Release Date: 2008/05/15 07:25 PM

headers

Joe Walker | 17 May 12:57

Re: basic authentication (the right way)

The reason we've never exposed this is that DWR doesn't guarantee to use XHR. If you have an old Safari (and maybe a new Safari too), IE6 on Windows server, are using file-upload, cross-domain, or reverse ajax, then DWR may use iframe or script tags, where the username and password don't work the same way if at all.

You can still:
- set a custom header / cookie / parameter and check in an AjaxFilter
- use cookie based auth like EE role based security
- add the auth details to an extra parameter to the called methods.

Joe.

2008/5/17 Johan Hoogenboezem <JohanH-ZWJd6XJrmA8AvxtiuMwx3w@public.gmane.org>:

Hi,

We're using basic authentication for our GI app. Before we started using DWR, we passed login credentials via the open() method on GI's jsx3.net.Request object. With DWR, I expected something similar to be required. However, we ended up hacking engine.js like this:

      if (DWREngine.USER_NAME != undefined) {

        batch.req.open(batch.httpMethod, request.url, batch.async, DWREngine.USER_NAME,

          DWREngine.USER_PASSWORD);

      }

      else

        batch.req.open(batch.httpMethod, request.url, batch.async);

We would set DWREngine.USER_NAME and DWREngine.USER_PASSWORD after logging in successfully. This works, but I've never felt comfortable with it. It's messy etc. etc. etc.

What is the recommended way for doing this? Something like options to be set for the engine?

Regards

Johan Hoogenboezem

No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1445 - Release Date: 2008/05/15 07:25 PM

headers

Johan Hoogenboezem | 19 May 07:38

RE: basic authentication (the right way)

Joe, I understand your reason. My use of DWR is more conventional though and I use basic auth because it is so simple. It does not get in the way. By the time the request gets to my web application code, there’s already an authenticated principal. My application need not be cluttered with security stuff – as with your third suggestion. On the server I use role-based auth. The sql query that JBoss uses (as defined in login-config.xml) sorts out the roles the principal has. The DWR methods call stateless session beans where the methods are covered by <at> RolesAllowed annotations.

I’m not sure what you mean with the second suggestion.

As for your first suggestion: with a filter I think I’ll be moving away from basic authentication which I really don’t want to do.

I was hoping there was some hook through which DWR could allow me to construct the request object for it (I’d be using the jsx3.net.Request() class from the GI framework). Something elegant, instead of hacking engine.js. But if there is no other way, I’d like to continue to use my hack, if you’re ok with it.

Regards

Johan

From: Joe Walker [mailto:joe-klYz7rYGnPJg9hUCZPvPmw@public.gmane.org]
Sent: 17 May 2008 12:58 PM
To: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
Subject: Re: [dwr-user] basic authentication (the right way)

No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.20/1452 - Release Date: 2008/05/17 06:26 PM

headers

Joe Walker | 19 May 16:03

Re: basic authentication (the right way)

I think if you were to use cookie based auth rather than basic auth things would work better, however I can understand the hack to make things fit in with other server stuff.

I'll make a note and consider adding something if this request keeps popping up. In the mean time I'd prefer to encourage the use of Cookie based auth when there are no other server constraints.

Joe.

On Mon, May 19, 2008 at 6:38 AM, Johan Hoogenboezem <JohanH <at> izazi.com> wrote:

Joe, I understand your reason. My use of DWR is more conventional though and I use basic auth because it is so simple. It does not get in the way. By the time the request gets to my web application code, there's already an authenticated principal. My application need not be cluttered with security stuff – as with your third suggestion. On the server I use role-based auth. The sql query that JBoss uses (as defined in login-config.xml) sorts out the roles the principal has. The DWR methods call stateless session beans where the methods are covered by <at> RolesAllowed annotations.

I'm not sure what you mean with the second suggestion.

As for your first suggestion: with a filter I think I'll be moving away from basic authentication which I really don't want to do.

I was hoping there was some hook through which DWR could allow me to construct the request object for it (I'd be using the jsx3.net.Request() class from the GI framework). Something elegant, instead of hacking engine.js. But if there is no other way, I'd like to continue to use my hack, if you're ok with it.

Regards

Johan

From: Joe Walker [mailto:joe <at> getahead.org]
Sent: 17 May 2008 12:58 PM
To: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
Subject: Re: [dwr-user] basic authentication (the right way)

The reason we've never exposed this is that DWR doesn't guarantee to use XHR. If you have an old Safari (and maybe a new Safari too), IE6 on Windows server, are using file-upload, cross-domain, or reverse ajax, then DWR may use iframe or script tags, where the username and password don't work the same way if at all.

You can still:
- set a custom header / cookie / parameter and check in an AjaxFilter
- use cookie based auth like EE role based security
- add the auth details to an extra parameter to the called methods.

Joe.

No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.20/1452 - Release Date: 2008/05/17 06:26 PM

headers

Johan Hoogenboezem | 20 May 07:04

RE: basic authentication (the right way)

Thanks for the help, Joe. If it is something the container can help me do, then I’m happy to do cookie based auth. I just cannot afford to spend too much time on this. Is there a link where I can read more about it?

Regards

Johan

From: Joe Walker [mailto:joe-klYz7rYGnPJg9hUCZPvPmw@public.gmane.org]
Sent: 19 May 2008 04:03 PM
To: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
Subject: Re: [dwr-user] basic authentication (the right way)

On Mon, May 19, 2008 at 6:38 AM, Johan Hoogenboezem <JohanH-ZWJd6XJrmA8AvxtiuMwx3w@public.gmane.org> wrote:

Joe, I understand your reason. My use of DWR is more conventional though and I use basic auth because it is so simple. It does not get in the way. By the time the request gets to my web application code, there's already an authenticated principal. My application need not be cluttered with security stuff – as with your third suggestion. On the server I use role-based auth. The sql query that JBoss uses (as defined in login-config.xml) sorts out the roles the principal has. The DWR methods call stateless session beans where the methods are covered by <at> RolesAllowed annotations.

I'm not sure what you mean with the second suggestion.

As for your first suggestion: with a filter I think I'll be moving away from basic authentication which I really don't want to do.

I was hoping there was some hook through which DWR could allow me to construct the request object for it (I'd be using the jsx3.net.Request() class from the GI framework). Something elegant, instead of hacking engine.js. But if there is no other way, I'd like to continue to use my hack, if you're ok with it.

Regards

Johan

No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.20/1453 - Release Date: 2008/05/18 09:31 AM

headers

Joe Walker | 20 May 10:24

Re: basic authentication (the right way)

I did a quick search and found this:
http://edocs.bea.com/wls/docs61/webapp/security.html

There are probably some better resources, at least this will give you a few keywords to search on.

Joe.

2008/5/20 Johan Hoogenboezem <JohanH-ZWJd6XJrmA8AvxtiuMwx3w@public.gmane.org>:

Thanks for the help, Joe. If it is something the container can help me do, then I'm happy to do cookie based auth. I just cannot afford to spend too much time on this. Is there a link where I can read more about it?

Regards

Johan

From: Joe Walker [mailto:joe <at> getahead.org]
Sent: 19 May 2008 04:03 PM

To: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
Subject: Re: [dwr-user] basic authentication (the right way)

I think if you were to use cookie based auth rather than basic auth things would work better, however I can understand the hack to make things fit in with other server stuff.

I'll make a note and consider adding something if this request keeps popping up. In the mean time I'd prefer to encourage the use of Cookie based auth when there are no other server constraints.

Joe.

On Mon, May 19, 2008 at 6:38 AM, Johan Hoogenboezem <JohanH-ZWJd6XJrmA8AvxtiuMwx3w@public.gmane.org> wrote:

Joe, I understand your reason. My use of DWR is more conventional though and I use basic auth because it is so simple. It does not get in the way. By the time the request gets to my web application code, there's already an authenticated principal. My application need not be cluttered with security stuff – as with your third suggestion. On the server I use role-based auth. The sql query that JBoss uses (as defined in login-config.xml) sorts out the roles the principal has. The DWR methods call stateless session beans where the methods are covered by <at> RolesAllowed annotations.

I'm not sure what you mean with the second suggestion.

As for your first suggestion: with a filter I think I'll be moving away from basic authentication which I really don't want to do.

I was hoping there was some hook through which DWR could allow me to construct the request object for it (I'd be using the jsx3.net.Request() class from the GI framework). Something elegant, instead of hacking engine.js. But if there is no other way, I'd like to continue to use my hack, if you're ok with it.

Regards

Johan

No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.20/1453 - Release Date: 2008/05/18 09:31 AM