I would not do any such role-based things on client, it's very easy to spoof http packets and a normal user can get access to Admin UI...
Just be careful with that... If you have solid way to avoid any such security issues, go ahead. -abdul On Jan 28, 2008 8:49 PM, Paul Andrews <[EMAIL PROTECTED]> wrote: > An interesting idea. > > I haven't got time to experiment, but here are some thoughts. > > There's two approacheas as I see it - 'outside in', or 'inside'. > > 'inside' would mean adding a call to a security object inside the custom > object to inspect the security parameters and 'detach' any components nested > inside the custom component. > > 'outside-in' would be similar to the 'inside' approach but with one call > at the application level, which investigates all children for the security > settings of each component and recursively descends into components if they > satisfy the security settings and 'detach' those that don't. > > It's not as easy as simply building a html page on the fly, because you > can't completely detach components. For example, your application might have > a login component sitting on the layout and for arguments sake there's a > 'save' component that will appear after login if the user has the right > security settings. So initially, with no user logged in, the save button > can't appear, but cannot be permamently removed either. Once the user has > logged in we need to make the button appear if the security settings are > right. Similarly when the user logs out, it goes again. Unlike an html page > which is refreshed, an instance of a Flex component may remain throughout > the life of the application. It's not possible to 'lose' these optional > components completely - hence the 'detach'. You can partially get what you > want by making these custom component invisible and taking them out of the > layout, but potentially there's another problem perhaps - what if a custom > component is doing some processing and not just sitting on the layout? > > Whenever the security status changes it will be necessary to trigger a new > traversal of the application component tree to decide which components are > visible or not. > > The Flex traditional way to do this kind of thing would be using states. > Your security-aware components could implement the correct states to adjust > to the security settings just by switching states - this would probably give > you what you want with the security component updating states rather than > directly manipulating components. > > Hope that helps. > > Paul > ----- Original Message ----- > > *From:* cool.king08 <[EMAIL PROTECTED]> > *To:* [email protected] > *Sent:* Sunday, January 27, 2008 5:04 PM > *Subject:* [flexcoders] Role based rendoring of MXML components - > visibility and editability > > Hi > I need some help regarding role based access control mechanism at the view > level i.e on flex components. > > My requirement is simple - I have flex page which has many controls like > buttons, combox, textinput etc. The users who access the page are grouped by > roles. I want limit access to components in the page. For example the 'Save' > button should be VISIBLE to a user with role 'ADMIN'. Another use case is a > combobox components should only be EDITABLE by a user with role 'ADMIN or > SUPER'. This could be more advanced; for example instead of controlling just > one component, we could control a block of MXML code like: > > *<custom:Authorize visible="ADMIN|SUPER" editable="SOMEUSER"> > <mx:Button name="Save" /> > <mx:Combobox name="Users" /> > </custom:Authorize>* > > (ofcourse visible attribute takes priority over editable attribute). Again > the features of such a robust view layer security can be limitless. For > example the above code just shows UI Controls. It could have a mix of layout > components, custom UI components, and UI Controls. It could also support > wildcards like | (or), & (and), !(not). This is a common requirement in > intranet applications where there are many different types of business users > demarcated by roles. This type of components also reduces code duplication. > For example a flex page can be shown in VIEW_ONLY mode as well as EDIT mode > based on the user role instead of writing two different flex pages. > > My mid tier has J2EE with spring + acegi. Acegi has a cool JSP tag library > <authz:authorize>which does a similar thing - > > *<authz:authorize ifAllGranted="ROLE_VIP, ROLE_GUEST">* > * Welcome USER* > * <a href="...">Logoff</a>* > *</authz:authorize>* > > I know flex doesnt have any such out-of-the-box component/functionality. > Is there anything out there which does something similar? I have some ideas > of how this can be implemented but if you can give some ideas it will always > help. > Thanks > > > -- -abdul --------------------------------------- http://abdulqabiz.com/blog/ ---------------------------------------
