Also think of this...when you create your views, use the Flex invalidation
framework to your advantage. Basically allow every view to receive your user
object and then decide what to show/hide, example:
<!-- ProductView.mxml -->
<mx:Box>
<mx:Script>
private var _user:User;
...
public function set user( u:User ):void {
this._user = u;
invalidateProperties();
}
...
override proetcted function commitProperties():void {
// show/hide parts of the UI based on the user roles
}
</mx:Script>
... rest of view form here ...
</mx:Box>
The view declaration in your main app would be as such:
<bla:ProductView user="{ theUser }"/>
Dimitrios Gianninas
RIA Developer and Team Lead
Optimal Payments Inc.
________________________________
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of
cool.king08
Sent: Monday, January 28, 2008 2:26 PM
To: [email protected]
Subject: [flexcoders] Re: Role based rendoring of MXML components - visibility
and editability
Dimitrios
Fantastic solution! Though it limits to only one component rather
than a block, this technique will work for my current requirement. I
had the same solution but I was thinking of implementing a more
advanced custom flex component which would work like:
<custom:Authorize visible="ADMIN|SUPER" editable="SOMEUSER">
<mx:Button name="Save" />
<mx:Combobox name="Users" />
</custom:Authorize>
But, I think it will be very complicated. So I will for now employ
your technique. I think some were confused between authentication and
authorization. The requirement I initially mentioned was
authorization. Every flex request can be authenticated on the server
side.
Thanks
--- In [email protected] <mailto:flexcoders%40yahoogroups.com> ,
"Dimitrios
Gianninas" <[EMAIL PROTECTED]> wrote:
>
> Here is my take:
>
> 1) roles should define an action that can be peformed, example:
CREATEACCOUNT, ADDACCOUNT, SEARCHACCOUNT, etc... If you want to
group users, do that from an administration point of view, the
application itself should know only about the individual roles. This
provides the greatest flexibility. (we do J2EE here as well)
>
> 2) Your AS User class, should have a method called hasRole() or
isUserInRole(), use this to bind to your various UI components to
either show or hide them, example:
>
> <mx:Button label="Save"
> visible="{user.hasRole( Constants.SAVEACCOUNT )}"
> includeInLayout="{user.hasRole( Constants.SAVEACCOUNT )}"/>
>
> Dimitrios Gianninas
> RIA Developer and Team Lead
> Optimal Payments Inc.
>
>
> ________________________________
>
> From: [email protected] <mailto:flexcoders%40yahoogroups.com>
[mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> ] On
Behalf Of cool.king08
> Sent: Sunday, January 27, 2008 12:04 PM
> To: [email protected] <mailto:flexcoders%40yahoogroups.com>
> 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
>
>
>
> --
> WARNING
> -------
> This electronic message and its attachments may contain
confidential, proprietary or legally privileged information, which
is solely for the use of the intended recipient. No privilege or
other rights are waived by any unintended transmission or
unauthorized retransmission of this message. If you are not the
intended recipient of this message, or if you have received it in
error, you should immediately stop reading this message and delete
it and all attachments from your system. The reading, distribution,
copying or other use of this message or its attachments by
unintended recipients is unauthorized and may be unlawful. If you
have received this e-mail in error, please notify the sender.
>
> AVIS IMPORTANT
> --------------
> Ce message électronique et ses pièces jointes peuvent contenir des
renseignements confidentiels, exclusifs ou légalement privilégiés
destinés au seul usage du destinataire visé. L'expéditeur original
ne renonce à aucun privilège ou à aucun autre droit si le présent
message a été transmis involontairement ou s'il est retransmis sans
son autorisation. Si vous n'êtes pas le destinataire visé du
présent message ou si vous l'avez reçu par erreur, veuillez cesser
immédiatement de le lire et le supprimer, ainsi que toutes ses
pièces jointes, de votre système. La lecture, la distribution, la
copie ou tout autre usage du présent message ou de ses pièces
jointes par des personnes autres que le destinataire visé ne sont
pas autorisés et pourraient être illégaux. Si vous avez reçu ce
courrier électronique par erreur, veuillez en aviser l'expéditeur.
>
