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