RequestFactory Security: prevent the user from retrieving other users content

[Alexander Orlov]

A RF call retrieves bookings for the current user. How can I prevent the current user from opening Web Inspector, changing the userId of the RF call and retrive bookings from another user? A classic problem isn't it? :) Are there RF/GWT-specific solutions and/or best practices?

[Jens]

You should save the currently logged in user into a server side session (app server session or a general user session stored in your database) and use this user to fetch data from your database. Then you dont even have to send the userId to the server during the request. The server knows who is logged in.

In general you cant trust the client and its requests, so you have to validate them. So its up to the server to manage logged in users, (multi-)tenant information, access controls, etc. Basically everything that is security related.

-- J.

[Alexander Orlov]

That's what I had in mind too but I wanted to know if there is also a GWT-specific out-of-the-box solution.

Thx!

[Thomas Broyer]

If you only look at the parameters sent with the request, you're basically login in everyone as an administrator.

The remedy is easy: authenticate your requests, and use the authenticated user to filter data on the server-side.

Either let the browser do it (using cookies or HTTP auth) or do it yourself (create a "token" for the client and associate it with a user on the server-side, the client sends the token with each request, which authenticates it on the server-side; this is basically mimicking a cookie, just at another level).

Only way to authenticate as another user is to "steal" his "token" (so make sure you make them expire).

This is only the *first* step though; security is hard, and the above is clearly not enough to declare your application "secure".

[Alexander Orlov]

I'll go with the token approach because I assume, cookies require HTTP and if you want to use the same app over Web Sockets, the cookies approach would not work?

[Thomas Broyer]

According to http://www.rfc-editor.org/authors/rfc6455.txt and http://dev.w3.org/html5/websockets/ I'd say the cookies should be sent over WebSocket (for obvious reasons of authentication precisely; such as GMail authenticating automatically over WebSocket as it authenticates over HTTP when loading the web page –GMail isn't using WebSocket but I believe it's in the works at Google–), now in practice I guess it highly depends on both the browsers and the server implementations.