Problem: certain types of J2EE authentication with GWT 2.0 and Eclipse 3.5 plugin no longer work
Ian.G
everyone involved in this great project.
We've recently moved up to GWT 2.0 from GWT 1.7 and everything has
gone quite smoothly so far.
One of the issues I have with the application I'm developing is that
it needs to be secured by J2EE security and correctly manage session
timeout etc.
I know there are lots of hazy bits of information about how/how not to
do this along with potential problems the developer faces with the GWT-
RPC interface calls from the client after the session has expired etc.
- but I think in GWT 1.7 we had a 99% working solution to this that
wasn't anything whacky like using client-side timers to keep the
session alive - I just need to continue on and complete it now we've
moved over to GWT 2.0
I'll describe the problem and to take away the need to understand
anything specific to my app so this can all be re-produced from a std
wizard-generated GWT project in ecliipse 3.5 (i.e. the Greeting sample
that gets built when you start a new project). This sample wont
gracefully manage session expiry with GWT-RPC – but it will show a
problem that I think I've found with the GWT 2.0 eclipse plugin and
J2EE authentication.
This is the start of how I previously made GWT (before version 2.0)
use J2EE security - and get realm-based security working in the
Eclipse DEV environment (and thus whatever container we deploy into
for production systems from the app's .war file).
in the applications WEB-INF directory I have a jetty-web.xml that
contains the following:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
"http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Get name="SecurityHandler">
<Call name="setUserRealm">
<Arg>
<!-- Hash File-based Security Realm -->
<New class="org.mortbay.jetty.security.HashUserRealm">
<Set name="name">SecurityTestRealm</Set>
<Set name="config"><SystemProperty name="jetty.home"
default="."/>/WEB-INF/etc/realm.properties</Set>
<Set name="RefreshInterval">5</Set>
</New>
</Arg>
</Call>
</Get>
</Configure>
This is obviously used to inject a security realm into the JeTTY
instance that runs within the Eclipse plugin for GWT. This has always
worked perfectly on GWT 1.7 (using the old external hosted mode
runtime).
Then down in WEB-INF/etc/realm.properties we just add our users, and
role mappings as per the JeTTY documentation - for example:
username: password,testrole
At this point when I start the application I know the embedded JeTTY
server within the GWT plugin for eclipse is picking up the jetty-
web.xml file as it complains if the realm file can't be found if I
don't create it etc.
Obviously the next thing that needs to be done is plug in all the J2EE
security and session management stuff in the applications main
web.xml. So based upon a wizard generated project you would end up
with something like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<description>A sample GWT Application that makes use of J2EE security
and sessions</description>
<!-- Servlets -->
<servlet>
<servlet-name>greetServlet</servlet-name>
<servlet-
class>uk.co.somecompany.securitytest.server.GreetingServiceImpl</
servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>greetServlet</servlet-name>
<url-pattern>/securitytest/greet</url-pattern>
</servlet-mapping>
<!--Session Management -->
<session-config>
<session-timeout>10</session-timeout>
</session-config>
<!-- Default page to serve -->
<welcome-file-list>
<welcome-file>SecurityTest.html</welcome-file>
</welcome-file-list>
<!-- Application Security -->
<security-constraint>
<display-name>Security</display-name>
<web-resource-collection>
<web-resource-name>Security</web-resource-name>
<description>This Constraint works across the website</description>
<url-pattern>/securitytest/*</url-pattern>
<url-pattern>/SecurityTest.html</url-pattern>
<url-pattern>/SecurityTest.css</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>testrole</role-name>
</auth-constraint>
</security-constraint>
<!-- This application uses FORM authentication -->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>SecurityTestRealm</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login.jsp?error=true</form-error-page>
</form-login-config>
</login-config>
<!-- Define roles -->
<security-role>
<role-name>testrole</role-name>
</security-role>
</web-app>
(Obviously the login.jsp page provides a simple HTML form that posts
to j_security_check – all standard stuff)
Both the web.xml and jetty-web.xml were both validated 100% against
their respective DTDs.
When we start up the GWT app in eclipse (either run or debug) we see
the following in the eclipse console.
2010-01-06 13:30:37.581 java[1317:a07] [Java CocoaComponent
compatibility mode]: Enabled
2010-01-06 13:30:37.584 java[1317:a07] [Java CocoaComponent
compatibility mode]: Setting timeout for SWT to 0.100000
Starting Jetty on port 8888
[WARN] Unknown realm: SecurityTestRealm
[WARN] Configuration problem at <login-config><auth-method>FORM</auth-
method><realm-name>SecurityTestRealm</realm-name><form-login-
config><form-login-page>/login.jsp</form-login-page><form-error-page>/
login.jsp?error=true</form-error-page></form-login-config></login-
config>
java.lang.NullPointerException
at org.mortbay.jetty.webapp.WebXmlConfiguration.initLoginConfig
(WebXmlConfiguration.java:883)
at org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement
(WebXmlConfiguration.java:359)
at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize
(WebXmlConfiguration.java:289)
at org.mortbay.jetty.webapp.WebXmlConfiguration.configure
(WebXmlConfiguration.java:222)
at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:
69)
at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:
52)
at com.google.gwt.dev.DevMode.doSlowStartup(DevMode.java:332)
at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:953)
at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:690)
at com.google.gwt.dev.DevMode.main(DevMode.java:251)
[WARN] Unable to process 'file:/Users/idg/Workspaces/sag/SecurityTest/
war/WEB-INF/web.xml' for servlet validation
javax.servlet.UnavailableException: Configuration problem
at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize
(WebXmlConfiguration.java:298)
at org.mortbay.jetty.webapp.WebXmlConfiguration.configure
(WebXmlConfiguration.java:222)
at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:
69)
at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:
52)
at com.google.gwt.dev.DevMode.doSlowStartup(DevMode.java:332)
at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:953)
at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:690)
at com.google.gwt.dev.DevMode.main(DevMode.java:251)
Previously we never used to get this error with the old style dev
plugin and GWT 1.7.
Now - if I completely remove the <login-config> section from web.xml I
don't get this error at startup and I can go to the sample application
on its url (which will be something like
http://localhost:8888/SecurityTest.html?gwt.codesvr=192.168.0.107:9997).
As soon as I hit this the browser pops up a std internal
authentication dialog saying 'The server localhost:8888 at
SecurityTestRealm requires a username and password'. The application
will now only let me through if I supply the credentials specified in
the realm.properties file so this proves that:
* The JeTTY realm injection is working a treat.
* The BASIC authentication part of J2EE is working.
But for some reason it doesn't like the <login-config> section at
all. I even tried switching out the login.jsp page for standard
static html pages for login and error just in case it was something to
do with JeTTY not compiling the .jsp files into servlets or some
aspect of the jsp engine had been turned off but that didn't work
either.
Does anyone have any ideas about what could have changed within the
GWT 2.0 Eclipse plugin to break Form-based J2EE authentication ? or is
it simply a case that I've gotten something wrong and not spotted it ?
For now I can probably make do with BASIC authentication from the
browser itself and I'll try the test application .war file against a
tomcat container later on today to see if its only the plugin that
struggles with login-config.
The concern I have is that if it doesn't support the other types of
J2EE authentication it will make it quite difficult when its running
in a normal app server, not to mention with the <login-config> section
gone there is also no way to direct login to a specific security
realm.
Any advice or thoughts you may have would be greatly appreciated.
Regards
Ian.G
Ian.G
When I reported this problem yesterday I was working on my Macbook
(OSX 10.6.2, Java 1.6, Eclipse 3.5, GWT 2.0 - Developer plugins for
both Firefox and Safari).
Today I'm back in the office to I figured I'd try it on a Windows
environment (Windows XP, Java 1.6, Eclipse 3.5, GWT 2.0, Developer
plugins for Chrome and Firefox).
Unfortunately I'm getting the same problem :(
The next thing I did is take a peep at the JeTTY source code where the
exception is occuring when the developer plugin fires up. You can see
the WebXmlConfiguration source code here on the codehaus website.
http://jetty.codehaus.org/jetty/jetty-6/xref/org/mortbay/jetty/webapp/WebXmlConfiguration.html#860
So if you take a look at the lines where the Exception is being thrown
Jetty has just read the <realm-name> element from the web.xml. The
next thing it does is enumerate all the realms that have been wired
into JeTTY to find the one specified in the web app config. So after
its checked the UserRealm[] for the one we've specified realm is still
null and hence we get the "[WARN] Unknown realm" message.
So the next thing I did is to try and increase the logging level of
the GWT plugin so we can see what else it does when it starts up. So
I now specify:
-logLevel DEBUG
in the program argumets to increase logging.
The strange thing here is that if I do this the security realm works
correctly (even though the configuration errors appear in the log
output). I attempt to log in with invalid users and I see lines like
[WARN] AUTH FAILURE: user <user-name>
appearing in the console.
If I log in with a valid username I get re-directed to the main
application html file.
If I then remove the -logLevel DEBUG from the startup parameters it
continues to work fine.
Not sure what happened there but may serve as a useful reference if
somebody else gets the problem in the future. If things start to fail
again I will report back my findings.
Regards
Ian.
lemaiol
It seems that the Jetty version could have changed and also its API.
Try with this little change in the syntax of the configuration (we
guessed it looking at the jetty classes API and it worked for us):
cheers,
Alberto
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
"http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Get name="SecurityHandler">
<Set name="UserRealm">
<New class="org.mortbay.jetty.security.HashUserRealm">
<Set name="name">MyRealm</Set>
<Set name="config">WEB-INF/dev_realm.properties</Set>
</New>
</Set>
</Get>
</Configure>
> on its url (which will be something likehttp://localhost:8888/SecurityTest.html?gwt.codesvr=192.168.0.107:9997).
Ian.G
thanks for taking the time to reply.
I've changed the wireup of the realm in jetty-web.xml so it more
closely matches what you have (i.e instead of doing <Call
name="setUserRealm"> we now do a <Set name="UserRealm">). So our
jetty-web.xml now looks like this:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
"http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Get name="SecurityHandler">
<Set name="UserRealm">
<New class="org.mortbay.jetty.security.HashUserRealm">
<Set name="name">SecurityTestRealm</Set>
<Set name="config"><SystemProperty name="jetty.home"
default="."/>/WEB-INF/etc/realm.properties</Set>
</New>
</Set>
</Get>
</Configure>
We still get the same errors as I originally reported. I think the
way we inject the Realm into the JeTTY SecurityHandler is still almost
the same - just slightly different XML notation for doing the set.
The Realm does in fact work and when we hit the GWT start page for the
app it does in fact re-direct to the login page as you would expect as
stated in my previous response.
I guess for now the errors that come out can be treated as noise
because the realm does in fact work - its just the [WARN] Unknown
realm: SecurityTestRealm message that goes to the console implies that
it wouldn't.
The next thing I have to do now is re-build my Filter that intercepts
login re-directs when the client-side JavaScript makes an RPC call and
the session has expired. I unfortuately lost this class as I hadn't
dropped it into our svn repo before I rebuilt my entire eclipse
environment (doh!). Its not too bad so I should have that back again
soon.
I hope I can get to the point where I can document what I think is
probably the most straight forward way of getting J2EE container
managed security and sessions working with GWT. There are lots of
chunks of useful information about this out there - but there isn't a
single source of information that pulls it all together with a full
working example for people to study. Maybe I will try and do this.
Regards
Ian.
> ...
>
> read more »
Ian.G
need to put this functionality back together so I can serialize
specific types of Exception that can can catch in my onFailure
method. We have an AsyncCallback handler that will hook failed
requests (for all our RPC services) in one place - so we can manage
the loss of session in one place.
So our App has the following paths in the web app
/SecurityTest.html - this is the main GWT page
/SecurityTest.css - our apps CSS Stylesheet
/Login.jsp - the J2EE FORM-based authentication page
/securitytest/* - all the servlets that implement our GWT RPC server-
side functionality.
In terms of our security-constraint section we require an
authenticated user to access
/SecurityTest.html
/SecurityTest.css
/securitytest/* (Where the GWT services are)
so everything is in place - we hit the entry point of the app - we get
sent to the login page, we authenticate and then the containter
managed security sends us back to the referring start page we came
from. All this is good and its just back to managing the loss of
session from client-side JavaScript RPC calls
To begin with I had <filter-mapping> entries for every resource that
could be hit bar the login page, e.g.
<filter-mapping>
<filter-name>ApplicationRequestFilter</filter-name>
<url-pattern>/SecurityTest.html</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ApplicationRequestFilter</filter-name>
<url-pattern>/SecurityTest.css</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ApplicationRequestFilter</filter-name>
<url-pattern>/securitytest/*</url-pattern>
</filter-mapping>
What I need to figure out is for our Filter that checks the session
state and if there is no session returns a Serialized Exception which
paths it should be working on. I can't recall now if the filter was
watching /* or /securitytest/*
Does anyone have a working Filter that does this ? would also be
interested to see if your filter mapping is for /* or just for the /
services/* part or your app.
Regards
Ian.
> ...
>
> read more »
lemaiol
Sorry, I missed something in your previous post and the problem I
solved was a little different but in our case was masking the second
one you describe here. I can confirm that we also have the same
behaviour so I would suggest creating an issue.
Cheers,
Alberto
> ...
>
> read more »
Ian.G
thanks for getting back on this.
We have our app secured again now - but I'm far from happy with the
approach I've taken right now. As I couldn't decide on appropriate
paths to watch with the filter I've removed it and gone with the dirty
hack approach of just mining information out of the
InvocationException that comes in the onFailure call on our
AsyncCallback class.
I check a very specific meta tag thats in the login page and if its
present I know this is as a result of the session being invalidated by
the container and the client end of the rpc call has the login page
instead of the response from the service.
This is because I couldn't easily tell in my filter that we'd ended up
at the login page for a valid reason (i.e. the user is trying to
access the app for the first time and needs to authenticate) or
because of a session timeout and them needing to re-authenticate.
We don't actually use the HTTP Session for anything - its purely there
as a means to using the security part of J2EE to restrict access to
our app.
It all gets a bit messy really. So if getMessage() from the
InvocationException can be proven that it contains my login page
source I give the user a message on the screen and cause the main page
of the app to reload by doing
Window.Location.reload();
Obviously because there is no session the app server redirects them to
the login page first so they can authenticate and then goes back to
the main page.
Its not pefect but it will do for now. I'm not prepared to have the
client end of the application performing some sort of timed ping
against the server just to keep the session alive (you may as go with
a session timeout of -1 if thats your approach - it serves the same
perpose without writing any code), or trying to anticipate session
loss by using some sort of countdown timer on the client. I don't
believe those kinds of solutions are good ones (especially when
thinking about client machine hibernation or network disconnection
etc). If our application used spring at the back end we could
consider using the acegi security stuff - but it doesn't so I'n not
prepared to introduce an entire framework just for this.
I'll try and get some time to raise the realm injection errors as an
issue as you have proven this isn't just specific to me - its probably
down to how the GWT plugin creates the JeTTY instance that is now
leading to these errors. I'm pretty sure 1,7 and 2.0 versions of GWT
both used the JeTTY 6.x libs.
Thanks again
Ian.
> ...
>
> read more »
Jon
absolute path to the realm.properties file.
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
"http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Get name="SecurityHandler">
<Set name="UserRealm">
<New class="org.mortbay.jetty.security.HashUserRealm">
<Set name="name">file</Set>
<Set name="config">C:\gwt-2.0.0\realm.properties</Set>
</New>
</Set>
</Get>
</Configure>
> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -