smartweb-devel

[smartweb-devel] [smartweb-auth] How to customize application gui by user's role

[Gaetano P. <gpe...@sm...>]

Actually if we would visualize a button for the users in a "myRole" role on
the application gui we must add a tag <auth:valid role="myRole"  > .
This means that the business rules about user permission lie around the jsp
source code, So if i would change the role permission strategy i must, in
the worst case look around  all the jsp page.
I think we could have the same approch used for the domain methods
authentication (AOP) for determining if a button, a textfield, a label must
be visualized. 
I have detected 2 approchs:

1. Add to the project an  <auth:valid funtion="myFunction"  > . This
approch has the loss of needing the coding in all the authorized code
blocks.

2. Override struts html tags <html:button id="myFunction" ...
<html:text id="myFunction" etc...

waiting for your feedback
-- 
View this message in context: http://www.nabble.com/-smartweb-auth--How-to-customize-application-gui-by-user%27s-role-tp14876789s17546p14876789.html
Sent from the SmartWeb Developers mailing list archive at Nabble.com.

Re: [smartweb-devel] [smartweb-auth] How to customize application gui by user's role

[Pino C. <gco...@gm...>]

Hi,
first of all , I completly agree with your request . We need to associate a
user 'function' to a role in a configuration file (xml format for best). It
was great your first solution proposed .
I propose an alternative scenario :
always in a gui it was wonder to write :
<auth valid : roles="myRoles1,myRoles2,.." > as a function to permitt
different cuncurrency roles .
or another solution <auth valid : groupId="devel" > were devel is a group of
distincts roles associate to a user . 
Waiting for reply..


Gaetano Perrone wrote:
> 
> Actually if we would visualize a button for the users in a "myRole" role
> on the application gui we must add a tag &lt;auth:valid role="myRole" 
> &gt; . This means that the business rules about user permission lie around
> the jsp source code, So if i would change the role permission strategy i
> must, in the worst case look around  all the jsp page.
> I think we could have the same approch used for the domain methods
> authentication (AOP) for determining if a button, a textfield, a label
> must be visualized. 
> I have detected 2 approchs:
> 
> 1. Add to the project an  &lt;auth:valid funtion="myFunction"  &gt; . This
> approch has the loss of needing the coding in all the authorized code
> blocks.
> 
> 2. Override struts html tags &lt;html:button id="myFunction" ...
> &lt;html:text id="myFunction" etc...
> 
> waiting for your feedback
> 

-- 
View this message in context: http://www.nabble.com/-smartweb-auth--How-to-customize-application-gui-by-user%27s-role-tp14876789s17546p14877928.html
Sent from the SmartWeb Developers mailing list archive at Nabble.com.

Re: [smartweb-devel] [smartweb-auth] How to customize application gui by user's role

[Gaetano P. <gpe...@sm...>]

I think u don't understand the solution i propose.
The xml configuration file that associates user's role to function yet
exists and was introduced with AOP domain methods authentication.
The solution u propose ( <auth:valid role="role1" ) also exists yet but
what i would avoid to specify the role in the jsp page parametrizing it by
function name and configured (xml & AOP) role-function association. The
advantage as i said in the previous post is that changing the role's
function associate impacts only at configuration time and we must'nt need
rediting N jsp pages source code
:-)


Pino Contartese wrote:
> 
> Hi,
> first of all , I completly agree with your request . We need to associate
> a user 'function' to a role in a configuration file (xml format for best).
> It was great your first solution proposed .
> I propose an alternative scenario :
> always in a gui it was wonder to write :
> <auth valid : roles="myRoles1,myRoles2,.." > as a function to permitt
> different cuncurrency roles .
> or another solution <auth valid : groupId="devel" > were devel is a group
> of distincts roles associate to a user . 
> Waiting for reply..
> 
> 
> Gaetano Perrone wrote:
>> 
>> Actually if we would visualize a button for the users in a "myRole" role
>> on the application gui we must add a tag &lt;auth:valid role="myRole" 
>> &gt; . This means that the business rules about user permission lie
>> around the jsp source code, So if i would change the role permission
>> strategy i must, in the worst case look around  all the jsp page.
>> I think we could have the same approch used for the domain methods
>> authentication (AOP) for determining if a button, a textfield, a label
>> must be visualized. 
>> I have detected 2 approchs:
>> 
>> 1. Add to the project an  &lt;auth:valid funtion="myFunction"  &gt; .
>> This approch has the loss of needing the coding in all the authorized
>> code blocks.
>> 
>> 2. Override struts html tags &lt;html:button id="myFunction" ...
>> &lt;html:text id="myFunction" etc...
>> 
>> waiting for your feedback
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-smartweb-auth--How-to-customize-application-gui-by-user%27s-role-tp14876789s17546p14896449.html
Sent from the SmartWeb Developers mailing list archive at Nabble.com.

Re: [smartweb-devel] [smartweb-auth] How to customize application gui by user's role

[Roberto Lo G. <rlo...@us...>]

I've a proposal which delivers your request to it's maximum flexibility:
point-cut the Tag interface to allow constraints on a tag level basis.

In brief what I suggest is to use AOP to intercept calls to any JSP tag and
verify if a constraint exists on that tag: if the constraint is not verified
that tag is not executed at all and all it's contents are skipped.

Here follows an example JSP fragment from the registry module:

<html:form action="/registry/entry-save">
  <html:hidden property="id"/><html:hidden property="version"/>
  <bean:message key="entry.header.edit" bundle="registry"/>
      <bean:message key="entry.display" bundle="registry"/><html:text
property="display" size="30"/>
    <html:button titleKey="operation.remove.title" property="remove"
disabled="true"><bean:message key="operation.remove"/></html:button>
    <html:cancel titleKey="operation.cancel.title"><bean:message
key="operation.cancel"/></html:cancel>
    <html:submit titleKey="operation.complete.title"><bean:message
key="operation.complete"/></html:submit>
</html:form>

Using AOP we can control the GUI field by field, tag by tag on a per role
basis, like in the following security.xml example:

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="security.xsd">
		.
		.
		.
	<roles>
		<role id="user">
			<description>Registered visitor</description>
			<privilege resource="entry-edit.jsp" element="*" modifier="rwx"/>
			<privilege resource="entry-edit.jsp" element="remove" modifier="r"/>
		</role>
	</roles>
</security>

The meaningful parts are the last two privileges of the "user" role:
- the first privilege allows the user to view, edit and execute every
element on the JSP
- the last privilege allows the user to only view the element marked
"remove" on the JSP

If you look back at the JSP the "remove" element in the JSP is a button and
the read-only permission says something like "show the button but make it
not executable" so the button should be displayed but in a disabled status.

The argument to this approach can be:
- it may be too flexible
- it may be hard to understand
- it may be difficult to implement

We are already investigating the last point but we appreciate your opinions
on the first two.


Gaetano Perrone wrote:
> 
> I think u don't understand the solution i propose.
> The xml configuration file that associates user's role to function yet
> exists and was introduced with AOP domain methods authentication.
> The solution u propose ( &lt;auth:valid role="role1" ) also exists yet but
> what i would avoid to specify the role in the jsp page parametrizing it by
> function name and configured (xml & AOP) role-function association. The
> advantage as i said in the previous post is that changing the role's
> function associate impacts only at configuration time and we must'nt need
> rediting N jsp pages source code
> :-)
> 

-- 
View this message in context: http://www.nabble.com/-smartweb-auth--How-to-customize-application-gui-by-user%27s-role-tp14876789s17546p15017447.html
Sent from the SmartWeb Developers mailing list archive at Nabble.com.

Re: [smartweb-devel] [smartweb-auth] How to customize application gui by user's role

[Roberto Lo G. <rlo...@us...>]

I've heard nothing about this feature in the last weeks... Stefano, are you
reading our posts? What are your intentions about this feature request?


Roberto Lo Giacco wrote:
> 
> I've a proposal which delivers your request to it's maximum flexibility:
> point-cut the Tag interface to allow constraints on a tag level basis.
> 
> In brief what I suggest is to use AOP to intercept calls to any JSP tag
> and verify if a constraint exists on that tag: if the constraint is not
> verified that tag is not executed at all and all it's contents are
> skipped.
> 
> Here follows an example JSP fragment from the registry module:
> 
> <html:form action="/registry/entry-save">
>   <html:hidden property="id"/><html:hidden property="version"/>
>   <bean:message key="entry.header.edit" bundle="registry"/>
>       <bean:message key="entry.display" bundle="registry"/><html:text
> property="display" size="30"/>
>     <html:button titleKey="operation.remove.title" property="remove"
> disabled="true"><bean:message key="operation.remove"/></html:button>
>     <html:cancel titleKey="operation.cancel.title"><bean:message
> key="operation.cancel"/></html:cancel>
>     <html:submit titleKey="operation.complete.title"><bean:message
> key="operation.complete"/></html:submit>
> </html:form>
> 
> Using AOP we can control the GUI field by field, tag by tag on a per role
> basis, like in the following security.xml example:
> 
> <security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:noNamespaceSchemaLocation="security.xsd">
> 		.
> 		.
> 		.
> 	<roles>
> 		<role id="user">
> 			<description>Registered visitor</description>
> 			<privilege resource="entry-edit.jsp" element="*" modifier="rwx"/>
> 			<privilege resource="entry-edit.jsp" element="remove" modifier="r"/>
> 		</role>
> 	</roles>
> </security>
> 
> The meaningful parts are the last two privileges of the "user" role:
> - the first privilege allows the user to view, edit and execute every
> element on the JSP
> - the last privilege allows the user to only view the element marked
> "remove" on the JSP
> 
> If you look back at the JSP the "remove" element in the JSP is a button
> and the read-only permission says something like "show the button but make
> it not executable" so the button should be displayed but in a disabled
> status.
> 
> The argument to this approach can be:
> - it may be too flexible
> - it may be hard to understand
> - it may be difficult to implement
> 
> We are already investigating the last point but we appreciate your
> opinions on the first two.
> 
> 
> Gaetano Perrone wrote:
>> 
>> I think u don't understand the solution i propose.
>> The xml configuration file that associates user's role to function yet
>> exists and was introduced with AOP domain methods authentication.
>> The solution u propose ( &lt;auth:valid role="role1" ) also exists yet
>> but what i would avoid to specify the role in the jsp page parametrizing
>> it by function name and configured (xml & AOP) role-function association.
>> The advantage as i said in the previous post is that changing the role's
>> function associate impacts only at configuration time and we must'nt need
>> rediting N jsp pages source code
>> :-)
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-smartweb-auth--How-to-customize-application-gui-by-user%27s-role-tp14876789s17546p15733752.html
Sent from the SmartWeb Developers mailing list archive at Nabble.com.

Re: [smartweb-devel] [smartweb-auth] How to customize application gui by user's role

[Roberto Lo G. <rlo...@us...>]

Actually the <auth:valid> tag supports the definition of a comma-separated
roles list in the "role" attribute. This means you can ALREADY write
something like

<auth:valid role="role1,role2,role3">

About the "grouping" feature I wish to highlight something: a group is a
collection of users and cannot contain roles... those are two distinct
business elements which we want to maintain as separated as possible.

It's an important distinction I wish to underline for convenience wherever
is possible, nothing personal.
 

Pino Contartese wrote:
> 
> Hi,
> first of all , I completly agree with your request . We need to associate
> a user 'function' to a role in a configuration file (xml format for best).
> It was great your first solution proposed .
> I propose an alternative scenario :
> always in a gui it was wonder to write :
> <auth valid : roles="myRoles1,myRoles2,.." > as a function to permitt
> different cuncurrency roles .
> or another solution <auth valid : groupId="devel" > were devel is a group
> of distincts roles associate to a user . 
> Waiting for reply..
> 
> 
> Gaetano Perrone wrote:
>> 
>> Actually if we would visualize a button for the users in a "myRole" role
>> on the application gui we must add a tag &lt;auth:valid role="myRole" 
>> &gt; . This means that the business rules about user permission lie
>> around the jsp source code, So if i would change the role permission
>> strategy i must, in the worst case look around  all the jsp page.
>> I think we could have the same approch used for the domain methods
>> authentication (AOP) for determining if a button, a textfield, a label
>> must be visualized. 
>> I have detected 2 approchs:
>> 
>> 1. Add to the project an  &lt;auth:valid funtion="myFunction"  &gt; .
>> This approch has the loss of needing the coding in all the authorized
>> code blocks.
>> 
>> 2. Override struts html tags &lt;html:button id="myFunction" ...
>> &lt;html:text id="myFunction" etc...
>> 
>> waiting for your feedback
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-smartweb-auth--How-to-customize-application-gui-by-user%27s-role-tp14876789s17546p15017501.html
Sent from the SmartWeb Developers mailing list archive at Nabble.com.