Re: problems with auto-complete form login

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.