Re: Problem: certain types of J2EE authentication with GWT 2.0 and Eclipse 3.5 plugin no longer work
I had a very similar problem, I ended up fixing it by setting an 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=namefile/Set Set name=configC:\gwt-2.0.0\realm.properties/Set /New /Set /Get /Configure On Jan 13, 8:20 am, Ian.G iandgrat...@googlemail.com wrote: Hi Alberto, 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. On Jan 13, 11:06 am, lemaiol lema...@gmail.com wrote: Hi Ian, 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 On Jan 8, 12:08 pm, Ian.G iandgrat...@googlemail.com wrote: Hi Alberto, 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=nameSecurityTestRealm/Set Set name=configSystemProperty 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
Re: Problem: certain types of J2EE authentication with GWT 2.0 and Eclipse 3.5 plugin no longer work
Hi Ian, 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 On Jan 8, 12:08 pm, Ian.G iandgrat...@googlemail.com wrote: Hi Alberto, 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=nameSecurityTestRealm/Set Set name=configSystemProperty 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. On Jan 8, 9:47 am, lemaiol lema...@gmail.com wrote: Hi Ian, 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=nameMyRealm/Set Set name=configWEB-INF/dev_realm.properties/Set /New /Set /Get /Configure On Jan 6, 3:32 pm, Ian.G iandgrat...@googlemail.com wrote: 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
Re: Problem: certain types of J2EE authentication with GWT 2.0 and Eclipse 3.5 plugin no longer work
Hi Alberto, 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. On Jan 13, 11:06 am, lemaiol lema...@gmail.com wrote: Hi Ian, 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 On Jan 8, 12:08 pm, Ian.G iandgrat...@googlemail.com wrote: Hi Alberto, 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=nameSecurityTestRealm/Set Set name=configSystemProperty 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
Re: Problem: certain types of J2EE authentication with GWT 2.0 and Eclipse 3.5 plugin no longer work
Hi Ian, 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=nameMyRealm/Set Set name=configWEB-INF/dev_realm.properties/Set /New /Set /Get /Configure On Jan 6, 3:32 pm, Ian.G iandgrat...@googlemail.com wrote: 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=nameSecurityTestRealm/Set Set name=configSystemProperty name=jetty.home default=.//WEB-INF/etc/realm.properties/Set Set name=RefreshInterval5/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 descriptionA sample GWT Application that makes use of J2EE security and sessions/description !-- Servlets -- servlet servlet-namegreetServlet/servlet-name servlet- classuk.co.somecompany.securitytest.server.GreetingServiceImpl/ servlet-class /servlet servlet-mapping servlet-namegreetServlet/servlet-name url-pattern/securitytest/greet/url-pattern /servlet-mapping !--Session Management -- session-config session-timeout10/session-timeout /session-config !-- Default page to serve -- welcome-file-list welcome-fileSecurityTest.html/welcome-file /welcome-file-list !-- Application Security -- security-constraint
Re: Problem: certain types of J2EE authentication with GWT 2.0 and Eclipse 3.5 plugin no longer work
Hi Alberto, 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=nameSecurityTestRealm/Set Set name=configSystemProperty 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. On Jan 8, 9:47 am, lemaiol lema...@gmail.com wrote: Hi Ian, 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=nameMyRealm/Set Set name=configWEB-INF/dev_realm.properties/Set /New /Set /Get /Configure On Jan 6, 3:32 pm, Ian.G iandgrat...@googlemail.com wrote: 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
Re: Problem: certain types of J2EE authentication with GWT 2.0 and Eclipse 3.5 plugin no longer work
Unfortunately no longer having my Filter code is holding me back. I 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-nameApplicationRequestFilter/filter-name url-pattern/SecurityTest.html/url-pattern /filter-mapping filter-mapping filter-nameApplicationRequestFilter/filter-name url-pattern/SecurityTest.css/url-pattern /filter-mapping filter-mapping filter-nameApplicationRequestFilter/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. On Jan 8, 11:08 am, Ian.G iandgrat...@googlemail.com wrote: Hi Alberto, 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=nameSecurityTestRealm/Set Set name=configSystemProperty 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. On Jan 8, 9:47 am, lemaiol lema...@gmail.com wrote: Hi Ian, 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
Re: Problem: certain types of J2EE authentication with GWT 2.0 and Eclipse 3.5 plugin no longer work
Hi Folks, 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. -- 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.
Problem: certain types of J2EE authentication with GWT 2.0 and Eclipse 3.5 plugin no longer work
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=nameSecurityTestRealm/Set Set name=configSystemProperty name=jetty.home default=.//WEB-INF/etc/realm.properties/Set Set name=RefreshInterval5/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 descriptionA sample GWT Application that makes use of J2EE security and sessions/description !-- Servlets -- servlet servlet-namegreetServlet/servlet-name servlet- classuk.co.somecompany.securitytest.server.GreetingServiceImpl/ servlet-class /servlet servlet-mapping servlet-namegreetServlet/servlet-name url-pattern/securitytest/greet/url-pattern /servlet-mapping !--Session Management -- session-config session-timeout10/session-timeout /session-config !-- Default page to serve -- welcome-file-list welcome-fileSecurityTest.html/welcome-file /welcome-file-list !-- Application Security -- security-constraint display-nameSecurity/display-name web-resource-collection web-resource-nameSecurity/web-resource-name descriptionThis 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-nametestrole/role-name /auth-constraint /security-constraint !-- This application uses FORM authentication -- login-config auth-methodFORM/auth-method realm-nameSecurityTestRealm/realm-name form-login-config
