Re: gwt mvp sessions

[David Chandler]

You could use the Command pattern as with GWT-RPC using a ValueProxy as the
command object, but I'm not sure what you'd gain by it as you'd lose all the
RF functionality related to entities. As it currently stands, you would need
to modify the RF transport protocol, perhaps with a ServiceLayerDecorator.
Are you convinced that the token needs to be part of the payload vs. request
header? It's much easier to modify the header by extending
DefaultRequestTransport as Thomas has pointed out elsewhere.

/dmc

On Fri, Feb 25, 2011 at 7:34 PM, veenatic  wrote:

> Thanks Jeff,
> With RPC, this way is understood. Similarily, I have some idea with
> RequestFactory also like
>
> requestFactory.serviceRequest().getAllEntities(clientSid);
>
> and on the server side, in getAllEntities(String clientSid) i can verify
> the same way you did.
>
> But this way is forcing me to put an extra parameter in all my business
> methods. I am sure there are other ways. Any Ideas?
> Obviously, the above approach is not that ugly.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>



-- 
David Chandler
Developer Programs Engineer, Google Web Toolkit
w: http://code.google.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[veenatic]

Thanks Jeff,
With RPC, this way is understood. Similarily, I have some idea with 
RequestFactory also like

requestFactory.serviceRequest().getAllEntities(clientSid);

and on the server side, in getAllEntities(String clientSid) i can verify the 
same way you did.

But this way is forcing me to put an extra parameter in all my business 
methods. I am sure there are other ways. Any Ideas?
Obviously, the above approach is not that ugly.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Jeff Schwartz]

btw my bad I meant to say overridden OnFailure method... sorry about that

On Fri, Feb 25, 2011 at 7:15 PM, Jeff Schwartz wrote:

> With RPC I define all my RPC synchronous methods taking  a string parameter
> whose value will be assigned from the cooke storing the sid. On the server,
> the handler will compare this string value to the value returned from the
> Session.getId() method. If they aren't the same I throw a custom exception
> which is caught on the client in the overloaded OnFailure method of the RPC
> call.
>
> Here's the typical code for a server-side handler:
>
> @Override
> public SingleRPCPayload someMethod(String clientSid, ...)
> throws MyCapabilityDisabledException {
> HttpSession session = getThreadLocalRequest().getSession(true);
> String sid = session.getId();
> if (clientSid.equals(sid)) {
> .
> .
> .
> return payload;
> } else {
> throw new MyInvalidSessionException();
>
> }
> }
>
>
> On Fri, Feb 25, 2011 at 7:01 PM, veenatic wrote:
>
>> I think the discussion has become very interesting and I understood a lot
>> about attacks and attackers but I still ponder over the question that if we
>> have to put the auth token on the payload of the RequestFactory, how to do
>> that?
>> And after this how to read the token from the payload to verify it?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To post to this group, send email to google-web-toolkit@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-web-toolkit+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>
>
>
> --
> *Jeff Schwartz*
> http://jefftschwartz.appspot.com/
> http://www.linkedin.com/in/jefftschwartz
> follow me on twitter: @jefftschwartz
>
>


-- 
*Jeff Schwartz*
http://jefftschwartz.appspot.com/
http://www.linkedin.com/in/jefftschwartz
follow me on twitter: @jefftschwartz

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Jeff Schwartz]

With RPC I define all my RPC synchronous methods taking  a string parameter
whose value will be assigned from the cooke storing the sid. On the server,
the handler will compare this string value to the value returned from the
Session.getId() method. If they aren't the same I throw a custom exception
which is caught on the client in the overloaded OnFailure method of the RPC
call.

Here's the typical code for a server-side handler:

@Override
public SingleRPCPayload someMethod(String clientSid, ...)
throws MyCapabilityDisabledException {
HttpSession session = getThreadLocalRequest().getSession(true);
String sid = session.getId();
if (clientSid.equals(sid)) {
.
.
.
return payload;
} else {
throw new MyInvalidSessionException();
}
}


On Fri, Feb 25, 2011 at 7:01 PM, veenatic  wrote:

> I think the discussion has become very interesting and I understood a lot
> about attacks and attackers but I still ponder over the question that if we
> have to put the auth token on the payload of the RequestFactory, how to do
> that?
> And after this how to read the token from the payload to verify it?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>



-- 
*Jeff Schwartz*
http://jefftschwartz.appspot.com/
http://www.linkedin.com/in/jefftschwartz
follow me on twitter: @jefftschwartz

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[veenatic]

I think the discussion has become very interesting and I understood a lot 
about attacks and attackers but I still ponder over the question that if we 
have to put the auth token on the payload of the RequestFactory, how to do 
that?
And after this how to read the token from the payload to verify it?

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Jeff Schwartz]

I am not dismissing your scenarios outright as I never said that the method
was foolproof and I also said that only SSL will give you something close to
that.

Also lets not forget that if the user manages to be lured to an attackers
site via a link in an email for instance and then doesn't notice that they
are then redirected to another site then they have bigger problems than
having their session hijacked lol.

However, there are ways to mitigate even the cross-subdomain attack that you
use as an example...


On Fri, Feb 25, 2011 at 2:20 PM, Thomas Broyer  wrote:

> This is where you fail to understand me: you make the assumption that the
> "authentication process" takes place, while I'm talking about bypassing it
> with a session-fixation attack.


I understood perfectly, Thomas. To reiterate, the attacker will have had to
authenticate in order to acquire a valid sid which he then stores and waits
in prey for the user to respond to his email with a link to his site. When
the user takes the bait and visits the attacker's site the attacker
redirects the user to another site including the sid as a query parameter.

One possible scenario (easily mitigated through the use of your own domain
> name):
> *Attacker*: authenticates to victim.example.com, grabs the cookies in use,
> store them at attacker.example.com (note: same domain, different
> subdomains, much like appspot.com hosted apps)
>

At this point the request hits the server and the session id is set the
query parameter, the same one as the attackers. This attack can be mitigated
by changing the session ID when users logs in and to additionally require
the user to authenticate on every important request. A pain in the rear for
the user of course but it will largely work. The fact that it does work is
due to the reluctance to require users to log in for every important
request.

Sure enough, even if you used SSL it would require that every request uses
it in order to be close to 100% protected from this kind of attack. The only
sites I know that do that are some banks. I believe Citibank does for
instance. Interestingly I believe Facebook announced that they will be
rolling this out to all their members. It will be interesting to see how it
affects the performance of their site.

Perhaps requiring every one to use SSL for every request is the right
approach. Maybe we should all be going in that direction but service
providers might be loathe to provide this service as it adds additional
demands on their servers that they might not be able to handle and the users
might complain because of the increased latency.

Perhaps using HttpOnly headers would also mitigate this kind of attack. I
don't think App Engine supports it though but I wish it did.

The bottom line is this, it really comes down to a multi-faceted approach to
security. One big wall isn't going to cut it and the more obstacles put up
the less chances are that some malcontent will be successful.

-- 
*Jeff Schwartz*
http://jefftschwartz.appspot.com/
http://www.linkedin.com/in/jefftschwartz
follow me on twitter: @jefftschwartz

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

On Friday, February 25, 2011 6:39:40 PM UTC+1, Jeff wrote:
>
>
>
> On Fri, Feb 25, 2011 at 12:30 PM, Thomas Broyer  wrote:
>
>> You contradict yourself (compare the HttpSession's ID with the auth token 
>> –the HttpSession is maintained by a cookie, whose value generally is the 
>> session's ID– vs. do not send the auth token in a cookie), but that's not 
>> the problem.
>
>
> Actually I am not contradicting myself, Thomas. You just failed to 
> understand!
>

And the other way around! ;-)

The problem is: how are you initializing the auth token on the client side, 
>> and how you associate it with the user on the server-side? The client and 
>> server have to share some knowledge at some point, and if you have use "form 
>> based" authentication on another web page (i.e. your app's host page is 
>> protected and cannot be accessed without being authenticated), then the only 
>> way (not accurate, but that's how 99.999% of auth is done, because the 
>> alternative comes with a UX penalty) to "transfer" the authentication from 
>> the login page to the app's page is to use either a cookie or pass a unique 
>> token in the URL, both of which can be hijacked.
>>
>
> If the user is authenticated the authentication process should then send 
> down the HttpSession id as part of the payload back to the client. The 
> client then stores the session id it receives as part of the payload from 
> the server as a local cookie.
>

This is where you fail to understand me: you make the assumption that the 
"authentication process" takes place, while I'm talking about bypassing it 
with a session-fixation attack.

One possible scenario (easily mitigated through the use of your own domain 
name):
*Attacker*: authenticates to victim.example.com, grabs the cookies in use, 
store them at attacker.example.com (note: same domain, different subdomains, 
much like appspot.com hosted apps)
*Victim*: goes to attacker.example.com, which sets the cookies with 
Domain=.example.com and redirects it to victim.example.com
The victim's browser sends the cookies to victim.example.com (because of 
Domain=.example.com, they apply, even though they've been set by 
attacker.example.com)
The victim is then authenticated to victim.example.com with the *same 
session* as the attacker.
The session id is sent down to the client as part of the payload, but it's 
too late.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Jeff Schwartz]

On Fri, Feb 25, 2011 at 12:30 PM, Thomas Broyer  wrote:

> You contradict yourself (compare the HttpSession's ID with the auth token
> –the HttpSession is maintained by a cookie, whose value generally is the
> session's ID– vs. do not send the auth token in a cookie), but that's not
> the problem.


Actually I am not contradicting myself, Thomas. You just failed to
understand!

>
> The problem is: how are you initializing the auth token on the client side,
> and how you associate it with the user on the server-side? The client and
> server have to share some knowledge at some point, and if you have use "form
> based" authentication on another web page (i.e. your app's host page is
> protected and cannot be accessed without being authenticated), then the only
> way (not accurate, but that's how 99.999% of auth is done, because the
> alternative comes with a UX penalty) to "transfer" the authentication from
> the login page to the app's page is to use either a cookie or pass a unique
> token in the URL, both of which can be hijacked.
>

If the user is authenticated the authentication process should then send
down the HttpSession id as part of the payload back to the client. The
client then stores the session id it receives as part of the payload from
the server as a local cookie. Encryption can even be applied on the server
for extra security as it's value has no real meaning to the client, only
that it needs to include it in each payload to the server.

>  --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>



-- 
*Jeff Schwartz*
http://jefftschwartz.appspot.com/
http://www.linkedin.com/in/jefftschwartz
follow me on twitter: @jefftschwartz

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

You contradict yourself (compare the HttpSession's ID with the auth token 
–the HttpSession is maintained by a cookie, whose value generally is the 
session's ID– vs. do not send the auth token in a cookie), but that's not 
the problem.

The problem is: how are you initializing the auth token on the client side, 
and how you associate it with the user on the server-side? The client and 
server have to share some knowledge at some point, and if you have use "form 
based" authentication on another web page (i.e. your app's host page is 
protected and cannot be accessed without being authenticated), then the only 
way (not accurate, but that's how 99.999% of auth is done, because the 
alternative comes with a UX penalty) to "transfer" the authentication from 
the login page to the app's page is to use either a cookie or pass a unique 
token in the URL, both of which can be hijacked.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Jeff Schwartz]

You are talking about using request cookies so of course the scenario you
describe might be possible. Everyone knows they are vulnerable and hence
their ease of hijacking. The right way to do it is not using request cookies
at all on the server because they cannot be trusted - the auth token must be
delivered to the server as part of the payload and it must never be read
from a request cookie.

On Fri, Feb 25, 2011 at 11:38 AM, Thomas Broyer  wrote:

>
>
> On Friday, February 25, 2011 3:21:18 PM UTC+1, Jeff wrote:
>
>> Hi Thomas,
>>
>>
>> On Fri, Feb 25, 2011 at 8:49 AM, Thomas Broyer  wrote:
>>
>>> Of course! I didn't mean to imply that you shouldn't secure your app, but
>>> honestly if someone succeeds in hijacking your session, then he could
>>> possibly do it before loading the host page, so that your GWT app will run
>>> with the hijacked session, and the "auth token in the request payload" won't
>>> be of any help.
>>
>>
>> First off, the hacker couldn't have access to the local cookie on the
>> user's machine unless the user has been infected with a virus. If the user's
>> computer has been infected with a virus that can some how target local
>> cookies then this user has a lot more to worry about than someone hijacking
>> their session. So let's rule that scenario out.
>>
>
> I can setup an web page at attacker.appspot.com that sets a cookie with
> Domain=.appspot.com, and it'll target every appspot.com app out there. If
> victim.appspot.com uses its own authentication mechanism and its own
> cookies, I can then easily set a cookie to a user's browser visiting
> attacker.appspot.com and redirect it to victim.appspot.com, and he would
> then be automatically authenticated with my own session (session fixation
> attack).
>
>
>> Secondly, if the hacker could somehow manage to hijack your session -
>> meaning they've some how coerced the request to use a different value for
>> the session id) and do it before loading the host page it wouldn't make a
>> difference if every Servlet method that is called does the following:
>> 1) checks each payload for an auth token (a value equal to the sid stored
>> as a cookie on the client) and
>> 2) compares the auth token's value to the HttpSession's session id value.
>> If they aren't the same then throw a custom exception and catch it on the
>> client and authenticate the user (either form-based auth or some other
>> method such as Google Account, OpenId, et. al)
>>
>
> But if the auth token is initialized from the cookie (or somehow attached
> to the authenticated user) and the attacker managed to set the cookie value
> on behalf of the webapp (or at least do a session fixation attack), then
> those two checks won't detect it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>



-- 
*Jeff Schwartz*
http://jefftschwartz.appspot.com/
http://www.linkedin.com/in/jefftschwartz
follow me on twitter: @jefftschwartz

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

On Friday, February 25, 2011 3:21:18 PM UTC+1, Jeff wrote:
>
> Hi Thomas,
>
> On Fri, Feb 25, 2011 at 8:49 AM, Thomas Broyer  wrote:
>
>> Of course! I didn't mean to imply that you shouldn't secure your app, but 
>> honestly if someone succeeds in hijacking your session, then he could 
>> possibly do it before loading the host page, so that your GWT app will run 
>> with the hijacked session, and the "auth token in the request payload" won't 
>> be of any help. 
>
>
> First off, the hacker couldn't have access to the local cookie on the 
> user's machine unless the user has been infected with a virus. If the user's 
> computer has been infected with a virus that can some how target local 
> cookies then this user has a lot more to worry about than someone hijacking 
> their session. So let's rule that scenario out.
>

I can setup an web page at attacker.appspot.com that sets a cookie with 
Domain=.appspot.com, and it'll target every appspot.com app out there. If 
victim.appspot.com uses its own authentication mechanism and its own 
cookies, I can then easily set a cookie to a user's browser visiting 
attacker.appspot.com and redirect it to victim.appspot.com, and he would 
then be automatically authenticated with my own session (session fixation 
attack).
 

> Secondly, if the hacker could somehow manage to hijack your session - 
> meaning they've some how coerced the request to use a different value for 
> the session id) and do it before loading the host page it wouldn't make a 
> difference if every Servlet method that is called does the following:
> 1) checks each payload for an auth token (a value equal to the sid stored 
> as a cookie on the client) and
> 2) compares the auth token's value to the HttpSession's session id value. 
> If they aren't the same then throw a custom exception and catch it on the 
> client and authenticate the user (either form-based auth or some other 
> method such as Google Account, OpenId, et. al)
>

But if the auth token is initialized from the cookie (or somehow attached to 
the authenticated user) and the attacker managed to set the cookie value on 
behalf of the webapp (or at least do a session fixation attack), then those 
two checks won't detect it.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Jeff Schwartz]

On Fri, Feb 25, 2011 at 10:14 AM, veenatic  wrote:

> Does this mean that "auth token" in the request payload is not of much use?
> Also, I want to understand when i have the token set in the requestfactory
> payload, how to retrieve from the payload when a service call is made by
> requestfactory since i will have to validate the token for every service
> request.
>
>
> On Friday, February 25, 2011 3:49:32 PM UTC+2, Thomas Broyer wrote:
>>
>> Of course! I didn't mean to imply that you shouldn't secure your app, but
>> honestly if someone succeeds in hijacking your session, then he could
>> possibly do it before loading the host page, so that your GWT app will run
>> with the hijacked session, and the "auth token in the request payload" won't
>> be of any help.
>
>
To the contrary - it means that every request to the server should include
it and that ever request should validate it against the HttpSession's
session id value and respond accordingly.

>  --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>



-- 
*Jeff Schwartz*
http://jefftschwartz.appspot.com/
http://www.linkedin.com/in/jefftschwartz
follow me on twitter: @jefftschwartz

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[veenatic]

Does this mean that "auth token" in the request payload is not of much use?
Also, I want to understand when i have the token set in the requestfactory 
payload, how to retrieve from the payload when a service call is made by 
requestfactory since i will have to validate the token for every service 
request.

On Friday, February 25, 2011 3:49:32 PM UTC+2, Thomas Broyer wrote:
>
> Of course! I didn't mean to imply that you shouldn't secure your app, but 
> honestly if someone succeeds in hijacking your session, then he could 
> possibly do it before loading the host page, so that your GWT app will run 
> with the hijacked session, and the "auth token in the request payload" won't 
> be of any help.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Jeff Schwartz]

Hi Thomas,

On Fri, Feb 25, 2011 at 8:49 AM, Thomas Broyer  wrote:

> Of course! I didn't mean to imply that you shouldn't secure your app, but
> honestly if someone succeeds in hijacking your session, then he could
> possibly do it before loading the host page, so that your GWT app will run
> with the hijacked session, and the "auth token in the request payload" won't
> be of any help.


First off, the hacker couldn't have access to the local cookie on the user's
machine unless the user has been infected with a virus. If the user's
computer has been infected with a virus that can some how target local
cookies then this user has a lot more to worry about than someone hijacking
their session. So let's rule that scenario out.

Secondly, if the hacker could somehow manage to hijack your session -
meaning they've some how coerced the request to use a different value for
the session id) and do it before loading the host page it wouldn't make a
difference if every Servlet method that is called does the following:
1) checks each payload for an auth token (a value equal to the sid stored as
a cookie on the client) and
2) compares the auth token's value to the HttpSession's session id value. If
they aren't the same then throw a custom exception and catch it on the
client and authenticate the user (either form-based auth or some other
method such as Google Account, OpenId, et. al)

Not only does the above protect against session hijacking but it also solves
the "how do I know if the session is timed out" question. So you solve two
use cases in one implementation which isn't bad.

You can even use filters to do this eliminating the need for every Servlet
method to implement this logic.

It's a simple, viable solution to an attack that is quite prevalent these
days. It's implementation on both the client and server are trivial yet (I
would venture to guess) is regrettably ignored by many if not most
developers (to which I am not limiting to GWT developers).

Of course, having a secure transport protocol (ie SSL) is the ultimate
solution but not every site or every page on a site requires SSL yet every
page that communicates with the server on every site requires a proactive
defense against these kinds of attacks.


> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>



-- 
*Jeff Schwartz*
http://jefftschwartz.appspot.com/
http://www.linkedin.com/in/jefftschwartz
follow me on twitter: @jefftschwartz

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

Of course! I didn't mean to imply that you shouldn't secure your app, but 
honestly if someone succeeds in hijacking your session, then he could 
possibly do it before loading the host page, so that your GWT app will run 
with the hijacked session, and the "auth token in the request payload" won't 
be of any help.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Jeff Schwartz]

On Thu, Feb 24, 2011 at 6:19 PM, Thomas Broyer  wrote:

> In such a scenario, you'll generally have a "session" maintained by the
> server through a cookie, which will be enough (yes, cookies are not that
> secure, but still deemed secure enough that everyone from Google to
> Facebook, Twitter, Microsoft, Yahoo!, etc. use them).
>

I respectfully disagree, Thomas, and think your advice on this is ill
served. In addition I believe that there are those at all the companies that
you mentioned who would take issue with your opinion. Values from cookies
that are explicitly maintained on the client and which are transported to
the server as part of an RPC's  payload can be trusted but values which come
directly from HTTPRequest's cookies aren't trustworthy. That's a fact. Leave
one little hole open and some malcontent with a half a brain is going to
take advantage of it and hijack your session. It's such an easy prevention
to implement that one would have to be foolish to not take advantage of it.

-- 
*Jeff Schwartz*
http://jefftschwartz.appspot.com/
http://www.linkedin.com/in/jefftschwartz
follow me on twitter: @jefftschwartz

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

In such a scenario, you'll generally have a "session" maintained by the 
server through a cookie, which will be enough (yes, cookies are not that 
secure, but still deemed secure enough that everyone from Google to 
Facebook, Twitter, Microsoft, Yahoo!, etc. use them). The RequestTransport 
will then be useful to detect when the session/cookie have expired.

Now, if your "host page" (the page that "hosts" the GWT app) can now an 
authentication token, then you can output it in the page (using a JSP for 
instance) and use a Dictionary to retrieve it from your GWT code.
See http://code.google.com/webtoolkit/articles/dynamic_host_page.html

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[veenatic]

>
> If you want to pass an "authentication token" on each request, then the 
> RequestTransport is the way to go on the client-side.
>
> Have a look 
> http://code.google.com/p/google-web-toolkit/source/browse/tags/2.1.1/samples/expenses/src/main/java/com/google/gwt/sample/gaerequest/
>  which 
> is used in the Expenses sample.


Hi Thomas,
Thanks for all your valuable insight to the subject.
I am looking for some more explanation on the above. If I understood 
correctly, we can implement separate page for login and a separate page 
where the gwt app resides. Once the user is authenticated from login page, 
we have the "security token", but how to communicate the token obtained from 
the login page to the gwt app so that we can put the token in the 
RequestTransport and initialize the RequestFactory.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

On 16 February 2011 12:14, Ernesto Reig  wrote:

>
>
> On 26 January 2011 14:53, Thomas Broyer  wrote:
>
>> You mean how I *did* implement it? ;-)
>>
>> Using the same pattern as the Expenses sample:
>>
>>1. out HTML host page (the one calling the *.nocache.js) is protected
>>with a simple servlet FORM authentication
>>(FORM in the web.xml); nothing special
>>here.
>>2. the server returns a known error response for unauthenticated
>>requests (i.e. a 401 status code, I didn't include a WWW-Authenticate 
>> header
>>which is in violation of HTTP, but it just works so...), this is done in a
>>servlet Filter, where I simply check for request.getUserPrincipal() != 
>> null.
>>This has really nothing specific to RequestFactory, and we use it with 
>> other
>>XMLHttpRequest-driven requests too.
>>
>> I don´t know why this is wrong, but the checking of
> request.getUserPrincipal() != null seems to be valid only the first time a
> request is made. The following requests (made by the requestFactory),
> getUserPrincipal() returns null. Here´s my code in my AuthFilter class:
>
> public void doFilter(ServletRequest servletRequest, ServletResponse
> servletResponse, FilterChain filterChain) throws IOException,
> ServletException {
>   HttpServletRequest request = (HttpServletRequest) servletRequest;
>   HttpServletResponse response = (HttpServletResponse) servletResponse;
>
>   if(request.getUserPrincipal() == null) {
> response.setHeader("WWW-Authenticate", "FORM realm=\"userRealm\"");
> response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
> return;
> }
>
> What am I doing wrong?
>

Sorry, it was my fault. I have it solved :)

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

On 26 January 2011 14:53, Thomas Broyer  wrote:

> You mean how I *did* implement it? ;-)
>
> Using the same pattern as the Expenses sample:
>
>1. out HTML host page (the one calling the *.nocache.js) is protected
>with a simple servlet FORM authentication
>(FORM in the web.xml); nothing special
>here.
>2. the server returns a known error response for unauthenticated
>requests (i.e. a 401 status code, I didn't include a WWW-Authenticate 
> header
>which is in violation of HTTP, but it just works so...), this is done in a
>servlet Filter, where I simply check for request.getUserPrincipal() != 
> null.
>This has really nothing specific to RequestFactory, and we use it with 
> other
>XMLHttpRequest-driven requests too.
>
> I don´t know why this is wrong, but the checking of
request.getUserPrincipal() != null seems to be valid only the first time a
request is made. The following requests (made by the requestFactory),
getUserPrincipal() returns null. Here´s my code in my AuthFilter class:

public void doFilter(ServletRequest servletRequest, ServletResponse
servletResponse, FilterChain filterChain) throws IOException,
ServletException {
  HttpServletRequest request = (HttpServletRequest) servletRequest;
  HttpServletResponse response = (HttpServletResponse) servletResponse;

  if(request.getUserPrincipal() == null) {
response.setHeader("WWW-Authenticate", "FORM realm=\"userRealm\"");
response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
return;
}

What am I doing wrong?

>
>1. the client handles the known error response in a custom
>RequestTransport (in our case, for the time being, we simply Window.alert()
>the user, prompting him to refresh the page to re-authenticate)
>
>
> (BTW, thank you for the "expert" qualifier ;-) )
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Thank you very much for your responses Thomas and Y2i.

Maybe, this can help to other people who are (like me) changing from Tomcat
to Jetty. Refering to the web.xml and jetty-web.xml:

 - I did know that jetty.home was pointing to my working directory
(C:\workspace\my_app\src\main\webapp in my case), but my problem was that I
couldn´t understand that Jetty was going to look for the users in a
properties file inside my_app. I was trying to draw an analogy between the
tomcat-way and the Jetty-way. I though "if the authentication is against the
server (jetty), why do I have to provide the users to Jetty?" And the answer
to this question is that this properties file is used to authenticate users
ONLY for THIS web application.
For Tomcat users: it´s like configuring a realm inside a  element (
http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#Configuring_a_Realm
).

I presume that in a real context, you can have the properties file inside
your_app, or establish the jetty.home system property and point to the
properties file inside jetty.home/etc/realm.properties and authenticate as a
user shared in all web apps.

Thank you very much again.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

thank you very much for the link.  So I've been using a wrong version all 
along...

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

Oops, sorry: 6.1.11 (but you'd have clicked the link to get the 
authoritative answer, right? ;-) )

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

Jetty classes are packaged within gwt-dev.jar, that one comdes from 
somewhere else (Eclipse WTP ?)
The version used by GWT is 6.1.1: 
http://code.google.com/p/google-web-toolkit/source/browse/tags/2.1.1/dev/build.xml#62

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

Based on the below I assumed it's 6.1.23, this is what I'm using.

find . -name "*jetty*"
./org.eclipse.equinox.http.jetty_2.0.0.v20100503.jar
./org.mortbay.jetty.serveradaptor_1.0.4
./org.mortbay.jetty.serveradaptor_1.0.4/icons/jetty_tiny.gif
./org.mortbay.jetty.serveradaptor_1.0.4/servers/jetty.serverdef
*./org.mortbay.jetty.server_6.1.23.v201004211559.jar*
*./org.mortbay.jetty.util_6.1.23.v201004211559.jar*

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

On Thursday, January 27, 2011 7:49:01 PM UTC+1, ernesto.reig wrote:
>
> Ok. Now I´m configuring the application to authenticata against the 
> embedded Jetty server wich comes with GWT. Please, correct me if I´m wrong:
>  - I have to create a jetty-web.xml in WEB-INF of my gwt application with 
> the following text:
>
> 
>   /test
>default="."/>/webapps/test


You don't have to set these: you're already in the webapp (I don't think the 
contextPath will be used given the way the webapp is deployed)

   ...
>   
> 
>   
> Test Realm
>  default="."/>/etc/realm.properties
>   


The "jetty.home" points to your working directory (according to my comment 
in http://code.google.com/p/google-web-toolkit/issues/detail?id=4462), which 
generally will be your "war" folder.

(compared to the sample jetty-web in my comment on the issue, you would just 
need to replace the "authenticator" with the , or you could 
use the same thing as I used to use)

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Ok. Now I´m configuring the application to authenticata against the embedded
Jetty server wich comes with GWT. Please, correct me if I´m wrong:
 - I have to create a jetty-web.xml in WEB-INF of my gwt application with
the following text:


  /test
  /webapps/test
   ...
  

  
Test Realm
/etc/realm.properties
  

  


And it gives me the following exception:
java.io.FileNotFoundException:
C:\workspace\myapp\src\main\webapp\etc\realm.properties (The system cannot
find the path specified)
Of course it does not find the file realm.properties. First, I have no
jetty.home system variable set, and second, what would it be the value of
this system variable??
The thing is, if I want to use HashUserRealm for my webapp authentication,
Jetty looks for a properties file to find the users and their credentials,
but where the hell is that file? Jetty is embedded...

Maybe I´m wrong in something. Please help.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Thank you very much for your response. At the moment I´m studying jetty and
I get to a very simple question:
*¿What is or how can I know, the current Jetty version of the current GWT
version?* Now I´m using 2.1.1
This is a very simple question that I cannot understand why in the world
there´s no answer in the GWT official documentation...

Thank you in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

I also started from using Tomcat, but the debugging issue forced me to 
switch to Jetty.  It took time to learn Jetty's specifics but it was worth 
it.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Hello again.
It seems that I get stuck in every step... The thing is that I don´t know
how to use Tomcat for the Development Mode instead of the embedded Jetty.
I´ve been reading lots and lots of docs (including
http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html#How_do_I_use_my_own_server_in_development_mode_instead_of_GWT%27s)
but I still haven´t found a way to do it. In my opinion it isn´t well
explained at al, it´s very unclear...
I have arrived to this because, as you said, protecting the host page with a
"servlet FORM authentication" forces me to use Tomcat.
So I need to check that the servlet authentication I am implementing is
right. Therefore, I have to deploy my webapp in Tomcat, BUT I don´t want to
end up re-deploying the application in Tomcat every time I make a little
change in the code.

Any help on this, please?

Than you very much.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Thank you very much for your response Thomas. I´ve reading and reading about
the servlet authentication and I was going to ask you some more things about
this approach, but I can´t sort my ideas now hehe. I´ll carry on this
tomorrow :)

Thank you again.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

You mean how I *did* implement it? ;-)

Using the same pattern as the Expenses sample:

   1. out HTML host page (the one calling the *.nocache.js) is protected 
   with a simple servlet FORM authentication 
   (FORM in the web.xml); nothing special 
   here.
   2. the server returns a known error response for unauthenticated requests 
   (i.e. a 401 status code, I didn't include a WWW-Authenticate header which is 
   in violation of HTTP, but it just works so...), this is done in a servlet 
   Filter, where I simply check for request.getUserPrincipal() != null. This 
   has really nothing specific to RequestFactory, and we use it with other 
   XMLHttpRequest-driven requests too.
   3. the client handles the known error response in a custom 
   RequestTransport (in our case, for the time being, we simply Window.alert() 
   the user, prompting him to refresh the page to re-authenticate)


(BTW, thank you for the "expert" qualifier ;-) )

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Thomas, just to know an expert opinion. How would you implement the custom
authentication? I mean, not using GAE.

Thank you in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Someone to deny or confirm my two previous comments on this post?

Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

I forgot to say this in my previous message:
I don´t think that including the Expenses app in the distribution of GWT is
a good idea. I ONLY SAY THIS BECAUSE OF THE AUTHENTICATION APPROACH USED. I
mean, it seems to be a custom app for a private organization/company. But as
said in my previous comment, you cannot use custom authentication. And I
don´t think a company would like to have its expenses and reports available
to the world (using google accounts or openID).
The only way it is justified would be if the authentication used in GAE in
the Expenses app was using the accounts from a Google Apps domain for the
users of a given company. Which I think it should be explained or commented
in the application.

I would appreciate any comment about this.
Thank you again.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Thank u for your help and comments Y2i (and the others).
To sum up, I will say that Google App Engine is a great thing to use with
your apps, but it´s designed for apps where everybody having an openID
account can log in, I mean, you cannot have your custom authentication.
- You cannot have your app using GAE for private purposes with your private
users (unless your users have a Google Apps account, which is too expensive
(50$/user)).
- You cannot restrict the access to everybody, allowing only a set of users
(your clients, employees, etc) with a username and password that you
provide.
This is a very common feature for web applications which is not considered
in GAE. I would like  to have my private web app (with my private users)
hosted in GAE, and pay for that as the numbers of new users I register
grows.
Well, I´ll post my final solution for the authentication (maybe a common
one), but it´s a pity I cannot use GAE :(

Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

It sounds, based on the full control requirement, that you cannot deploy on 
GAE.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Following my previous post...
what I need is to provide my users with username and password, and to have
full control of the users that login in my application. I don´t want that
everybody who has a google account or an openID identifier can do login. So,
the question again:
 - Is this possible using GAE Authentication?

Thank you very much.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Ok. If I haven´t misunderstood (reading at
http://code.google.com/appengine/docs/java/users/overview.html#Authentication_Options),
you have three options to authenticate users with App Engine:
 - A Google Account
 - An account from an (my) Google Apps domain.
 - An OpenID identifier

BUT, if I wanted to use my custom authentication I couldn´t do it any of
these three ways, could I? I mean, I don´t want to have my users forced to
create a Google Account or an OpenID account. I just need to give my users a
username and password (via paper) in order to allow them to login in the
system. This is because most of the users will be people with
zero-internet-knowldge and they will receive the username and password,
which they will write in the login screen.
 - Is this possible using GAE Authentication?
 - Do I have missed anything?

Thank you very much.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

Take a look here
http://code.google.com/appengine/docs/java/config/webxml.html#Security_and_Authentication

And then here (the first link will also point you here)
http://code.google.com/appengine/docs/java/users/

Also read the overview 
http://code.google.com/appengine/docs/java/users/overview.html

The overview explains how users are authenticated.  Once a user is 
authenticated, UserService will know about the user.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Keeping on trying to fully understand GAE Authentication, with the Expenses
example approach, I find these lines of code:

UserService userService = UserServiceFactory.getUserService();
...
if (!userService.isUserLoggedIn()) {
  ...
}

And now I get stuck into this.
 - What is that UserService? Ok, it´s the interface
com.google.appengine.api.users.UserService.
 - But how does it work? How can it check if a user is logged in? where the
hell does it get the users from?

Thank you in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

Sorry if I was not clear, I didn't say it's the best to use GAE, it all 
depends on your requirements.  GAE is a web server where you deploy your 
application.  If you chose to deploy on GAE then it's better to use 
authentication offered by GAE.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Ok. I´ve been having a look to GAE Authentication. And there are things I
don´t understand well...
If you look at this page (
http://code.google.com/p/gwt-gae-book/wiki/Authentication), which seems to
be quite reliable, it clearly says "Although it's possible to develop App
Engine applications with custom authentication (e.g. using your own
username/password lookup, or by connecting to custom 3rd party web
services), we'll focus on OpenID".
Well, the thing is that* I do need custom authentication*. I need to
generate my own usernames and their corresponding passwords to log in. I
don´t know how to do it with GAE, but as above mentioned, it said "*it's
possible to develop App Engine applications with custom authentication*".
So the question is:
 - How do I implement custom authentication using GAE?
 - Can I use the approach used by the Expenses sample? If so, what do I have
to change/customize?
 - Using App Engine, can I use my own MySQL tables (for users and other
data)?

I know I´m a bit confused.
Thank you for your help.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Thank you Y2i. The thing is that I don´t use GAE. I´ve never used GAE
actually. But, as I said in my first comment, I want to implement the
authentication/authorization the best way (the most
recommended/professional) to do it.
If you think, from your experience, that the best way is using GAE, I will.

Thank you very much again.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

On Tuesday, January 18, 2011 9:05:23 AM UTC-8, ernesto.reig wrote:
>
> It does not make sense to have 2 RequestFactory(s) in a single web app. I´d 
> have 2 (or more) RequestContext, and I´d get them having these methods in my 
> AppRequestFactory interface (one of them dealing with the user management):
>
 
It does if you use declarative security combined with form-based 
authentication as described Servlet specification.   
requires  URL that un-authenticated users can access to 
perform authentication.

As I said earlier, there are many ways to implement 
authentication/authorization.  If you use GAE it's better to stick with what 
it offers.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Thank you Thomas. I´ll have a look (and try to understand) the approach
you´ve recommended (used in the Expenses sample).
What a coincidende today I´ve been reading a blog
http://tbroyer.posterous.com/ Maybe you know it ;) Congratulations for your
great posts.

Thank you very much.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Thomas Broyer]

If you want to pass an "authentication token" on each request, then the 
RequestTransport is the way to go on the client-side.

Have a look 
http://code.google.com/p/google-web-toolkit/source/browse/tags/2.1.1/samples/expenses/src/main/java/com/google/gwt/sample/gaerequest/
 which 
is used in the Expenses sample.

However, if you want to do your login() call using RequestFactory, then 
you'd of course get rid of the servlet filter and then either add checks in 
each service method requiring authentication (not productive, but easy to 
comprehend) or somehow "filter" the invocations using a 
ServiceLayerDecorator (kind of AOP-like) that report() any unauthorized 
call. You'd probably couple that with a 
com.google.gwt.requestfactory.server.ExceptionHandler and generic error 
management in your Receiver subclasses (in onFailure).

I'm talking from experience: I'd highly recommend doing sign-in outside the 
app and use the approach used by the Expenses sample (though I acknowledge 
there are use-cases for "in app" authentication that people think are worth 
the trouble)

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

It does not make sense to have 2 RequestFactory(s) in a single web app. I´d
have 2 (or more) RequestContext, and I´d get them having these methods in my
AppRequestFactory interface (one of them dealing with the user management):

ARequest aRequest();
BRequest bRequest();

The question of having the session management with GWT RPC is because I was
following these directions:
http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQand
I wonder how to implement session management
(authentication/authorization) with RequestFactory.

Every help will be appreciated. Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

It probably does not matter, RequestFactory is just a form of RPC.  You can 
have 2 request factories: one for login, anther for the rest of the app.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ernesto Reig]

Thank you very much for your responses.
So, in order to clarify things:
Is it better to use RequestFactory to "talk" to the server in every case? or
is it better to use GWT RPC when the user first logs in (sending the
credentials to the server and creating the session id) and RequestFactory
for everything else?

Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

P.S. Forgot to mention that if you use GAE, it's better to start from this 
page
.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Ryan Mehregan]

The best practice for developing GWT applications is to keep the
server-side of your code as "Stateless" as possible.

In the past, with traditional web frameworks, there was not much you
could do on the client,
we only had basic html forms, which we asked user for input, and most
of the processing was done on the server.
Also, with traditional web frameworks and web apps, your application
was consisted of "Pages".
when our use cases were too big to fit in a single "Page", we had to
spread it across a number of pages,
and the challenge was to keep the data in consistent state as user
navigated from one page to another page within related pages for the
usecase.
JBoss Seam and Spring Webflow have the concept of conversation, to
deal with these scenarios.

However, with GWT, you have only ONE page. therefore you do not have
to maintain State between "Pages".
if your UseCase is complex, you do not need multiple pages for that.
you can have complex widgets, show/hide widgets as necessary.
and do much of the processing on the client. You can also cache data
on the client. and if you use RequestFactory it does that for you.

The only time you need to contact the server is Request for Data or
Updating the existing data. and it doesn't have to be stateful.

it is best only to keep only the user (session) id on the server, to
discern the current user making the request.

You can maintain as much state you want on the client, but
the recommended practice is to keep your application STATELESS on the
server.

Ryan

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[Y2i]

There are many ways to implement logins, depending on the server side you 
use.  

If you use servlets then the servlet spec will guide you: 
http://jcp.org/aboutJava/communityprocess/pr/jsr315/index.html

Look at , , , 
,  tag description

Once web.xml is configured, you need to configure your realm.  This part is 
server-specific. 

If you use Jetty 6.1.x (the version embedded into GWT distribution), then 
look at org.mortbay.jetty.webapp.WebAppContext's securityHandler, which is 
configured in jetty-web.xml.
If you want to use JAAS for authentication and authorization, 
configure securityHandler with org.mortbay.jetty.plus.jaas.JAASUserRealm. 

JAASUserRealm itself requires module configuration.  If you want to use a 
datastore to keep user credentials, then conigure the module 
with org.mortbay.jetty.plus.jaas.spi.DataSourceLoginModule.

Other servers (including GAE) have their own settings, I'm just afraid I'm 
getting too specific here...

 

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[junaid]

You need to put session code in server side

if you know the basics of session ,below code would be helpful

HttpSession session;

session= getThreadLocalRequest().getSession(*true*);

*save value in session:*

session.setAttribute("myuser", user);  [ myuser-- name of the session ]
[user- any object,string]

*get value from session:*

session.getAttribute("myuser");

cheers

On Mon, Jan 17, 2011 at 10:11 AM, ernesto.reig  wrote:

> Hello everybody.
> I´m trying to develop my first gwt mvp application following the
> directions given in
> http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html
> I want to make a login page where the user has to log in before
> entering to the main application view. Anyway, the thing is that I
> have to implement the user sessions in the application and I would
> like to know the best (the most recommended or professional) way.
> I´ve been googling but I´m getting a bit lost since I don´t find a
> clear solution. I found
> http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ
> but I´m not sure if that´s the best way to do it.
> I´d apprecciate every help.
>
> Thank you very much.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: gwt mvp sessions

[ernesto.reig]

Any comments please?

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

gwt mvp sessions

[ernesto.reig]

Hello everybody.
I´m trying to develop my first gwt mvp application following the
directions given in 
http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html
I want to make a login page where the user has to log in before
entering to the main application view. Anyway, the thing is that I
have to implement the user sessions in the application and I would
like to know the best (the most recommended or professional) way.
I´ve been googling but I´m getting a bit lost since I don´t find a
clear solution. I found 
http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ
but I´m not sure if that´s the best way to do it.
I´d apprecciate every help.

Thank you very much.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.