I should point out that it still works great in IE and Firefox. Just not Chrome.
On Tuesday, 3 July 2012 17:07:44 UTC+10, Craig Mitchell wrote: > > The submitting to a javascript URL was working great. However, Chrome has > decided to stop working (currently on version 20.0.1132.47 m). > > And the only thing that seems to make it work, is doing a submit straight > to the servlet from the login form, which is a real pain (and a major > change). > > Anyone else notice that Chrome has stopped working for auto complete? > > > On Friday, 7 May 2010 03:24:31 UTC+10, Sri wrote: >> >> 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%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]. >>> > 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]. >>> 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. >> > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/3u30EV9LVw4J. 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.
