Hmmm...I would like to get my peace with this, but... I now created an invisible iframe in my host html. On login I just show it, so it's a native html form. It's not so nice as a DialogBox, but it works.
I cannot see why this is bad. Why is it bad? You see, I cannot let it go... :-) Magnus On Sep 2, 3:47 am, Thomas Broyer <t.bro...@gmail.com> wrote: > On Sep 1, 3:42 pm, Magnus <alpineblas...@googlemail.com> wrote: > > > > > 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! > > Not necessarily. > The setup I described about web.xml, etc. would make it behave as you > describe, but that's just one way to do "externalized login", and a > way that doesn't make "guest access" possible (to make things simpler > and keeping the advantages of container-managed login using servlet > FORM or JASPIC, you could just use 2 "host pages": a world-accessible > one and a restricted one, possible using redirections and so on to > make it "work as intended" in every corner case, I haven't tested; I > bet you'll find plenty of examples on the Web about doing guest and > authenticated access on the same resource in Java servlet/JSP) > > In every of the 3 cases you cite, I don't see a problem in reloading > the app when switching from unauthenticated to authenticated access > (if you want to keep some information around –such as your shopping > cart–, send it as part of the login process –or store it on the server > and pass some ID around–). YMMV of course (and I didn't say > "externalize login" is a silver bullet, you might really want/need > some UX that would make it impossible to use). > > One possibility too is to only allow a guest-to-authenticated-user > workflow without reloading the app ("integrated login"). As soon as > the user wants to sign out, then reload the app and start back in > "guest mode". That way, you don't have to fear about restricted data > "leaking" between user sessions, but you'd still have to make sure to > clear some client-side caches (depending on your use case; for the > forum case you gave, for instance, clear the list of posts so you'll > reload them from the server and see the "restricted posts"). -- 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.