Some good info in that link, Isaac, thanks.

"Do NOT attempt to use the Cookie header to transfer the sessionID
from GWT to the server; it is fraught with security issues that will
become clear in the rest of this article. You MUST transfer the
sessionID in the payload of the request. For an example of why this
can fail, see CrossSiteRequestForgery. "

Hm.  Well, ok then... i guess i should heed that warning.

The article doesn't seem to directly address Nickelnext concern about
having the admin content already in the browser though.  I mean, once
you compile the UI into javascript and the browser downloads it,
everything that the view does is there in the browser.  It seems
pretty far out there that someone could use that obfuscated javascript
mischievously but that's what hacking is all about, so i hear!

Trevis

On Jul 29, 12:46 pm, Isaac Truett <itru...@gmail.com> wrote:
> http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecur...
>
> This FAQ and the Security for GWT Applications article it links to should 
> help.
>
> - Isaac
>
> On Wed, Jul 29, 2009 at 1:40 PM, Trevis<trevistho...@gmail.com> wrote:
>
> > Ah, I understand your concern.
>
> > Hm. Maybe someone with more GWT experience can chime in on this but
> > i'm thinking this.  It's not like you have a simple hidden DIV in the
> > browser that you're deciding to show dynamically.  You have a
> > javascript function that generates that div, which i'd imagine would
> > be a lot tricker to hack (though probably not impossible if the hacker
> > were properly motivated) Even still, what would the hacker have access
> > to at that point? He'd see the admin tab... but what could he do with
> > it?  You should implement your security so that the admin RPC methods
> > also require some kind of authentication.  This way, a determined
> > hacker may be able to see the tab but he still couldn't do anything
> > with it.  Not knowing your exact application, this may have other
> > complications but that is the way that i'd probably be thinking of
> > doing it.
>
> > I'd love to hear some alternative solutions as i'm pretty much in the
> > same boat as you are.  I'm porting my first major application to GWT
> > and i've been going with the assumption that server based security for
> > the admin RPC's combined with obfuscated javascript will give me a
> > similar level of security to what i would get by traditional means.
> > (though arguably better since there will be no history trail to the
> > admin pages left in the browser since gwt allows you to not cause any
> > browser history footprint that you don't deliberately generate)
>
> > On Jul 29, 12:27 pm, Nickelnext <nickeln...@gmail.com> wrote:
> >> Hello
>
> >> You suggest that when the callback gets the Onsuccess and the user is
> >> valid, i can simply add a new tab or panele or whatever making the
> >> Admin Area visible?
>
> >> Your solution would be perfect, and i thought of it yet but my
> >> question is: isn't it easily hack-able? I mean, inside the javascript
> >> that gwt compiles there would be also the admin area, so a malicious
> >> user could, with some tricks, retrieve the content and do some ugly
> >> things with my app, couldn't he?
>
> >> What i mean is: is this easy and fast solution also secure? Would be
> >> the part of the admin area untouchable if the user doesn't
> >> authenticate himself or there should be a possibility? Because if i'm
> >> not wrong, the solution you suggest isn't like one with, for example,
> >> a PHP page that renders a new html page with the private content, but
> >> the content is himself into the Application, cause the Admin Area tab
> >> (or else) is in the client code (and so in whoever's open my app
> >> browser).
>
> >> Sorry for my bad bad english, hope you get the point.
> >> Thank you!
> >> Nickelnext
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to