Login page

[Jordan Shweky]

I am building a GWT app that requires user authentication via a login page, plus constant validation any time a user request is made to the server.

I built an HTML login page that included a button that linked to the GWT app's html file, and set the login page as the welcome page in the web.xml file.  That worked, except converting the username/password into a Java object for authentication purposes was giving me problems.  

I am currently trying to build the entire login page with GWT widgets (leaving the HTML page behind entirely), but now redirecting from a login.java clas to the GWT app itself (via the app's HTML page) via a button is similarly giving me fits.

I have Googled this issue and found a bunch of pages, but with inconsistent methodology.  The most common page people have mentioned is this one: https://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ but I find that page to be less helpful than others apparently do.  Any assistance getting this login page functional would be greatly appreciated.

[Thomas Broyer]

Use the servlet container's authentication support with <security-constraint> in your WEB-INF/web.xml. For AJAX requests, don't use a <security-constraint> but rather use a servlet filter that returns a predefined response that the client knows how to deal with (I like returning a 401 Unauthorized status code –without WWW-Authenticate header–).

You can see an example (also using RequestFactory, Guice/GIN and Activities/Places, but it should be rather easy to isolate the login-related things) in the "guice-rf-activities" archetype in https://github.com/tbroyer/gwt-maven-archetypes

[Pascal Heus]

Jordan:
I would recommend integrating with Spring Security, either by using gwtsecurity (https://code.google.com/p/gwtsecurity/) or writing your own implementation.
Hope this helps.
best
*P

--
You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-mojo-gwt-maven-...@googlegroups.com.
To post to this group, send email to codehaus-mojo-gwt-...@googlegroups.com.
Visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users.
For more options, visit https://groups.google.com/d/optout.

[David Hoffer]

I too am very interested in Jordan's question and have found documentation on this subject to be lacking.  I really like the concept in Thomas's reply as it separates security concerns from the application logic (if I understand it correctly).  I'm wondering if there is some detailed documentation on on this approach?  In addition, in my case I need to use OpenID to authenticate the user so then would I need to install an OpenID authenticator in my container (which is Tomcat)?  Also I need features like the ability to restrict the user to one concurrent session (kill prior one), session timeout, etc.  Does this approach provide features like this?  Also I'm assuming with this approach I would have no need for Spring AOP type security on the server's exposed methods?  Again sure would like to see some docs of a how to implement this for GWT apps and what features it supports.

Jordan, did you find a solution?

-Dave   

[David Hoffer]

I created a sample guice-rf-activities project, this looks really interesting but brings up a few more questions.

1. Can this approach be used for GWT RPC instead of RequestFactory?  (My application makes extensive RPC calls.)  I assume so but I haven't used RequestFactory.

2. What is the significance of the custom annotations, CurrentUser, IsAdmin, LogoutUrl, etc?  

-Dave

[Thomas Broyer]

On Thursday, February 12, 2015 at 4:10:25 AM UTC+1, David Hoffer wrote:

I created a sample guice-rf-activities project, this looks really interesting but brings up a few more questions.

1. Can this approach be used for GWT RPC instead of RequestFactory?  (My application makes extensive RPC calls.)  I assume so but I haven't used RequestFactory.

Yes; you'd have to handle the StatusCodeException in each and every AsyncCallback on the client side though (or alternatively use a custom RpcRequestBuilder, once per GWT.create() on a RemoteService interface)

 

2. What is the significance of the custom annotations, CurrentUser, IsAdmin, LogoutUrl, etc?

They're specific to dependency injection (javax.inject, JSR330; as implemented here by Guice and GIN). An injected "@CurrentUser String" will the current user's name whereas "@LogoutUrl String" is the logout URL (see configurations in ServletContextListener and GinModule); without those annotations, you would be unable to inject those "String"s (or at least meaningfully). "@CurrentUser User" (rather than just "User") is for consistency with "@CurrentUser String" and to give meaning to the injected value (it's not just "some user", it's the "current user").

[David Hoffer]

I had originally mentioned that we want to use OpenID to authenticate the user, I now see that OpenID (v2) has fallen out of favor and is replaced with vendor specific authentication, e.g. Google, Facebook, etc.  For our purposes we were only going to support Google anyway so now that would be Google+ Sign-In or the OpenID Connect protocol that it is based on instead of OpenID v2.

So my questions are still the same but the protocols have changed.

1. Using the container authentication approach does that work with OpenID Connect/Google+, etc.  Does Tomcat support this?  If not, others?

2. Is this the right way to incorporate security in a GWT app?  

3. Or should I incorporate OpenID Connect support directly in my app?

4. If using the container approach, can I get some of the features I need, such as:

4a. Single user session (terminate prior sessions).

4b. User inactivity timeouts.

From the context of GWT I would really like to see some overall documentation on the various approaches to solving these issues, either from the container approach point of view or any other such as Spring security.

-Dave 

On Wednesday, December 31, 2014 at 11:29:46 AM UTC-7, Jordan Shweky wrote: