Hi all, this is a quite interesting discussion. So far I've gone this way (and any suggestion will be appreciated):
1) let user authenticate through an external login page; 2) retrieve user profile and store it in client; 3) write authorization code in views for "what user can see" and in activities for "what user can do". Authorization can be done in check-points (like you do in places mapping/filtering) or in a pervasive way. In other terms in places or in views/activities. Back to Jeff's original question I will reload the app when user gets authenticated. It should be possible to forward unauthenticated user status by mean of place parameters (passed back in return link by login page) / cookies / server session. I'll think the app as a non- profiled part and a profiled part. In non-profiled part there are normal activities/views, in profiled part there are augmented activities/view they can show different content, based on user profile, and forward user to a login page. Cheers, Luca On 5 Giu, 20:57, Jeff Schnitzer <[email protected]> wrote: > On Sun, Jun 5, 2011 at 2:34 AM, Thomas Broyer <[email protected]> wrote: > > > Or maybe you could have a single place and have the ActivityMappers (or > > whatever PlaceChangeHandler if you're not using Activities) react > > differently whether the user is authenticated or not. > > Originally I did have a single default Place, but the caching of > places made this problematic. Ie, when you log in, you "go to" the > same place and nothing happens. A. Stevko's suggestion of just firing > the PlaceChangeEvent myself is the > "doh-I-can't-believe-I-didn't-think-of-that" solution to this problem > (thanks A!) > > > Authentication is (should be) orthogonal to navigation. When the user > > authenticates, you should dispatch a LoginEvent (or similar) on the event > > bus and have the activities (or whatever) refresh their content ("restart"). > > This just doesn't work in my application. When the user logs in, the > *entire* app gets torn down and rebuilt using a different set of Gin > "singletons" and a totally different navigation structure. Basically, > when I get a LoginEvent, I need to simulate the user having gone > directly to the new URL in a fresh application. > > Reloading the browser page would be tempting but I have too much state > that needs to carry across. Also, it's ugly. > > I think the LoginEvent approach makes sense in an app that you can > reasonably navigate in both auth and nonauth states. In this kind of > app, yeah, authenticating just makes some widgets redraw their > content. But I don't think I can get away with that. I do have a > LoginEvent, but it's essentially caught by my master module object, > and has to do a warm restart of the app. I'm guessing this is a > common pattern, and Places makes it difficult. > > Jeff -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
