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!
For now, I am not sure if I understood you right. In addition I am
thinking about a "dummy user" to let guests come into my application,
but I am not sure if this is a solution.
What do you think about this?
Magnus
On 1 Sep., 00:13, Thomas Broyer <t.bro...@gmail.com> wrote:
> On 31 août, 19:34, Magnus <alpineblas...@googlemail.com> wrote:
>
> > Hi folks,
>
> > is it the common opinion for GWT apps to have a separate login page?
> > (Thomas, your "cache" example seems a bit artificial to me (although I
> > believe that you know why you recommend a separate login page).)
>
> Having built 2 apps that way, and having to remember to handle those
> login/logout events to "reset" the views, I can assure you it's not
> "artificial", but lot of boilerplate code I could have just avoided
> writing. I also spent way too much time (IMO) to get the login process
> working (have to use a base AsyncCallback/RequestCallback that handles
> authentication errors to show the login screen –RequestFactory will
> fortunately makes this waaay easier–; and what to do once you log back
> in? replay the request? the reason we went for an "integrated login"
> UX was our client asking for sessions to expire, and we didn't want
> the user to lose its unsaved work, so the login screen in this case is
> showed "above" the screen, with the username field switched to
> readonly; if you do not have a need for such a thing, then I you could
> probably live with an "externalized login"; I'm now trying to make
> clients change their mind about session expiration, and/or adopting a
> different approach with auto-saves into server-side "working copies",
> or live with their users losing work if they don't hit "save" soon
> enough though without automatically redirecting them to the login
> screen, similar to how "web 1.0" applications generally work –
> directing you to the login screen only when you hit the server, i.e.
> only between page loads–)
>
> > Could someone please provide an example for a separate login page? I
> > wonder if this should be realized as a servlet or a jsp or something
> > like that, how control is passed to the app and how the app finds out
> > that the user is logged in...
>
> To force authentication, my approach is to just have the "host html
> page" a protected resource (configure security in the web.xml to
> require a valid, authenticated user; letting the servlet container
> handling authentication, using JASPIC/JSR-196 or the container's own
> APIs when you need/want customization).
> For the app to know the user's details, the host html page is a JSP,
> rendering a <script> block defining a JavaScript variable with the
> needed info,and using JSNI or just Dictionnary to getthe info from the
> GWT app (do a view-source on GMail or any AJAX Google App, you'll see
> that they're doing similar things), but an RPC request at onModuleLoad
> could do it too (though a bit less performant).
>
> I can't give you code/config sample offhand, but there's nothing
> really special about it. The only missing thing is to detect session
> expirations from your RPC calls but you already were doing this,
> right?
> (as I said, RequestFactory makes this easier –dispatching an event on
> the eventbus– so if you can wait GWT 2.1, use RequestFactory!)
--
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