Hi Folks - my first post on the discussion group so big thanks to 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
-- 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-tool...@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.
