Why don't you just use JAAS? You could then protect your GWT page in web.xml, and then instruct your app server to "redirect" to login page if the user is not logged in. You can also setup custom roles and permissions - the code is largely copy/paste and rest of the stuff is declarative in your web.xml.
Just do a google search on JAAS + your application server, you'll get detailed notes on how to setup. --Sri On 6 May 2010 22:33, markww <[email protected]> wrote: > Thanks for the heads up, was just going down that route. > > I'm fine with using a regular html form, just not sure where to put > it. Twitter has a login form on their main splash page, which is > ideal. I am thinking I could do the same. My main page is already a > jsp page. I can do something like: > > // myproject.jsp > <form action="myproject.jsp"> > ... login text fields ... > </form> > > <% > String login = request.getParameter("login"); > String password = request.getParameter("password"); > if (login and password exist and are correct) { > startSession(); > showProtectedUserInfoEtc(); > } > else { > showGeneralInfo(); > } > %> > > this could work, the form just re-posts itself back to my main project > page. The downside is that I have to add the login logic on the main > page which is kind of ugly, but I think this will work correctly? > > Thank you > > > On May 6, 9:30 am, Sripathi Krishnan <[email protected]> > wrote: > > +1 on that - if you can, don't make the same mistake! > > > > We also put in some hacks to get the login page "GWT controlled". In > > retrospect, it was a poor decision. Its much cleaner to assume that the > GWT > > page is only reachable once authenticated. > > > > --Sri > > P.S. And as luck would have it, as I typed this email, my gmail session > > timed out. I got a popup - "Your session has timedout". So, I was able to > > copy the draft, login again and then continue on this email. Not too bad > for > > usability, I didn't loose my work. > > > > On 6 May 2010 21:19, Thomas Broyer <[email protected]> wrote: > > > > > > > > > > > > > > > > > On May 6, 4:45 pm, markww <[email protected]> wrote: > > > > Actually, just confirming this, all the solutions presented here *do > > > > not* work in webkit browsers (chrome, safari), right? Looks like it > > > > works in firefox ok. I haven't found any alternative solutions in my > > > > searches, so seems like our options are still: > > > > > > 1) Use methods presented here, but won't work in chrome or safari > > > > 2) Use standard login submit form (outside of gwt, but will work on > > > > all browsers) > > > > > I'm using GWT-controlled auth (i.e. without "exiting" the app when > > > logging out) for more than 2 years now (initially sending the form to > > > the server, then using the above solution) and I must say that... > > > > > if you can, don't make the same mistake! > > > > > For all my new projects, I'm using a separate page for the login > > > screen adn the GWT app (which can safely assume it is authenticated), > > > just like Google does. Yes it means you could loose your work when > > > your session expires but it makes the development sooo much easier! > > > In our app where we still do this, the session automatically ends > > > after 30' of inactivity (calculated only based on requests to the > > > server, or rather, responses from the server). You're then showed the > > > login screen but you cannot change the username, your only option is > > > to give your password (much like a "session locked" screen, as in MS > > > Windows), or refresh the page. All your work is kept behind though, so > > > when you "unlock" the app, you didn't loose anything. Only when the > > > user explicitly logs out the login screen is shown with the ability to > > > log back in as any user (and switch locale, which reloads the page > > > with the appropriate GWT locale selected), and only in this case the > > > whole app (except the login screen) is blown out, and cached data is > > > cleared. This is really a PITA to maintain as there's always a risk > > > you forget clearing something out. > > > So let me reiterate: > > > > > if you can, don't make the same mistake! > > > > > -- > > > 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]<google-web-toolkit%[email protected]><google-web-toolkit%2Bunsubs > [email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > > -- > > 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]<google-web-toolkit%[email protected]> > . > > For more options, visit this group athttp:// > groups.google.com/group/google-web-toolkit?hl=en. > > -- > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- 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.
