--- On Tue, 4/12/11, Raphael André Bauer raphael.andre.ba...@gmail.com wrote:
From: Raphael André Bauer raphael.andre.ba...@gmail.com
Subject: Re: Login security question
To: google-web-toolkit@googlegroups.com
Cc: Leung leung1_2...@yahoo.com
Date: Tuesday, April 12, 2011, 9:39 PM
On Tue
Hi
According to article LoginSecurityFAQ,
http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ , I
have a point that I really want someone to make it clear for me.
From the article,
Your server will then validate this login, and return a sessionID to your GWT
app. The
On Tue, Apr 12, 2011 at 12:30 PM, Leung leung1_2...@yahoo.com wrote:
Hi
According to article LoginSecurityFAQ,
http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ ,
I have a point that I really want someone to make it clear for me.
From the article,
Your server
Hi Leung,
if you're realizing the log in and log out functionality within
your GWT app and not with other mechanism (e.g. container based
authentication),
you just need to make sure that the log-in RPC call to the server
returns an unique sessionID to your client. For the generation of the
FYI - I figured out how to elegantly handle this requirement. I
overrode the onBeforeRequestDeserialized method and verify the verifID
(what I call it) in there. I ignore the login method and invoke
doUnexpectedFailure for any method that does not pass the correct
verifID.
// Find the
Per the Login Security FAQ (http://code.google.com/p/google-web-
toolkit-incubator/wiki/LoginSecurityFAQ) I have a few questions:
1) We're storing the SID in a client-side cookie and then the GWT app
is grabbing that and sending it to the server with each RPC request.
How is that any different
I can answer the 2nd the fastest. It does make sense to have Tomcat
or whatever server handle things, until you have a multi-server
cluster. Then typical session management ideals are tossed out the
window.
On Dec 29, 7:10 am, akutz sak...@gmail.com wrote:
Per the Login Security FAQ
And the answer to #1 is 'there is no difference' if you do it that way - but
you shouldn't be getting it from a cookie at all, you should be storing it
in the app.
It's pretty obvious that if you get it from the cookie, someone can replace
the cookie; if you store it in the app, replacing the
If you do 1) you open yourself to XSRF attacks. Read this article
(http://groups.google.com/group/Google-Web-Toolkit/web/security-for-
gwt-applications) on how to avoid this by submitting a duplicate field
with the cookie value and verifying it on the server end before
executing the request
For
Ultimately I think much of my concern will be moot because SSL will be
turned on at all times. However, I do love academic discussions. As
for #1, let's say we refresh the page or the user closes the browser
and comes back. Either of those events requires the application to
initializes its static
akutz:
** YOU COULDNT BE MORE WRONG **
SSL protects against many things, but it does *NOT* protect against
XSRF. Which is -exactly- what you're opening yourself up to if you
only rely on the cookie automatically sent by the browser in the form
of the 'Cookie' header - which is the mechanism
I appreciate the response, but you're a complete and total ass. I do
not know why people let you get away with acting the way you do. We
come here for help, not abuse. We're not idiots, we simply don't
understand the subject as well as you do. I've seen your other
responses, and you are just as
So I'm not to reply to you but you do engage in a long missive to
explain your situation and then ask for help?
Let me know how calling people an ass before asking for help works out
for you.
On Dec 30, 12:47 am, akutz sak...@gmail.com wrote:
I appreciate the response, but you're a complete
I'm very grateful for your help, but not your attitude. If there is
anyone who would like to help me in a polite manner, I'd be more than
happy to listen to you. I enjoy being educated, and I often miss the
forest for the trees, but I do expect a certain amount of mutual
courtesy. What do you
14 matches
Mail list logo
