Hi Thomas, I have thought about this the whole day now and it really sounds interesting to me to give it a try with external login, but - if I understood you right - I see a big disatvantage:
Many applications are not or should not be usable at all when the user is not logged in. But there are also applications that should be usable (in a limited way) without login. Consider eBay: You can search and browse as nobody, but if you want to sell, you have to sign in. Or consider a chess application: You can watch everything, but if you want to create a new game, you have to sign in first. Consider a forum: You can read a lot, but not everything, but after you login, you can read everything and also write. So my problem is that with your method I had to lock out all guest users that just want to come and see what is going on there! For now, I am not sure if I understood you right. In addition I am thinking about a "dummy user" to let guests come into my application, but I am not sure if this is a solution. What do you think about this? Magnus On 1 Sep., 00:13, Thomas Broyer <t.bro...@gmail.com> wrote: > On 31 août, 19:34, Magnus <alpineblas...@googlemail.com> wrote: > > > Hi folks, > > > is it the common opinion for GWT apps to have a separate login page? > > (Thomas, your "cache" example seems a bit artificial to me (although I > > believe that you know why you recommend a separate login page).) > > Having built 2 apps that way, and having to remember to handle those > login/logout events to "reset" the views, I can assure you it's not > "artificial", but lot of boilerplate code I could have just avoided > writing. I also spent way too much time (IMO) to get the login process > working (have to use a base AsyncCallback/RequestCallback that handles > authentication errors to show the login screen –RequestFactory will > fortunately makes this waaay easier–; and what to do once you log back > in? replay the request? the reason we went for an "integrated login" > UX was our client asking for sessions to expire, and we didn't want > the user to lose its unsaved work, so the login screen in this case is > showed "above" the screen, with the username field switched to > readonly; if you do not have a need for such a thing, then I you could > probably live with an "externalized login"; I'm now trying to make > clients change their mind about session expiration, and/or adopting a > different approach with auto-saves into server-side "working copies", > or live with their users losing work if they don't hit "save" soon > enough though without automatically redirecting them to the login > screen, similar to how "web 1.0" applications generally work – > directing you to the login screen only when you hit the server, i.e. > only between page loads–) > > > Could someone please provide an example for a separate login page? I > > wonder if this should be realized as a servlet or a jsp or something > > like that, how control is passed to the app and how the app finds out > > that the user is logged in... > > To force authentication, my approach is to just have the "host html > page" a protected resource (configure security in the web.xml to > require a valid, authenticated user; letting the servlet container > handling authentication, using JASPIC/JSR-196 or the container's own > APIs when you need/want customization). > For the app to know the user's details, the host html page is a JSP, > rendering a <script> block defining a JavaScript variable with the > needed info,and using JSNI or just Dictionnary to getthe info from the > GWT app (do a view-source on GMail or any AJAX Google App, you'll see > that they're doing similar things), but an RPC request at onModuleLoad > could do it too (though a bit less performant). > > I can't give you code/config sample offhand, but there's nothing > really special about it. The only missing thing is to detect session > expirations from your RPC calls but you already were doing this, > right? > (as I said, RequestFactory makes this easier –dispatching an event on > the eventbus– so if you can wait GWT 2.1, use RequestFactory!) -- 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.