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-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment