I think you can pretty much solve the problems related with performance in runAsync() calls. So in the initial package have only the minimum code for showing an empty page and the login, and after a successful login start getting the data needed. That will also fix (I think) problems related with security. No authenticated user can see the content of your page.
In the second article I read this: > Form-based Authentication > Before I show you how to implement form-based authentication, you > should be aware that Google does not recommend this. Below is a > warning from their LoginSecurityFAQ. > >Do NOT attempt to use the Cookie header to transfer the sessionID > >from GWT to the server; it is fraught with security issues that will > >become clear in the rest of this article. You MUST transfer the > >sessionID in the payload of the request. For an example of why this > >can fail, see CrossSiteRequestForgery. Is kind of closing the loop (having a bit more knowledge in another technology, always grateful) But with the same set of questions. So the idea is that I always should send this session id. And then having the server check for it. Maybe relegating the job to a framework like spring security. But no one saves me from sending the id. thx On Jun 17, 9:25 am, Frederic Conrotte <[email protected]> wrote: > >I didn't want the user to wait for the GWT app to load because he could see > >the login screen > > Correction: I didn't want the user to wait for the GWT app to load > BEFORE he could see the login screen. > > Sorry :) > > On Jun 17, 9:17 am, Frederic Conrotte <[email protected]> > wrote: > > > > > In our case I didn't want the user to wait for the GWT app to load > > because he could see the login screen. > > > Furthermore, you should take care at securing both HTML request URLs > > and RPC requests URLs. > > > On Jun 17, 9:06 am, Kasper Hansen <[email protected]> wrote: > > > > Just curious; why do You recommend a classic HTML form, Frederic ? > > > > Cheers. > > > > :-) Kasper > > > > On Thu, Jun 17, 2010 at 8:25 AM, Frederic Conrotte > > > > <[email protected]> wrote: > > > > GWT and Spring Security work perfectly together. > > > > > See this as a starter point: > > > >http://www.jroller.com/sjivan/entry/ajax_based_login_using_aceci > > > >http://java.dzone.com/articles/integrating-gwt-spring > > > > > I advise you to use a classic HTML form for login, not a GWT based > > > > login dialog. > > > > > On Jun 17, 7:19 am, fmod <[email protected]> wrote: > > > >> Hi, I need to re-implement the classic login page. And I'm a bit lost > > > >> with all the alternatives. The communication with the server is with > > > >> RPC. Until now the flow I was using was: > > > >> - User enters login and pass [client sends them in plain text to the > > > >> server] > > > >> - Server validates and generate a session id (String generated with > > > >> UUID) [server replies that]. > > > >> - On every request the client sends session id. (all the functions in > > > >> the rpc have sessionId) > > > >> - The server was keeping track of this session id and after 30 mins > > > >> without being used it removed it as valid session. > > > > >> This was working quite well, but it was a bit annoying to have this > > > >> sessionId all the time. Reading some posts, seems that is a bad idea > > > >> sending the session id all the time (at least as I understood). That I > > > >> can rely on the 'classical session' mechanism. So somehow the server > > > >> remembers the client after he logs in the first time. > > > > >> Here is my dilemma. This 'classical session' carried by the server > > > >> seems to disagree with the 'new Ajax-era' where the server carries no > > > >> status of the client. > > > > >> I think I'm totally messing concepts here. What is the correct way of > > > >> doing it? Is there some good explaining how to do it, maybe an example > > > >> will be great. > > > > >> Thank you in advance. > > > > > -- > > > > 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.
