-
1. Re: Design strategy for Authorization and Seam Remoting
shane.bryzak Oct 14, 2010 11:10 AM (in response to bartmatthaei)Hmm that's quite an interesting problem, and unfortunately I don't have an easy answer for you. The issue I see is that authorization is not a static thing... who's to say that a failed authorization check for a particular operation won't work the second time? User privileges might have been modified in the meantime, not to mention that some permissions might be temporal based (i.e. grant the user X permission if the current time is between 1pm and 2pm). There is simply no way for a client to determine whether a user has authorization to invoke a particular operation without checking with the server.
That all said though, it should be possible to at least read the user's role memberships and use that information to disable certain UI elements. It won't be the full authorization
spectrum
but at least it gives you some control. We actually do this a fair bit in JSF for some of the Seam examples - you'll see expressions like s:hasRole('admin') inside the rendered attribute for certain tags. I don't see why you couldn't do something similar to this, all you need is to return a list of the user's role memberships to the page and store them somewhere. Then you simply use the contents of this list to decide whether to render certain elements.