Hello Magnus, That's called "Breaking out of frames" [1]. If you need your app to be able to detect a valid login, then you'll need to communicate from within the iframe to the hosting app that the login was ok (have a look at window.name transport in this case [2])
[1] http://www.blooberry.com/indexdot/html/topics/breakframe.htm [2] http://development.lombardi.com/?p=611 On Sep 6, 3:00 pm, Magnus <alpineblas...@googlemail.com> wrote: > Thomas, > > I was too quick when saying that it works with iframes: The login page > was shown correctly and the browser offered autofill, but > FormPanel.wrap caused an exception which I could not get away (i think > a JS exception). > > Then I tried a combination of both - external login and visual GWT > integration: > > I made an external JSP page for the log, totally outside of GWT, but I > loaded this JSP page into an iframe so that it showed up within my GWT > app. > > The only problem is, when I submit the login form inside the iframe, > the login page redirects to my app inside the iframe. So the app > appears inside the iframe. > > Isn't there a way to do the following: > If the login form within the iframe is submitted, reload the app > outside the iframe. > > Magnus > > On 3 Sep., 19:00, Magnus <alpineblas...@googlemail.com> wrote: > > > 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.