I have a question from a slightly different angle: Is there a common way / design strategy to show/hide or enable/disable gwt widgets based on a predefined role/access rights. i.e. if a user with role 'admin' is acessing the application an admin button is visible, which is not visible in the case a user with role 'guest' is accessing the page?
Thanks in advance, Steve L. On Aug 21, 2:02 pm, Phineas Gage <[email protected]> wrote: > On Aug 20, 4:46 pm, Laird Nelson <[email protected]> wrote: > > > > > On Thu, Aug 20, 2009 at 9:39 AM, Zé Vicente > > <[email protected]>wrote: > > > > I would say that all you need to do is to use runAsync() to saparate > > > Adm features from regular features and then make sure that on server > > > side you check for each operation, if the user has the good credential > > > to execute it. > > > Bear in mind that unless I've misread the documentation runAsync() will not > > always split the code where you have asked it to split it. > > > I think the original poster still has a valid point; I'd be curious to see > > what the GWT guys have to say about this (very, very common) use case. How > > does one separate admin code from normal user code in a GWT application? > > > Obviously the ultimate answer is to make sure that the server side > > functionality is protected by an authentication mechanism, so that no matter > > what you can't run an admin function unless you are authenticated as an > > admin. But it seems like there should be a way beyond runAsync() to > > reliably segment application code that is downloaded to the browser. > > Right...consider this use case: You have tworoles, one for manager > and one for employee. You wouldn't want the employee downloading the > manager's part of the application as well. In there might be sensitive > information revealing management policy/procedure, structure or other > things that are not intended to be viewed by employees. > > And in general, even though RPC methods will be protected from being > called, it's better if users can't look at the client stubs for > sensitive methods to learn about what parameters are passed and what's > returned, as that might inadvertently reveal internal info about how > the system works, which might be used in other attacks. > > regards, > Phineas --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
