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-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.
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="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 <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="name">MyRealm</Set>
> > <Set name="config">WEB-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="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
>
> ...
>
> read more »
--
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.
