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.
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...
On Oct 15, 11:43 pm, Mark <sschwa...@shoptext.com> wrote:
> 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.
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.
> 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...
> On Oct 15, 11:43 pm, Mark <sschwa...@shoptext.com> wrote:
> > 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.
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?
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.
On Dec 19, 7:58 am, mrpantsuit <kevin.peter.w...@gmail.com> wrote:
> 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?
> 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.
> On Dec 19, 7:58 am, mrpantsuit <kevin.peter.w...@gmail.com> wrote:
> > 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?
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.
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.
On Jan 13, 1:01 am, Allen Holub <allen.ho...@gmail.com> wrote:
> 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.
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.
On Jan 12, 11:44 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> 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.
> On Jan 13, 1:01 am, Allen Holub <allen.ho...@gmail.com> wrote:
> > 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.
> 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.
> On Jan 12, 11:44 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > 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.
> > On Jan 13, 1:01 am, Allen Holub <allen.ho...@gmail.com> wrote:
> > > 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.
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:
> On Jan 14, 1:53 am, Allen Holub <allen.ho...@gmail.com> wrote:
> > 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.
> > On Jan 12, 11:44 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > > 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.
> > > On Jan 13, 1:01 am, Allen Holub <allen.ho...@gmail.com> wrote:
> > > > 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.
|
