Creating/managing sessions for different users using DWR

[shravanjc]

Hello DWR users,

I am a newbie to both web development as well as DWR, so may be this question is very basic. I tried to do a lot of reading (in vain) before posting this question.
Version: 3.0 RC2. Eclipse IDE and tomcat server.

I am using DWR on cross-domain environment, all the remote calls are working fine. When the user logs in, I want to save the session variables: userID and service version at user logon. What I currently see is a new script session ID generated per DWR remote call. But the session variables set after user logs on are lost, as new session is created per DWR request.

What should I do to see those session variables set during the remote DWR login() request by all subsequent requests till the user logs out? Thanks for any suggestions.

Regards,
Shaun

"What I currently see is a new script session ID generated per DWR remote call."

That is the correct behavior.  A script session is a DWR entity and not the same as an HttpSession.

"But the session variables set after user logs on are lost, as new session is created per DWR request."

Where/how are you saving the variables?  Are you talking about an HttpSession or DWR's ScriptSession?



On 01/22/2012 03:14 PM, Shravan Shetty wrote:

> Hello DWR users,
>
> I am a newbie to both web development as well as DWR, so may be this question is very basic. I tried to do a lot of reading (in vain) before posting this question.
> Version: 3.0 RC2. Eclipse IDE and tomcat server.
>
> I am using DWR on cross-domain environment, all the remote calls are working fine. When the user logs in, I want to save the session variables: userID and service version at user logon. What I currently see is a new script session ID generated per DWR remote call. But the session variables set after user logs on are lost, as new session is created per DWR request.
>
> What should I do to see those session variables set during the remote DWR login() request by all subsequent requests till the user logs out? Thanks for any suggestions.
>
> Regards,
> Shaun

Also, DWR does not manage HttpSessions, your container does.  Because you are going cross-domain (session tracking cookie is not working) Tomcat has no way to associate the request with an HttpSession so it creates a new one.  I have no idea how or what you are doing are if DWR is even involved but ... in order for this to work you need to make sure you pass the jsessionid in the request.  This post may help:

http://dwr.2114559.n2.nabble.com/A-HttpSession-getting-created-for-each-DWR-Javascript-include-td5886531.html#a5887035

[Mike Wilson]

Actually it shouldn't be required to add any session info to
the url when doing cross-domain, as the browser manages the
JSESSIONID cookie for the foreign DWR domain independently
from your page on its domain. Depending on your application
you may end up with two different HttpSessions and
JSESSIONIDs, one for the DWR API and one for the using app,
on their respective servers, though.

Use FireBug or similar to inspect the JSESSIONID cookie
values sent in each request to verify that this is working
as it should. If not, check if you have set up too
restrictive cookie settings.

Best regards
Mike Wilson

david wrote:

> Also, DWR does not manage HttpSessions, your container does.  
> Because you are
> going cross-domain (session tracking cookie is not working)
> Tomcat has no
> way to associate the request with an HttpSession so it
> creates a new one.  I
> have no idea how or what you are doing are if DWR is even
> involved but ...
> in order for this to work you need to make sure you pass the
> jsessionid in
> the request.  This post may help:
>
> http://dwr.2114559.n2.nabble.com/A-HttpSession-getting-created
> -for-each-DWR-Javascript-include-td5886531.html#a5887035

Thanks Mike.

On 01/23/2012 01:39 AM, Mike Wilson wrote:

> Actually it shouldn't be required to add any session info to
> the url when doing cross-domain, as the browser manages the
> JSESSIONID cookie for the foreign DWR domain independently
> from your page on its domain. Depending on your application
> you may end up with two different HttpSessions and
> JSESSIONIDs, one for the DWR API and one for the using app,
> on their respective servers, though.
>
> Use FireBug or similar to inspect the JSESSIONID cookie
> values sent in each request to verify that this is working
> as it should. If not, check if you have set up too
> restrictive cookie settings.
>
> Best regards
> Mike Wilson
>
> david wrote:
>> Also, DWR does not manage HttpSessions, your container does.
>> Because you are
>> going cross-domain (session tracking cookie is not working)
>> Tomcat has no
>> way to associate the request with an HttpSession so it
>> creates a new one.  I
>> have no idea how or what you are doing are if DWR is even
>> involved but ...
>> in order for this to work you need to make sure you pass the
>> jsessionid in
>> the request.  This post may help:
>>
>> http://dwr.2114559.n2.nabble.com/A-HttpSession-getting-created
>> -for-each-DWR-Javascript-include-td5886531.html#a5887035
>

[shravanjc]

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

On 23 January 2012 09:39, Mike Wilson <[hidden email]> wrote:

Actually it shouldn't be required to add any session info to
the url when doing cross-domain, as the browser manages the
JSESSIONID cookie for the foreign DWR domain independently
from your page on its domain. Depending on your application
you may end up with two different HttpSessions and
JSESSIONIDs, one for the DWR API and one for the using app,
on their respective servers, though.

Use FireBug or similar to inspect the JSESSIONID cookie
values sent in each request to verify that this is working
as it should. If not, check if you have set up too
restrictive cookie settings.

Best regards
Mike Wilson

david wrote:
> Also, DWR does not manage HttpSessions, your container does.
> Because you are
> going cross-domain (session tracking cookie is not working)
> Tomcat has no
> way to associate the request with an HttpSession so it
> creates a new one.  I
> have no idea how or what you are doing are if DWR is even
> involved but ...
> in order for this to work you need to make sure you pass the
> jsessionid in
> the request.  This post may help:
>
> http://dwr.2114559.n2.nabble.com/A-HttpSession-getting-created
> -for-each-DWR-Javascript-include-td5886531.html#a5887035

Is there a reason why you are trying to do this via the ScriptSession?  A ScriptSession is created for user/page.  Please see the section titled "ScriptSession lifecycle" : http://directwebremoting.org/dwr/documentation/reverse-ajax/hints-and-tips.html"

On Mon, Jan 23, 2012 at 11:29 AM, Shravan Shetty <[hidden email]> wrote:

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

On 23 January 2012 09:39, Mike Wilson <[hidden email]> wrote:

Actually it shouldn't be required to add any session info to
the url when doing cross-domain, as the browser manages the
JSESSIONID cookie for the foreign DWR domain independently
from your page on its domain. Depending on your application
you may end up with two different HttpSessions and
JSESSIONIDs, one for the DWR API and one for the using app,
on their respective servers, though.

Use FireBug or similar to inspect the JSESSIONID cookie
values sent in each request to verify that this is working
as it should. If not, check if you have set up too
restrictive cookie settings.

Best regards
Mike Wilson

david wrote:
> Also, DWR does not manage HttpSessions, your container does.
> Because you are
> going cross-domain (session tracking cookie is not working)
> Tomcat has no
> way to associate the request with an HttpSession so it
> creates a new one.  I
> have no idea how or what you are doing are if DWR is even
> involved but ...
> in order for this to work you need to make sure you pass the
> jsessionid in
> the request.  This post may help:
>
> http://dwr.2114559.n2.nabble.com/A-HttpSession-getting-created
> -for-each-DWR-Javascript-include-td5886531.html#a5887035

[Mike Wilson]

The expected behaviour is that all calls from the same page ("document instance") will use the same ScriptSession on the server. So, if you load a page in the browser and it makes three DWR calls they should all see the same ScriptSession, but if you then refresh or navigate to a new page, you will be connected to a new ScriptSession with no association to the old one.

Is this what you are seeing?

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

[shravanjc]

Yes, I am seeing this and also understand that it is as expected. But what would be an optimal solution for my problem? HttpSessions? Can you give me an outline of how I can get this to work?

Thank you for being patient with my amateur questions :)

On Jan 23, 2012, at 11:44 PM, Mike Wilson wrote:

The expected behaviour is that all calls from the same page ("document instance") will use the same ScriptSession on the server. So, if you load a page in the browser and it makes three DWR calls they should all see the same ScriptSession, but if you then refresh or navigate to a new page, you will be connected to a new ScriptSession with no association to the old one.

Is this what you are seeing?

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

[Mike Wilson]

Ok, good.

DWR is at mercy of the rules set up by web browsers and HTTP standards so much of what you can do is standard web app stuff and not specifically related to DWR. Anyway, if you provide a more detailed sketch of the different pages, domains and servers that you have (just make up example names if you want) then I might be able to point out some directions.

 

Best regards

Mike

 

Shravan Shetty wrote:

Yes, I am seeing this and also understand that it is as expected. But what would be an optimal solution for my problem? HttpSessions? Can you give me an outline of how I can get this to work?

Thank you for being patient with my amateur questions :)

On Jan 23, 2012, at 11:44 PM, Mike Wilson wrote:

The expected behaviour is that all calls from the same page ("document instance") will use the same ScriptSession on the server. So, if you load a page in the browser and it makes three DWR calls they should all see the same ScriptSession, but if you then refresh or navigate to a new page, you will be connected to a new ScriptSession with no association to the old one.

Is this what you are seeing?

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

[shravanjc]

Hello Mike,

I am developing a web application where the client logs in from a different domain to my (server) domain (both with its own servlet container, hence making it cross domain). At valid log on, I want to manage any user's session at the server. My intention is now is to set few attributes after login so that all subsequent calls from that client via a DWR call can be validated based on these attributes. I do not manage any sessions at the Client domain, because this is something that I will not have control in the future too. I want to control all sessions only at the Server.

Pictorially it is something like: Client1 --->  Server  <--- Client2. Based on the login credentials I want to limit any Client's future request to the Server. 

What I currently have is a new session running (per page) for each DWR request. How do I persist the session attributes?

Thank you.

On 24 January 2012 09:53, Mike Wilson <[hidden email]> wrote:

Ok, good.

DWR is at mercy of the rules set up by web browsers and HTTP standards so much of what you can do is standard web app stuff and not specifically related to DWR. Anyway, if you provide a more detailed sketch of the different pages, domains and servers that you have (just make up example names if you want) then I might be able to point out some directions.

 

Best regards

Mike

 

Shravan Shetty wrote:

Yes, I am seeing this and also understand that it is as expected. But what would be an optimal solution for my problem? HttpSessions? Can you give me an outline of how I can get this to work?

Thank you for being patient with my amateur questions :)

On Jan 23, 2012, at 11:44 PM, Mike Wilson wrote:

The expected behaviour is that all calls from the same page ("document instance") will use the same ScriptSession on the server. So, if you load a page in the browser and it makes three DWR calls they should all see the same ScriptSession, but if you then refresh or navigate to a new page, you will be connected to a new ScriptSession with no association to the old one.

Is this what you are seeing?

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

--
Regards,
Shravan

[Mike Wilson]

Ok, here goes. You want to persist the logged-in user on your DWR API between page loads on the foreign-domain client site.

Standard webapp rules say that to persist a state between page loads, we need to either send it to the server at navigation (GET or POST parameter) so the server can send it back to us in the next page, or to save it as a cookie managed by the browser.

 

There are two main solutions that you can consider, see below. There are many variations that can be made on these two themes, so I recommend that you use them as a basis for further exploring and learning about webapps, and not as the "only" ways possible.

 

PERSIST HTTPSESSION ON YOUR SERVER

 

Outline:

 

client.com/page.html

    Remote.login(user, password)

    Remote.doStuff()

        |

        | (cookie for server.com:JSESSIONID=...)

        |

        V

server.com/dwr/*

    class Remote

        public void login(String user, String password, HttpSession sess)

            if (loginOk) sess.setAttribute("validUserId", ...)

        public void doStuff(HttpSession sess)

            userId = sess.getAttribute("validUserId");

            if (userId != "") do stuff ...

 

Here we set up a session between the client browser and the server, and it will use a cookie to remember which browser is connected to which session. Note that a cross-domain setup like yours will allow any site to participate in this session and you will be subject to CSRF attacks. You can mitigate this to some degree by using the "Referer" header to partition the "session" into different parts for the different client sites.

(Note: the HttpSession parameter is automatically filled in by DWR, see http://directwebremoting.org/dwr/documentation/server/javaapi.html)

 

USE YOUR OWN LOGIN TOKEN PERSISTED BY THE CLIENT

 

Outline:

 

client.com/page.html

    var token

    Remote.login(user, password, function(returnValue){token=returnValue})

    Remote.doStuff(token)

        |

        |

        V

server.com/dwr/*

    class Remote

        public String login(String user, String password)

            return (loginOk ? generateToken(mySession) : "")

        public void doStuff(String token)

            mySession = checkToken(token)

            if (mySession != null) do stuff ...

 

Here you basically set up your own session mechanism on your server, and generate hard-to-guess identifiers (tokens) for them. The token is returned to the client on successful login, and you then require the client to pass this token in every call to your DWR-remoted methods.

It will then be up to the client site to persist this token between page loads, and this could either be done through a cookie on the client site or through parameters (GET or POST) passed between client pages on navigation.

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello Mike,

I am developing a web application where the client logs in from a different domain to my (server) domain (both with its own servlet container, hence making it cross domain). At valid log on, I want to manage any user's session at the server. My intention is now is to set few attributes after login so that all subsequent calls from that client via a DWR call can be validated based on these attributes. I do not manage any sessions at the Client domain, because this is something that I will not have control in the future too. I want to control all sessions only at the Server.

Pictorially it is something like: Client1 --->  Server  <--- Client2. Based on the login credentials I want to limit any Client's future request to the Server. 

What I currently have is a new session running (per page) for each DWR request. How do I persist the session attributes?

Thank you.

On 24 January 2012 09:53, Mike Wilson <[hidden email]> wrote:

Ok, good.

DWR is at mercy of the rules set up by web browsers and HTTP standards so much of what you can do is standard web app stuff and not specifically related to DWR. Anyway, if you provide a more detailed sketch of the different pages, domains and servers that you have (just make up example names if you want) then I might be able to point out some directions.

 

Best regards

Mike

 

Shravan Shetty wrote:

Yes, I am seeing this and also understand that it is as expected. But what would be an optimal solution for my problem? HttpSessions? Can you give me an outline of how I can get this to work?

Thank you for being patient with my amateur questions :)

On Jan 23, 2012, at 11:44 PM, Mike Wilson wrote:

The expected behaviour is that all calls from the same page ("document instance") will use the same ScriptSession on the server. So, if you load a page in the browser and it makes three DWR calls they should all see the same ScriptSession, but if you then refresh or navigate to a new page, you will be connected to a new ScriptSession with no association to the old one.

Is this what you are seeing?

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

--
Regards,
Shravan

[shravanjc]

Thank you Mike. Great explanation. I will try it out and let you know how it goes. If I understood correct, the second option you suggested about client side token persistence can (to a large extent) mitigate CSRF attacks? 

Thank you again. I will update you on my progress in a day's time. 

On 24 January 2012 12:45, Mike Wilson <[hidden email]> wrote:

Ok, here goes. You want to persist the logged-in user on your DWR API between page loads on the foreign-domain client site.

Standard webapp rules say that to persist a state between page loads, we need to either send it to the server at navigation (GET or POST parameter) so the server can send it back to us in the next page, or to save it as a cookie managed by the browser.

 

There are two main solutions that you can consider, see below. There are many variations that can be made on these two themes, so I recommend that you use them as a basis for further exploring and learning about webapps, and not as the "only" ways possible.

 

PERSIST HTTPSESSION ON YOUR SERVER

 

Outline:

 

client.com/page.html

    Remote.login(user, password)

    Remote.doStuff()

        |

        | (cookie for server.com:JSESSIONID=...)

        |

        V

server.com/dwr/*

    class Remote

        public void login(String user, String password, HttpSession sess)

            if (loginOk) sess.setAttribute("validUserId", ...)

        public void doStuff(HttpSession sess)

            userId = sess.getAttribute("validUserId");

            if (userId != "") do stuff ...

 

Here we set up a session between the client browser and the server, and it will use a cookie to remember which browser is connected to which session. Note that a cross-domain setup like yours will allow any site to participate in this session and you will be subject to CSRF attacks. You can mitigate this to some degree by using the "Referer" header to partition the "session" into different parts for the different client sites.

(Note: the HttpSession parameter is automatically filled in by DWR, see http://directwebremoting.org/dwr/documentation/server/javaapi.html)

 

USE YOUR OWN LOGIN TOKEN PERSISTED BY THE CLIENT

 

Outline:

 

client.com/page.html

    var token

    Remote.login(user, password, function(returnValue){token=returnValue})

    Remote.doStuff(token)

        |

        |

        V

server.com/dwr/*

    class Remote

        public String login(String user, String password)

            return (loginOk ? generateToken(mySession) : "")

        public void doStuff(String token)

            mySession = checkToken(token)

            if (mySession != null) do stuff ...

 

Here you basically set up your own session mechanism on your server, and generate hard-to-guess identifiers (tokens) for them. The token is returned to the client on successful login, and you then require the client to pass this token in every call to your DWR-remoted methods.

It will then be up to the client site to persist this token between page loads, and this could either be done through a cookie on the client site or through parameters (GET or POST) passed between client pages on navigation.

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello Mike,

I am developing a web application where the client logs in from a different domain to my (server) domain (both with its own servlet container, hence making it cross domain). At valid log on, I want to manage any user's session at the server. My intention is now is to set few attributes after login so that all subsequent calls from that client via a DWR call can be validated based on these attributes. I do not manage any sessions at the Client domain, because this is something that I will not have control in the future too. I want to control all sessions only at the Server.

Pictorially it is something like: Client1 --->  Server  <--- Client2. Based on the login credentials I want to limit any Client's future request to the Server. 

What I currently have is a new session running (per page) for each DWR request. How do I persist the session attributes?

Thank you.

On 24 January 2012 09:53, Mike Wilson <[hidden email]> wrote:

Ok, good.

DWR is at mercy of the rules set up by web browsers and HTTP standards so much of what you can do is standard web app stuff and not specifically related to DWR. Anyway, if you provide a more detailed sketch of the different pages, domains and servers that you have (just make up example names if you want) then I might be able to point out some directions.

 

Best regards

Mike

 

Shravan Shetty wrote:

Yes, I am seeing this and also understand that it is as expected. But what would be an optimal solution for my problem? HttpSessions? Can you give me an outline of how I can get this to work?

Thank you for being patient with my amateur questions :)

On Jan 23, 2012, at 11:44 PM, Mike Wilson wrote:

The expected behaviour is that all calls from the same page ("document instance") will use the same ScriptSession on the server. So, if you load a page in the browser and it makes three DWR calls they should all see the same ScriptSession, but if you then refresh or navigate to a new page, you will be connected to a new ScriptSession with no association to the old one.

Is this what you are seeing?

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

--
Regards,
Shravan

--
Regards,
Shravan

[Mike Wilson]

Right, the second option doesn't have the inherent CSRF weakness that the first has. But if you put it another way, we are really moving the responsibility for session persistence away from your server and to the client instead with the second option. If you don't have control over the client's code it is possible they introduce bugs that in turn open up for CSRF vulnerabilities on their side. Part of the choice depends on how much responsibility you want to hand over to clients.

 

It will be interesting to hear what you find, and it's great if you share your experiences for the benefit of all readers of this list.

 

Best regards

Mike

 

Shravan Shetty wrote:

Thank you Mike. Great explanation. I will try it out and let you know how it goes. If I understood correct, the second option you suggested about client side token persistence can (to a large extent) mitigate CSRF attacks? 

Thank you again. I will update you on my progress in a day's time. 

On 24 January 2012 12:45, Mike Wilson <[hidden email]> wrote:

Ok, here goes. You want to persist the logged-in user on your DWR API between page loads on the foreign-domain client site.

Standard webapp rules say that to persist a state between page loads, we need to either send it to the server at navigation (GET or POST parameter) so the server can send it back to us in the next page, or to save it as a cookie managed by the browser.

 

There are two main solutions that you can consider, see below. There are many variations that can be made on these two themes, so I recommend that you use them as a basis for further exploring and learning about webapps, and not as the "only" ways possible.

 

PERSIST HTTPSESSION ON YOUR SERVER

 

Outline:

 

client.com/page.html

    Remote.login(user, password)

    Remote.doStuff()

        |

        | (cookie for server.com:JSESSIONID=...)

        |

        V

server.com/dwr/*

    class Remote

        public void login(String user, String password, HttpSession sess)

            if (loginOk) sess.setAttribute("validUserId", ...)

        public void doStuff(HttpSession sess)

            userId = sess.getAttribute("validUserId");

            if (userId != "") do stuff ...

 

Here we set up a session between the client browser and the server, and it will use a cookie to remember which browser is connected to which session. Note that a cross-domain setup like yours will allow any site to participate in this session and you will be subject to CSRF attacks. You can mitigate this to some degree by using the "Referer" header to partition the "session" into different parts for the different client sites.

(Note: the HttpSession parameter is automatically filled in by DWR, see http://directwebremoting.org/dwr/documentation/server/javaapi.html)

 

USE YOUR OWN LOGIN TOKEN PERSISTED BY THE CLIENT

 

Outline:

 

client.com/page.html

    var token

    Remote.login(user, password, function(returnValue){token=returnValue})

    Remote.doStuff(token)

        |

        |

        V

server.com/dwr/*

    class Remote

        public String login(String user, String password)

            return (loginOk ? generateToken(mySession) : "")

        public void doStuff(String token)

            mySession = checkToken(token)

            if (mySession != null) do stuff ...

 

Here you basically set up your own session mechanism on your server, and generate hard-to-guess identifiers (tokens) for them. The token is returned to the client on successful login, and you then require the client to pass this token in every call to your DWR-remoted methods.

It will then be up to the client site to persist this token between page loads, and this could either be done through a cookie on the client site or through parameters (GET or POST) passed between client pages on navigation.

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello Mike,

I am developing a web application where the client logs in from a different domain to my (server) domain (both with its own servlet container, hence making it cross domain). At valid log on, I want to manage any user's session at the server. My intention is now is to set few attributes after login so that all subsequent calls from that client via a DWR call can be validated based on these attributes. I do not manage any sessions at the Client domain, because this is something that I will not have control in the future too. I want to control all sessions only at the Server.

Pictorially it is something like: Client1 --->  Server  <--- Client2. Based on the login credentials I want to limit any Client's future request to the Server. 

What I currently have is a new session running (per page) for each DWR request. How do I persist the session attributes?

Thank you.

On 24 January 2012 09:53, Mike Wilson <[hidden email]> wrote:

Ok, good.

DWR is at mercy of the rules set up by web browsers and HTTP standards so much of what you can do is standard web app stuff and not specifically related to DWR. Anyway, if you provide a more detailed sketch of the different pages, domains and servers that you have (just make up example names if you want) then I might be able to point out some directions.

 

Best regards

Mike

 

Shravan Shetty wrote:

Yes, I am seeing this and also understand that it is as expected. But what would be an optimal solution for my problem? HttpSessions? Can you give me an outline of how I can get this to work?

Thank you for being patient with my amateur questions :)

On Jan 23, 2012, at 11:44 PM, Mike Wilson wrote:

The expected behaviour is that all calls from the same page ("document instance") will use the same ScriptSession on the server. So, if you load a page in the browser and it makes three DWR calls they should all see the same ScriptSession, but if you then refresh or navigate to a new page, you will be connected to a new ScriptSession with no association to the old one.

Is this what you are seeing?

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

--
Regards,
Shravan

--
Regards,
Shravan

[shravanjc]

Hi Mike,

Thank you for your valuable suggestions. 

I have adopted a method in the lines of the second option (or a combination of both). I do agree that generating a token will give complete control/trust on the clients part, hence I generate the token after successful login and save it in the session too. This makes sure that the client making any subsequent DWR call using the token is validated at the server side (using the session attributes) as well. 

lient.com/page.html

    var token

    Remote.login(user, password, function(returnValue){token=returnValue})

    Remote.doStuff(token)

        |

        |

        V

server.com/dwr/*

    class Remote

        public String login(String user, String password)

            return (loginOk ? generateToken(mySession) : "")

        

public void doStuff(String token, HttpSession sess)

            sess.getAttribute("token") == token ? do stuff.. : do nothing and return... ;

Can you comment on the security risk (if any) running on this mechanism, when I use it in a cross-domain DWR environment?

 

On Jan 24, 2012, at 2:42 PM, Mike Wilson wrote:

Right, the second option doesn't have the inherent CSRF weakness that the first has. But if you put it another way, we are really moving the responsibility for session persistence away from your server and to the client instead with the second option. If you don't have control over the client's code it is possible they introduce bugs that in turn open up for CSRF vulnerabilities on their side. Part of the choice depends on how much responsibility you want to hand over to clients.

 

It will be interesting to hear what you find, and it's great if you share your experiences for the benefit of all readers of this list.

 

Best regards

Mike

 

Shravan Shetty wrote:

Thank you Mike. Great explanation. I will try it out and let you know how it goes. If I understood correct, the second option you suggested about client side token persistence can (to a large extent) mitigate CSRF attacks? 

Thank you again. I will update you on my progress in a day's time. 

On 24 January 2012 12:45, Mike Wilson <[hidden email]> wrote:

Ok, here goes. You want to persist the logged-in user on your DWR API between page loads on the foreign-domain client site.

Standard webapp rules say that to persist a state between page loads, we need to either send it to the server at navigation (GET or POST parameter) so the server can send it back to us in the next page, or to save it as a cookie managed by the browser.

 

There are two main solutions that you can consider, see below. There are many variations that can be made on these two themes, so I recommend that you use them as a basis for further exploring and learning about webapps, and not as the "only" ways possible.

 

PERSIST HTTPSESSION ON YOUR SERVER

 

Outline:

 

client.com/page.html

    Remote.login(user, password)

    Remote.doStuff()

        |

        | (cookie for server.com:JSESSIONID=...)

        |

        V

server.com/dwr/*

    class Remote

        public void login(String user, String password, HttpSession sess)

            if (loginOk) sess.setAttribute("validUserId", ...)

        public void doStuff(HttpSession sess)

            userId = sess.getAttribute("validUserId");

            if (userId != "") do stuff ...

 

Here we set up a session between the client browser and the server, and it will use a cookie to remember which browser is connected to which session. Note that a cross-domain setup like yours will allow any site to participate in this session and you will be subject to CSRF attacks. You can mitigate this to some degree by using the "Referer" header to partition the "session" into different parts for the different client sites.

(Note: the HttpSession parameter is automatically filled in by DWR, see http://directwebremoting.org/dwr/documentation/server/javaapi.html)

 

USE YOUR OWN LOGIN TOKEN PERSISTED BY THE CLIENT

 

Outline:

 

client.com/page.html

    var token

    Remote.login(user, password, function(returnValue){token=returnValue})

    Remote.doStuff(token)

        |

        |

        V

server.com/dwr/*

    class Remote

        public String login(String user, String password)

            return (loginOk ? generateToken(mySession) : "")

        public void doStuff(String token)

            mySession = checkToken(token)

            if (mySession != null) do stuff ...

 

Here you basically set up your own session mechanism on your server, and generate hard-to-guess identifiers (tokens) for them. The token is returned to the client on successful login, and you then require the client to pass this token in every call to your DWR-remoted methods.

It will then be up to the client site to persist this token between page loads, and this could either be done through a cookie on the client site or through parameters (GET or POST) passed between client pages on navigation.

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello Mike,

I am developing a web application where the client logs in from a different domain to my (server) domain (both with its own servlet container, hence making it cross domain). At valid log on, I want to manage any user's session at the server. My intention is now is to set few attributes after login so that all subsequent calls from that client via a DWR call can be validated based on these attributes. I do not manage any sessions at the Client domain, because this is something that I will not have control in the future too. I want to control all sessions only at the Server.

Pictorially it is something like: Client1 --->  Server  <--- Client2. Based on the login credentials I want to limit any Client's future request to the Server. 

What I currently have is a new session running (per page) for each DWR request. How do I persist the session attributes?

Thank you.

On 24 January 2012 09:53, Mike Wilson <[hidden email]> wrote:

Ok, good.

DWR is at mercy of the rules set up by web browsers and HTTP standards so much of what you can do is standard web app stuff and not specifically related to DWR. Anyway, if you provide a more detailed sketch of the different pages, domains and servers that you have (just make up example names if you want) then I might be able to point out some directions.

 

Best regards

Mike

 

Shravan Shetty wrote:

Yes, I am seeing this and also understand that it is as expected. But what would be an optimal solution for my problem? HttpSessions? Can you give me an outline of how I can get this to work?

Thank you for being patient with my amateur questions :)

On Jan 23, 2012, at 11:44 PM, Mike Wilson wrote:

The expected behaviour is that all calls from the same page ("document instance") will use the same ScriptSession on the server. So, if you load a page in the browser and it makes three DWR calls they should all see the same ScriptSession, but if you then refresh or navigate to a new page, you will be connected to a new ScriptSession with no association to the old one.

Is this what you are seeing?

 

Best regards

Mike

 

Shravan Shetty wrote:

Hello David and Mike,

 I was talking about DWR's scriptsession. I also went through the post where MK had a similar problem. I am not able to solve the issue using URL rewriting:

<script type='text/javascript' src='<%= response.encodeURL("/dwr/<DWR JS Name>.js")%>'></script>

The attributes set returns a value null on the subsequent DWR calls.

My objective is to save the 2 parameters corresponding to a user after a login is validated. I am currently using ScriptSession.setAttribute(<attribute>,<attribute value>). The client is logging in from a different domain and the server exists in a different one (cross-domain). How can I use these attributes set for every subsequent DWR call by the client. 

Thank you.

--

--

[Mike Wilson]

Just a quick note as I am preparing for travelling for a week.
Your choice sounds fine, two comments:

1) Instead of blocking any other token than the one logged into your session, you may want to allow multiple tokens logged in to one session. This is important if the same browser instance may be navigated to multiple client sites - the browser will use the same HttpSession on your server for all the client sites so this will allow you to avoid issuing confusing warnings to users.

2) About security: when using cross-domain and supplying your own token as a parameter, then the token wil show up as url parameters on generate script tags in the client page dom. Any party that has access to the client page dom can harvest this token, but normally it is only the client site that has this so shouldn't be a problem.

Best regards
Mike