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="name">file</Set> <Set name="config">C:\gwt-2.0.0\realm.properties</Set> </New> </Set> </Get> </Configure> On Jan 13, 8:20 am, "Ian.G" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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="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. > > > > On Jan 8, 9:47 am, lemaiol <[email protected]> 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="name">MyRealm</Set> > > > > <Set name="config">WEB-INF/dev_realm.properties</Set> > > > > </New> > > > > </Set> > > > > </Get> > > > > </Configure> > > > > > On Jan 6, 3:32 pm, "Ian.G" <[email protected]> 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="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 > > ... > > read more »- Hide quoted text - > > - Show quoted text -
-- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
