Container managed security and time-out of the webapp.
In my GWT application MyApp I'm using container managed security
(logon through html form with
action=j_security_check and input elements j_username and j_password).
Works fine except
when the application times out: the container doesn't allow the RPC
service to be executed anymore on the server, so it throws back the
html of the logon-form. But the client side RPC code has no 'solid'
way of detecting this.
Currently I've implemented it as follows: in the onFailure method,
check if it's an InvocationException, then check if it contains a bit
of html that's in the logon-page.
If yes, then redirect to the start page of my app.
AsyncCallbackVoid callback = new AsyncCallbackVoid()
{
public void onFailure(Throwable caught)
{
if ( (caught instanceof InvocationException)
(caught.getMessage().contains(htmlheadtitleMyApp
Logon/title/head) ))
{
Window.Location.assign(MyApp.html);
}
else
{
..
Is there a more proper way of doing this?
Regards,
Willem
--~--~-~--~~~---~--~~
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: Container managed security and time-out of the webapp.
Hello
There have been many approaches to securing GWT applications, I think
it all depends on your application workflow. But an approach similar to
yours that i'm used to follows:
- Create a servlet filter to filter requests for the GWT module
servlets. Then in the doFilter() method do something like ...
HttSession session = request.getSession(false); // get the
session attached to request
if(session == null) { // the case if client is not logged in
ression.sendError(HttpServletResponse.SC_UNAUTHORIZED);
} else {
chain.doFilter(request, response); // pass request on to
the GWT servlets
}
- Next create a custom AsyncCallback handler for the client side
wherein the onFailure() method does something like this ..
void doFailure(Throwable t) {
try {
throw t;
} catch (IncompatibleRemoteServiceException e) {
// this client code is not compatible with the server
refresh the browser to download new one
Window.Location.reload();
} catch (StatusCodeException e) {
// the call didn't complete cleanly
switch (e.getStatusCode()) {
case 401: // Authentication required; reload the whole
page so server can enforce login
Window.Location.reload();
break;
default:
// do other tests or pass on to an abstract method
so you can do more localized processing
}
} catch (Throwable e) {
// shouldn't get here though ...
}
}
then you can use the custom AsyncCallback handler in other RPC requests
of the application
However, this approach appears to require some application design issues
- the URL (especially the history tokens) you choose SHOULD be mapped
to known application states, so that the application can appear to
return to where it was before the Window.Location.reload() call.
- the host page of the GWT module SHOULD be placed behind a security
constraint
This way i've been able to use container managed security and standard
servlet security annotations in my application
Just another way of achieving the same result :-)
Cheers
Sikiru
willemsl...@gmail.com wrote:
In my GWT
application MyApp I'm using container managed security
(logon through html form with
action="" and input elements j_username and j_password).
Works fine except
when the application times out: the container doesn't allow the RPC
service to be executed anymore on the server, so it throws back the
html of the logon-form. But the client side RPC code has no 'solid'
way of detecting this.
Currently I've implemented it as follows: in the onFailure method,
check if it's an InvocationException, then check if it contains a bit
of html that's in the logon-page.
If yes, then redirect to the start page of my app.
AsyncCallbackVoid callback = new AsyncCallbackVoid()
{
public void onFailure(Throwable caught)
{
if ( (caught instanceof InvocationException)
(caught.getMessage().contains("htmlheadtitleMyApp
Logon/title/head") ))
{
Window.Location.assign("MyApp.html");
}
else
{
..
Is there a more proper way of doing this?
Regards,
Willem
--~--~-~--~~~---~--~~
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: Container managed security and time-out of the webapp.
Thanks for your quick response and elaborate answer, Braheem!
I've tried a servlet-filter, but that didn't work for me since my
security constraint protects EVERY possible url within my app, see
following URL-pattern:
security-constraint
web-resource-collection
..
url-pattern/*/url-pattern
I guess I'll have to make this more fine grained, and put the servlet
filter servlet in an unprotected area.
Ciao,
Willem
On Jun 20, 12:01 pm, Braheem Sikiru sbrah...@gmail.com wrote:
Hello
There have been many approaches to securing GWT applications, I think it all
depends on your application workflow. But an approach similar to yours that
i'm used to follows:
- Create a servlet filter to filter requests for the GWT module servlets.
Then in the doFilter() method do something like ...
HttSession session = request.getSession(false); // get the session
attached to request
if(session == null) { // the case if client is not logged in
ression.sendError(HttpServletResponse.SC_UNAUTHORIZED);
} else {
chain.doFilter(request, response); // pass request on to the
GWT servlets
}
- Next create a custom AsyncCallback handler for the client side wherein the
onFailure() method does something like this ..
void doFailure(Throwable t) {
try {
throw t;
} catch (IncompatibleRemoteServiceException e) {
// this client code is not compatible with the server refresh the
browser to download new one
Window.Location.reload();
} catch (StatusCodeException e) {
// the call didn't complete cleanly
switch (e.getStatusCode()) {
case 401: // Authentication required; reload the whole page
so server can enforce login
Window.Location.reload();
break;
default:
// do other tests or pass on to an abstract method so you
can do more localized processing
}
} catch (Throwable e) {
// shouldn't get here though ...
}
}
then you can use the custom AsyncCallback handler in other RPC requests of
the application
However, this approach appears to require some application design issues
- the URL (especially the history tokens) you choose SHOULD be mapped to
known application states, so that the application can appear to return to
where it was before the Window.Location.reload() call.
- the host page of the GWT module SHOULD be placed behind a security
constraint
This way i've been able to use container managed security and standard
servlet security annotations in my application
Just another way of achieving the same result:-)
Cheers
sikiruwillemsl...@gmail.comwrote:In my GWT application MyApp I'm using
container managed security
(logon through html form with
action=j_security_check and input elements j_username and j_password).
Works fine except
when the application times out: the container doesn't allow the RPC
service to be executed anymore on the server, so it throws back the
html of the logon-form. But the client side RPC code has no 'solid'
way of detecting this.
Currently I've implemented it as follows: in the onFailure method,
check if it's an InvocationException, then check if it contains a bit
of html that's in the logon-page.
If yes, then redirect to the start page of my app.
AsyncCallbackVoid callback = new AsyncCallbackVoid()
{
public void onFailure(Throwable caught)
{
if ( (caught instanceof InvocationException)
(caught.getMessage().contains(htmlheadtitleMyApp
Logon/title/head) ))
{
Window.Location.assign(MyApp.html);
}
else
{
..
Is there a more proper way of doing this?
Regards,
Willem
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
