Debate sobre security-for-gwt-applications

[Claudio Fainschtein]

Very usefull, but what about integration with JAAS?

[mickey]

Hi

[Maarten Volders]

Also 'Hi' Mickey :-)

Do you also have a question or just want to greet the community, which also can be appreciated ;-)

Grtz

On 6/28/07, mickey <i274....@gmail.com> wrote:

Hi

[Vaclav]

And what about integration with Acegi? ;)

[Mark]

I tried integrating with JAAS using server-side authentication. The
roadblock appears to be caching the LoginContext on the client. How
can I pass it via GWT RPC? It won't [de]serialize (no no-arg
constructor) and GWT won't pass Java Object instances.

[mP]

Your Context is a server side asset... it makes no sense sending it to
the client. If you really must keep it store it in the sesion or
something similar...

[Sami Ekblad]

In the IT Mill Toolkit we have addressed the security issues by
keeping the data control and application logic mostly in server side
components. These transparently sync with the client side (GWT)
widgets.

This approach makes it easier to avoid the security pitfalls of client-
side programming.
More about this: http://www.itmill.com/itmill-toolkit/

[mrpantsuit]

I'm a web security newbie, so this might be a dumb question. Why does
the session ID have to be stored in a cookie. If a login(..) RPC call
returns a session ID, couldn't that just be stored in a client-side
variable to be used in subsequent RPC calls?

[Reinier Zwitserloot]

Yup, you can. Only reason why you want to sidetrack through a cookie
is so that if the user closes the page, reloads, futzes with history
in the wrong browser, opens a new window, or otherwise resets the
javascript engine, that they don't need to log in again on the new
page.

[mrpantsuit]

Makes sense. Much obliged.

[Allen Holub]

Is it possible to do GWT-RPC over HTTPS? The URL that establishes the
RPC endpoint is relative to the page base, so there's no protocol, and
I can't find a discussion, anywhere, of how to specify a protocol. I'd
like to establish the session once, then have all RPC communication
happen over the same secure socket. Lacking that, using HTTPS for
login and doing other RPC functions in the clear will probably work,
but I can't see how to do this either.

I can, of course, use HTTPRequest to do the initial login, but RPC
would be more convenient.

Thanks.

[Reinier Zwitserloot]

You can't mix HTTP and HTTPS in one page unless you want to bother
your user with funky mixed mode warning boxes they don't understand.
If you want HTTPS, the entire page has to be HTTPS. A trick which some
sites pull (take you into HTTPS for a while and then back out,
transferring state via a cookie with the secure flag off) is not
feasible for GWT, because GWT is a one-page webapp.

[Allen Holub]

I do understand about the mixed-mode problem. What I'm really asking
about is GWT's behavior under HTTPS. Are you saying that, if the
initial URL used to download the main page of the GWT application is
HTTPS, then all subsequent RPC calls made from that page are
*guaranteed* to also use HTTPS. That is, does GWT notices and remember
the protocol used to download the main page and then automatically use
the same protocol on all subsequent RPC requests? Moreover, will it
do this in an efficient way that doesn't continually reopen SSL
connections?

Thanks.

[Reinier Zwitserloot]

Yes; 'relative URL' is not a fuzzy concept. If the main page is
https://www.myserver.foobar/, and you make a relative call to /api/
whatever, then that will resolve to https://www.myserver.foobar/api/whatever.
Period.

[walden]

Allen,

Note that you have control over the scheme used for RPC calls because
you are setting the URL for the RPC entry point when you create it.
Typical code:

MyAsyncService service = (MyAsyncService) GWT.create(MyService.class);
((ServiceDefTarget)
service).setServiceEntryPoint(GWT.getModuleBaseURL() + "MyService");

Maybe what you're really asking is whether getModuleBaseURL() is
guaranteed to return a URL with the same scheme the client accessed
your application with?

Walden

On Jan 14, 2:09 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Yes; 'relative URL' is not a fuzzy concept. If the main page ishttps://www.myserver.foobar/, and you make a relative call to /api/
> whatever, then that will resolve tohttps://www.myserver.foobar/api/whatever.

> > > > Thanks.- Hide quoted text -
>
> - Show quoted text -