Discussion: Permissions Checking Enhancement
Locked
123
123
Discussion: Permissions Checking Enhancement
 
|
In the screen widgets, you can check permissions with the
<if-has-permission> or <if-service-permission> elements. That's fine if you only need to check a single permission to control access to the entire screen. Things get complicated when a screen's elements are controlled by more than one permission. Let's say you have a typical Edit Item screen. The screen should be viewable only to users who have the VIEW permission. Users who have the UPDATE permission can edit the item. Users who have the CREATE permission see a "New Item" button. Users who have DELETE permission see a "Delete Item" button. Users who have the ADMIN permission have unrestricted access to the screen. Wow. Five permission elements (and five service calls) are needed to control one screen. Here's my idea: have a permission service that returns ALL of the user's permissions in a Map. You call the service with the permission to check - "ACCOUNTING" for example. The service returns a Map containing all of the user's ACCOUNTING permissions stored as Boolean objects. Let's say the returned Map is called permissionsMap and the user has ACCOUNTING_VIEW and ACCOUNTING_UPDATE permissions, then the Map would contain these elements: CREATE=false UPDATE=true DELETE=false VIEW=true ADMIN=false If the service call is put in the screen's <actions> element, then the Map elements could be used to control the display of screen widget sections, menu items, and form fields. Freemarker code would be simpler too: <#if permissionsMap.CREATE> <!-- Render a Create New button --> </#if> <#if permissionsMap.DELETE> <!-- Render a Delete button --> </#if> What do you think? -Adrian |
Re: Discussion: Permissions Checking Enhancement
|
|
Wonderfull !!!!
Looking forward to having it !!! ;-) This will let me also define a more granular permissions to simplify the interface for not-so-skilled users. -Bruno 2008/6/4 Adrian Crum <[hidden email]>: > In the screen widgets, you can check permissions with the > <if-has-permission> or <if-service-permission> elements. That's fine if you > only need to check a single permission to control access to the entire > screen. > > Things get complicated when a screen's elements are controlled by more than > one permission. Let's say you have a typical Edit Item screen. The screen > should be viewable only to users who have the VIEW permission. Users who > have the UPDATE permission can edit the item. Users who have the CREATE > permission see a "New Item" button. Users who have DELETE permission see a > "Delete Item" button. Users who have the ADMIN permission have unrestricted > access to the screen. Wow. Five permission elements (and five service calls) > are needed to control one screen. > > > Here's my idea: have a permission service that returns ALL of the user's > permissions in a Map. You call the service with the permission to check - > "ACCOUNTING" for example. The service returns a Map containing all of the > user's ACCOUNTING permissions stored as Boolean objects. Let's say the > returned Map is called permissionsMap and the user has ACCOUNTING_VIEW and > ACCOUNTING_UPDATE permissions, then the Map would contain these elements: > > CREATE=false > UPDATE=true > DELETE=false > VIEW=true > ADMIN=false > > If the service call is put in the screen's <actions> element, then the Map > elements could be used to control the display of screen widget sections, > menu items, and form fields. > > Freemarker code would be simpler too: > > <#if permissionsMap.CREATE> > <!-- Render a Create New button --> > </#if> > <#if permissionsMap.DELETE> > <!-- Render a Delete button --> > </#if> > > What do you think? > > -Adrian > |
Re: Discussion: Permissions Checking Enhancement
Administrator
|
Yes this sounds good to me too
Jacques From: "Bruno Busco" <[hidden email]> > Wonderfull !!!! > Looking forward to having it !!! ;-) > This will let me also define a more granular permissions to simplify the > interface for not-so-skilled users. > > -Bruno > > 2008/6/4 Adrian Crum <[hidden email]>: > >> In the screen widgets, you can check permissions with the >> <if-has-permission> or <if-service-permission> elements. That's fine if you >> only need to check a single permission to control access to the entire >> screen. >> >> Things get complicated when a screen's elements are controlled by more than >> one permission. Let's say you have a typical Edit Item screen. The screen >> should be viewable only to users who have the VIEW permission. Users who >> have the UPDATE permission can edit the item. Users who have the CREATE >> permission see a "New Item" button. Users who have DELETE permission see a >> "Delete Item" button. Users who have the ADMIN permission have unrestricted >> access to the screen. Wow. Five permission elements (and five service calls) >> are needed to control one screen. >> >> >> Here's my idea: have a permission service that returns ALL of the user's >> permissions in a Map. You call the service with the permission to check - >> "ACCOUNTING" for example. The service returns a Map containing all of the >> user's ACCOUNTING permissions stored as Boolean objects. Let's say the >> returned Map is called permissionsMap and the user has ACCOUNTING_VIEW and >> ACCOUNTING_UPDATE permissions, then the Map would contain these elements: >> >> CREATE=false >> UPDATE=true >> DELETE=false >> VIEW=true >> ADMIN=false >> >> If the service call is put in the screen's <actions> element, then the Map >> elements could be used to control the display of screen widget sections, >> menu items, and form fields. >> >> Freemarker code would be simpler too: >> >> <#if permissionsMap.CREATE> >> <!-- Render a Create New button --> >> </#if> >> <#if permissionsMap.DELETE> >> <!-- Render a Delete button --> >> </#if> >> >> What do you think? >> >> -Adrian >> > |
Re: Discussion: Permissions Checking Enhancement
|
|
+1
-- Sumit Pandit On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: > Yes this sounds good to me too > > Jacques > > From: "Bruno Busco" <[hidden email]> >> Wonderfull !!!! >> Looking forward to having it !!! ;-) >> This will let me also define a more granular permissions to >> simplify the >> interface for not-so-skilled users. >> -Bruno >> 2008/6/4 Adrian Crum <[hidden email]>: >>> In the screen widgets, you can check permissions with the >>> <if-has-permission> or <if-service-permission> elements. That's >>> fine if you >>> only need to check a single permission to control access to the >>> entire >>> screen. >>> >>> Things get complicated when a screen's elements are controlled by >>> more than >>> one permission. Let's say you have a typical Edit Item screen. The >>> screen >>> should be viewable only to users who have the VIEW permission. >>> Users who >>> have the UPDATE permission can edit the item. Users who have the >>> CREATE >>> permission see a "New Item" button. Users who have DELETE >>> permission see a >>> "Delete Item" button. Users who have the ADMIN permission have >>> unrestricted >>> access to the screen. Wow. Five permission elements (and five >>> service calls) >>> are needed to control one screen. >>> >>> >>> Here's my idea: have a permission service that returns ALL of the >>> user's >>> permissions in a Map. You call the service with the permission to >>> check - >>> "ACCOUNTING" for example. The service returns a Map containing all >>> of the >>> user's ACCOUNTING permissions stored as Boolean objects. Let's say >>> the >>> returned Map is called permissionsMap and the user has >>> ACCOUNTING_VIEW and >>> ACCOUNTING_UPDATE permissions, then the Map would contain these >>> elements: >>> >>> CREATE=false >>> UPDATE=true >>> DELETE=false >>> VIEW=true >>> ADMIN=false >>> >>> If the service call is put in the screen's <actions> element, then >>> the Map >>> elements could be used to control the display of screen widget >>> sections, >>> menu items, and form fields. >>> >>> Freemarker code would be simpler too: >>> >>> <#if permissionsMap.CREATE> >>> <!-- Render a Create New button --> >>> </#if> >>> <#if permissionsMap.DELETE> >>> <!-- Render a Delete button --> >>> </#if> >>> >>> What do you think? >>> >>> -Adrian >>> >> |
Re: Discussion: Permissions Checking Enhancement
|
|
+1
Adrian I liked your idea. On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit <[hidden email]> wrote: > +1 > -- > Sumit Pandit > > > On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: > > Yes this sounds good to me too >> >> Jacques >> >> From: "Bruno Busco" <[hidden email]> >> >>> Wonderfull !!!! >>> Looking forward to having it !!! ;-) >>> This will let me also define a more granular permissions to simplify the >>> interface for not-so-skilled users. >>> -Bruno >>> 2008/6/4 Adrian Crum <[hidden email]>: >>> >>>> In the screen widgets, you can check permissions with the >>>> <if-has-permission> or <if-service-permission> elements. That's fine if >>>> you >>>> only need to check a single permission to control access to the entire >>>> screen. >>>> >>>> Things get complicated when a screen's elements are controlled by more >>>> than >>>> one permission. Let's say you have a typical Edit Item screen. The >>>> screen >>>> should be viewable only to users who have the VIEW permission. Users who >>>> have the UPDATE permission can edit the item. Users who have the CREATE >>>> permission see a "New Item" button. Users who have DELETE permission see >>>> a >>>> "Delete Item" button. Users who have the ADMIN permission have >>>> unrestricted >>>> access to the screen. Wow. Five permission elements (and five service >>>> calls) >>>> are needed to control one screen. >>>> >>>> >>>> Here's my idea: have a permission service that returns ALL of the user's >>>> permissions in a Map. You call the service with the permission to check >>>> - >>>> "ACCOUNTING" for example. The service returns a Map containing all of >>>> the >>>> user's ACCOUNTING permissions stored as Boolean objects. Let's say the >>>> returned Map is called permissionsMap and the user has ACCOUNTING_VIEW >>>> and >>>> ACCOUNTING_UPDATE permissions, then the Map would contain these >>>> elements: >>>> >>>> CREATE=false >>>> UPDATE=true >>>> DELETE=false >>>> VIEW=true >>>> ADMIN=false >>>> >>>> If the service call is put in the screen's <actions> element, then the >>>> Map >>>> elements could be used to control the display of screen widget sections, >>>> menu items, and form fields. >>>> >>>> Freemarker code would be simpler too: >>>> >>>> <#if permissionsMap.CREATE> >>>> <!-- Render a Create New button --> >>>> </#if> >>>> <#if permissionsMap.DELETE> >>>> <!-- Render a Delete button --> >>>> </#if> >>>> >>>> What do you think? >>>> >>>> -Adrian >>>> >>>> >>> > |
Re: Discussion: Permissions Checking Enhancement
|
|
I'll work on it this weekend.
-Adrian Ashish Vijaywargiya wrote: > +1 > Adrian I liked your idea. > > On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit <[hidden email]> > wrote: > >> +1 >> -- >> Sumit Pandit >> >> >> On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: >> >> Yes this sounds good to me too >>> Jacques >>> >>> From: "Bruno Busco" <[hidden email]> >>> >>>> Wonderfull !!!! >>>> Looking forward to having it !!! ;-) >>>> This will let me also define a more granular permissions to simplify the >>>> interface for not-so-skilled users. >>>> -Bruno >>>> 2008/6/4 Adrian Crum <[hidden email]>: >>>> >>>>> In the screen widgets, you can check permissions with the >>>>> <if-has-permission> or <if-service-permission> elements. That's fine if >>>>> you >>>>> only need to check a single permission to control access to the entire >>>>> screen. >>>>> >>>>> Things get complicated when a screen's elements are controlled by more >>>>> than >>>>> one permission. Let's say you have a typical Edit Item screen. The >>>>> screen >>>>> should be viewable only to users who have the VIEW permission. Users who >>>>> have the UPDATE permission can edit the item. Users who have the CREATE >>>>> permission see a "New Item" button. Users who have DELETE permission see >>>>> a >>>>> "Delete Item" button. Users who have the ADMIN permission have >>>>> unrestricted >>>>> access to the screen. Wow. Five permission elements (and five service >>>>> calls) >>>>> are needed to control one screen. >>>>> >>>>> >>>>> Here's my idea: have a permission service that returns ALL of the user's >>>>> permissions in a Map. You call the service with the permission to check >>>>> - >>>>> "ACCOUNTING" for example. The service returns a Map containing all of >>>>> the >>>>> user's ACCOUNTING permissions stored as Boolean objects. Let's say the >>>>> returned Map is called permissionsMap and the user has ACCOUNTING_VIEW >>>>> and >>>>> ACCOUNTING_UPDATE permissions, then the Map would contain these >>>>> elements: >>>>> >>>>> CREATE=false >>>>> UPDATE=true >>>>> DELETE=false >>>>> VIEW=true >>>>> ADMIN=false >>>>> >>>>> If the service call is put in the screen's <actions> element, then the >>>>> Map >>>>> elements could be used to control the display of screen widget sections, >>>>> menu items, and form fields. >>>>> >>>>> Freemarker code would be simpler too: >>>>> >>>>> <#if permissionsMap.CREATE> >>>>> <!-- Render a Create New button --> >>>>> </#if> >>>>> <#if permissionsMap.DELETE> >>>>> <!-- Render a Delete button --> >>>>> </#if> >>>>> >>>>> What do you think? >>>>> >>>>> -Adrian >>>>> >>>>> > |
Re: Discussion: Permissions Checking Enhancement
|
|
Adrian,
may be a newbie question but... ...in the example you give what will happen if a user has the ADMIN permission but not the CREATE one? Will the Create New button be rendered? In other words who is responsible for the permission hierarchy ? In order to display the CREATE button, should a user be given with the CREATE permission explicitly or the ADMIN is sufficient? Thank you -Bruno 2008/6/6 Adrian Crum <[hidden email]>: > I'll work on it this weekend. > > -Adrian > > > Ashish Vijaywargiya wrote: > >> +1 >> Adrian I liked your idea. >> >> On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit < >> [hidden email]> >> wrote: >> >> +1 >>> -- >>> Sumit Pandit >>> >>> >>> On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: >>> >>> Yes this sounds good to me too >>> >>>> Jacques >>>> >>>> From: "Bruno Busco" <[hidden email]> >>>> >>>> Wonderfull !!!! >>>>> Looking forward to having it !!! ;-) >>>>> This will let me also define a more granular permissions to simplify >>>>> the >>>>> interface for not-so-skilled users. >>>>> -Bruno >>>>> 2008/6/4 Adrian Crum <[hidden email]>: >>>>> >>>>> In the screen widgets, you can check permissions with the >>>>>> <if-has-permission> or <if-service-permission> elements. That's fine >>>>>> if >>>>>> you >>>>>> only need to check a single permission to control access to the entire >>>>>> screen. >>>>>> >>>>>> Things get complicated when a screen's elements are controlled by more >>>>>> than >>>>>> one permission. Let's say you have a typical Edit Item screen. The >>>>>> screen >>>>>> should be viewable only to users who have the VIEW permission. Users >>>>>> who >>>>>> have the UPDATE permission can edit the item. Users who have the >>>>>> CREATE >>>>>> permission see a "New Item" button. Users who have DELETE permission >>>>>> see >>>>>> a >>>>>> "Delete Item" button. Users who have the ADMIN permission have >>>>>> unrestricted >>>>>> access to the screen. Wow. Five permission elements (and five service >>>>>> calls) >>>>>> are needed to control one screen. >>>>>> >>>>>> >>>>>> Here's my idea: have a permission service that returns ALL of the >>>>>> user's >>>>>> permissions in a Map. You call the service with the permission to >>>>>> check >>>>>> - >>>>>> "ACCOUNTING" for example. The service returns a Map containing all of >>>>>> the >>>>>> user's ACCOUNTING permissions stored as Boolean objects. Let's say the >>>>>> returned Map is called permissionsMap and the user has ACCOUNTING_VIEW >>>>>> and >>>>>> ACCOUNTING_UPDATE permissions, then the Map would contain these >>>>>> elements: >>>>>> >>>>>> CREATE=false >>>>>> UPDATE=true >>>>>> DELETE=false >>>>>> VIEW=true >>>>>> ADMIN=false >>>>>> >>>>>> If the service call is put in the screen's <actions> element, then the >>>>>> Map >>>>>> elements could be used to control the display of screen widget >>>>>> sections, >>>>>> menu items, and form fields. >>>>>> >>>>>> Freemarker code would be simpler too: >>>>>> >>>>>> <#if permissionsMap.CREATE> >>>>>> <!-- Render a Create New button --> >>>>>> </#if> >>>>>> <#if permissionsMap.DELETE> >>>>>> <!-- Render a Delete button --> >>>>>> </#if> >>>>>> >>>>>> What do you think? >>>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> >> |
Re: Discussion: Permissions Checking Enhancement
|
|
The pattern used so far is that the ADMIN permission is checked first,
then the other permissions. So if a user has the ADMIN permission, they don't need the additional permissions. I'll probably have all of the permissions Map elements set to true if the user has the ADMIN permission. -Adrian Bruno Busco wrote: > Adrian, > may be a newbie question but... > ...in the example you give what will happen if a user has the ADMIN > permission but not the CREATE one? > Will the Create New button be rendered? > > In other words who is responsible for the permission hierarchy ? > In order to display the CREATE button, should a user be given with the > CREATE permission explicitly or the ADMIN is sufficient? > > Thank you > -Bruno > > > > 2008/6/6 Adrian Crum <[hidden email]>: > >> I'll work on it this weekend. >> >> -Adrian >> >> >> Ashish Vijaywargiya wrote: >> >>> +1 >>> Adrian I liked your idea. >>> >>> On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit < >>> [hidden email]> >>> wrote: >>> >>> +1 >>>> -- >>>> Sumit Pandit >>>> >>>> >>>> On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: >>>> >>>> Yes this sounds good to me too >>>> >>>>> Jacques >>>>> >>>>> From: "Bruno Busco" <[hidden email]> >>>>> >>>>> Wonderfull !!!! >>>>>> Looking forward to having it !!! ;-) >>>>>> This will let me also define a more granular permissions to simplify >>>>>> the >>>>>> interface for not-so-skilled users. >>>>>> -Bruno >>>>>> 2008/6/4 Adrian Crum <[hidden email]>: >>>>>> >>>>>> In the screen widgets, you can check permissions with the >>>>>>> <if-has-permission> or <if-service-permission> elements. That's fine >>>>>>> if >>>>>>> you >>>>>>> only need to check a single permission to control access to the entire >>>>>>> screen. >>>>>>> >>>>>>> Things get complicated when a screen's elements are controlled by more >>>>>>> than >>>>>>> one permission. Let's say you have a typical Edit Item screen. The >>>>>>> screen >>>>>>> should be viewable only to users who have the VIEW permission. Users >>>>>>> who >>>>>>> have the UPDATE permission can edit the item. Users who have the >>>>>>> CREATE >>>>>>> permission see a "New Item" button. Users who have DELETE permission >>>>>>> see >>>>>>> a >>>>>>> "Delete Item" button. Users who have the ADMIN permission have >>>>>>> unrestricted >>>>>>> access to the screen. Wow. Five permission elements (and five service >>>>>>> calls) >>>>>>> are needed to control one screen. >>>>>>> >>>>>>> >>>>>>> Here's my idea: have a permission service that returns ALL of the >>>>>>> user's >>>>>>> permissions in a Map. You call the service with the permission to >>>>>>> check >>>>>>> - >>>>>>> "ACCOUNTING" for example. The service returns a Map containing all of >>>>>>> the >>>>>>> user's ACCOUNTING permissions stored as Boolean objects. Let's say the >>>>>>> returned Map is called permissionsMap and the user has ACCOUNTING_VIEW >>>>>>> and >>>>>>> ACCOUNTING_UPDATE permissions, then the Map would contain these >>>>>>> elements: >>>>>>> >>>>>>> CREATE=false >>>>>>> UPDATE=true >>>>>>> DELETE=false >>>>>>> VIEW=true >>>>>>> ADMIN=false >>>>>>> >>>>>>> If the service call is put in the screen's <actions> element, then the >>>>>>> Map >>>>>>> elements could be used to control the display of screen widget >>>>>>> sections, >>>>>>> menu items, and form fields. >>>>>>> >>>>>>> Freemarker code would be simpler too: >>>>>>> >>>>>>> <#if permissionsMap.CREATE> >>>>>>> <!-- Render a Create New button --> >>>>>>> </#if> >>>>>>> <#if permissionsMap.DELETE> >>>>>>> <!-- Render a Delete button --> >>>>>>> </#if> >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> > |
Re: Discussion: Permissions Checking Enhancement
|
|
Thank you,
it make sense; so a CREATE permission check will be sufficient for the CREATE button rendering. -Bruno 2008/6/6 Adrian Crum <[hidden email]>: > The pattern used so far is that the ADMIN permission is checked first, then > the other permissions. So if a user has the ADMIN permission, they don't > need the additional permissions. > > I'll probably have all of the permissions Map elements set to true if the > user has the ADMIN permission. > > -Adrian > > > Bruno Busco wrote: > >> Adrian, >> may be a newbie question but... >> ...in the example you give what will happen if a user has the ADMIN >> permission but not the CREATE one? >> Will the Create New button be rendered? >> >> In other words who is responsible for the permission hierarchy ? >> In order to display the CREATE button, should a user be given with the >> CREATE permission explicitly or the ADMIN is sufficient? >> >> Thank you >> -Bruno >> >> >> >> 2008/6/6 Adrian Crum <[hidden email]>: >> >> I'll work on it this weekend. >>> >>> -Adrian >>> >>> >>> Ashish Vijaywargiya wrote: >>> >>> +1 >>>> Adrian I liked your idea. >>>> >>>> On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit < >>>> [hidden email]> >>>> wrote: >>>> >>>> +1 >>>> >>>>> -- >>>>> Sumit Pandit >>>>> >>>>> >>>>> On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: >>>>> >>>>> Yes this sounds good to me too >>>>> >>>>> Jacques >>>>>> >>>>>> From: "Bruno Busco" <[hidden email]> >>>>>> >>>>>> Wonderfull !!!! >>>>>> >>>>>>> Looking forward to having it !!! ;-) >>>>>>> This will let me also define a more granular permissions to simplify >>>>>>> the >>>>>>> interface for not-so-skilled users. >>>>>>> -Bruno >>>>>>> 2008/6/4 Adrian Crum <[hidden email]>: >>>>>>> >>>>>>> In the screen widgets, you can check permissions with the >>>>>>> >>>>>>>> <if-has-permission> or <if-service-permission> elements. That's fine >>>>>>>> if >>>>>>>> you >>>>>>>> only need to check a single permission to control access to the >>>>>>>> entire >>>>>>>> screen. >>>>>>>> >>>>>>>> Things get complicated when a screen's elements are controlled by >>>>>>>> more >>>>>>>> than >>>>>>>> one permission. Let's say you have a typical Edit Item screen. The >>>>>>>> screen >>>>>>>> should be viewable only to users who have the VIEW permission. Users >>>>>>>> who >>>>>>>> have the UPDATE permission can edit the item. Users who have the >>>>>>>> CREATE >>>>>>>> permission see a "New Item" button. Users who have DELETE permission >>>>>>>> see >>>>>>>> a >>>>>>>> "Delete Item" button. Users who have the ADMIN permission have >>>>>>>> unrestricted >>>>>>>> access to the screen. Wow. Five permission elements (and five >>>>>>>> service >>>>>>>> calls) >>>>>>>> are needed to control one screen. >>>>>>>> >>>>>>>> >>>>>>>> Here's my idea: have a permission service that returns ALL of the >>>>>>>> user's >>>>>>>> permissions in a Map. You call the service with the permission to >>>>>>>> check >>>>>>>> - >>>>>>>> "ACCOUNTING" for example. The service returns a Map containing all >>>>>>>> of >>>>>>>> the >>>>>>>> user's ACCOUNTING permissions stored as Boolean objects. Let's say >>>>>>>> the >>>>>>>> returned Map is called permissionsMap and the user has >>>>>>>> ACCOUNTING_VIEW >>>>>>>> and >>>>>>>> ACCOUNTING_UPDATE permissions, then the Map would contain these >>>>>>>> elements: >>>>>>>> >>>>>>>> CREATE=false >>>>>>>> UPDATE=true >>>>>>>> DELETE=false >>>>>>>> VIEW=true >>>>>>>> ADMIN=false >>>>>>>> >>>>>>>> If the service call is put in the screen's <actions> element, then >>>>>>>> the >>>>>>>> Map >>>>>>>> elements could be used to control the display of screen widget >>>>>>>> sections, >>>>>>>> menu items, and form fields. >>>>>>>> >>>>>>>> Freemarker code would be simpler too: >>>>>>>> >>>>>>>> <#if permissionsMap.CREATE> >>>>>>>> <!-- Render a Create New button --> >>>>>>>> </#if> >>>>>>>> <#if permissionsMap.DELETE> >>>>>>>> <!-- Render a Delete button --> >>>>>>>> </#if> >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> |
Re: Discussion: Permissions Checking Enhancement
|
|
Correct.
Bruno Busco wrote: > Thank you, > it make sense; so a CREATE permission check will be sufficient for the > CREATE button rendering. > -Bruno > > 2008/6/6 Adrian Crum <[hidden email]>: > >> The pattern used so far is that the ADMIN permission is checked first, then >> the other permissions. So if a user has the ADMIN permission, they don't >> need the additional permissions. >> >> I'll probably have all of the permissions Map elements set to true if the >> user has the ADMIN permission. >> >> -Adrian >> >> >> Bruno Busco wrote: >> >>> Adrian, >>> may be a newbie question but... >>> ...in the example you give what will happen if a user has the ADMIN >>> permission but not the CREATE one? >>> Will the Create New button be rendered? >>> >>> In other words who is responsible for the permission hierarchy ? >>> In order to display the CREATE button, should a user be given with the >>> CREATE permission explicitly or the ADMIN is sufficient? >>> >>> Thank you >>> -Bruno >>> >>> >>> >>> 2008/6/6 Adrian Crum <[hidden email]>: >>> >>> I'll work on it this weekend. >>>> -Adrian >>>> >>>> >>>> Ashish Vijaywargiya wrote: >>>> >>>> +1 >>>>> Adrian I liked your idea. >>>>> >>>>> On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit < >>>>> [hidden email]> >>>>> wrote: >>>>> >>>>> +1 >>>>> >>>>>> -- >>>>>> Sumit Pandit >>>>>> >>>>>> >>>>>> On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: >>>>>> >>>>>> Yes this sounds good to me too >>>>>> >>>>>> Jacques >>>>>>> From: "Bruno Busco" <[hidden email]> >>>>>>> >>>>>>> Wonderfull !!!! >>>>>>> >>>>>>>> Looking forward to having it !!! ;-) >>>>>>>> This will let me also define a more granular permissions to simplify >>>>>>>> the >>>>>>>> interface for not-so-skilled users. >>>>>>>> -Bruno >>>>>>>> 2008/6/4 Adrian Crum <[hidden email]>: >>>>>>>> >>>>>>>> In the screen widgets, you can check permissions with the >>>>>>>> >>>>>>>>> <if-has-permission> or <if-service-permission> elements. That's fine >>>>>>>>> if >>>>>>>>> you >>>>>>>>> only need to check a single permission to control access to the >>>>>>>>> entire >>>>>>>>> screen. >>>>>>>>> >>>>>>>>> Things get complicated when a screen's elements are controlled by >>>>>>>>> more >>>>>>>>> than >>>>>>>>> one permission. Let's say you have a typical Edit Item screen. The >>>>>>>>> screen >>>>>>>>> should be viewable only to users who have the VIEW permission. Users >>>>>>>>> who >>>>>>>>> have the UPDATE permission can edit the item. Users who have the >>>>>>>>> CREATE >>>>>>>>> permission see a "New Item" button. Users who have DELETE permission >>>>>>>>> see >>>>>>>>> a >>>>>>>>> "Delete Item" button. Users who have the ADMIN permission have >>>>>>>>> unrestricted >>>>>>>>> access to the screen. Wow. Five permission elements (and five >>>>>>>>> service >>>>>>>>> calls) >>>>>>>>> are needed to control one screen. >>>>>>>>> >>>>>>>>> >>>>>>>>> Here's my idea: have a permission service that returns ALL of the >>>>>>>>> user's >>>>>>>>> permissions in a Map. You call the service with the permission to >>>>>>>>> check >>>>>>>>> - >>>>>>>>> "ACCOUNTING" for example. The service returns a Map containing all >>>>>>>>> of >>>>>>>>> the >>>>>>>>> user's ACCOUNTING permissions stored as Boolean objects. Let's say >>>>>>>>> the >>>>>>>>> returned Map is called permissionsMap and the user has >>>>>>>>> ACCOUNTING_VIEW >>>>>>>>> and >>>>>>>>> ACCOUNTING_UPDATE permissions, then the Map would contain these >>>>>>>>> elements: >>>>>>>>> >>>>>>>>> CREATE=false >>>>>>>>> UPDATE=true >>>>>>>>> DELETE=false >>>>>>>>> VIEW=true >>>>>>>>> ADMIN=false >>>>>>>>> >>>>>>>>> If the service call is put in the screen's <actions> element, then >>>>>>>>> the >>>>>>>>> Map >>>>>>>>> elements could be used to control the display of screen widget >>>>>>>>> sections, >>>>>>>>> menu items, and form fields. >>>>>>>>> >>>>>>>>> Freemarker code would be simpler too: >>>>>>>>> >>>>>>>>> <#if permissionsMap.CREATE> >>>>>>>>> <!-- Render a Create New button --> >>>>>>>>> </#if> >>>>>>>>> <#if permissionsMap.DELETE> >>>>>>>>> <!-- Render a Delete button --> >>>>>>>>> </#if> >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > |
Re: Discussion: Permissions Checking Enhancement
|
|
Hi Adrian,
I am thinking to something similar to what you proposed in this thread. What I would like to do is to simplify the UI to users who should not perform some operations. For instance, in the catalog application, when looking to the EditProduct screen, I would like that the following tabmenus: Geos, IDs, Keywords, Associations, Manufacturing, Costs, Attributes, Agreements, Accounts, Maintenance, Meters, Workefforts should not be visible to standard users while they should be visible to admin. I am thinking to implement several permissions (may be some are already there) and to check for them in the menu items. What do you think? Did you implement something about it? Thank you, -Bruno 2008/6/6 Adrian Crum <[hidden email]> > Correct. > > > Bruno Busco wrote: > >> Thank you, >> it make sense; so a CREATE permission check will be sufficient for the >> CREATE button rendering. >> -Bruno >> >> 2008/6/6 Adrian Crum <[hidden email]>: >> >> The pattern used so far is that the ADMIN permission is checked first, >>> then >>> the other permissions. So if a user has the ADMIN permission, they don't >>> need the additional permissions. >>> >>> I'll probably have all of the permissions Map elements set to true if the >>> user has the ADMIN permission. >>> >>> -Adrian >>> >>> >>> Bruno Busco wrote: >>> >>> Adrian, >>>> may be a newbie question but... >>>> ...in the example you give what will happen if a user has the ADMIN >>>> permission but not the CREATE one? >>>> Will the Create New button be rendered? >>>> >>>> In other words who is responsible for the permission hierarchy ? >>>> In order to display the CREATE button, should a user be given with the >>>> CREATE permission explicitly or the ADMIN is sufficient? >>>> >>>> Thank you >>>> -Bruno >>>> >>>> >>>> >>>> 2008/6/6 Adrian Crum <[hidden email]>: >>>> >>>> I'll work on it this weekend. >>>> >>>>> -Adrian >>>>> >>>>> >>>>> Ashish Vijaywargiya wrote: >>>>> >>>>> +1 >>>>> >>>>>> Adrian I liked your idea. >>>>>> >>>>>> On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit < >>>>>> [hidden email]> >>>>>> wrote: >>>>>> >>>>>> +1 >>>>>> >>>>>> -- >>>>>>> Sumit Pandit >>>>>>> >>>>>>> >>>>>>> On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: >>>>>>> >>>>>>> Yes this sounds good to me too >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>>> From: "Bruno Busco" <[hidden email]> >>>>>>>> >>>>>>>> Wonderfull !!!! >>>>>>>> >>>>>>>> Looking forward to having it !!! ;-) >>>>>>>>> This will let me also define a more granular permissions to >>>>>>>>> simplify >>>>>>>>> the >>>>>>>>> interface for not-so-skilled users. >>>>>>>>> -Bruno >>>>>>>>> 2008/6/4 Adrian Crum <[hidden email]>: >>>>>>>>> >>>>>>>>> In the screen widgets, you can check permissions with the >>>>>>>>> >>>>>>>>> <if-has-permission> or <if-service-permission> elements. That's >>>>>>>>>> fine >>>>>>>>>> if >>>>>>>>>> you >>>>>>>>>> only need to check a single permission to control access to the >>>>>>>>>> entire >>>>>>>>>> screen. >>>>>>>>>> >>>>>>>>>> Things get complicated when a screen's elements are controlled by >>>>>>>>>> more >>>>>>>>>> than >>>>>>>>>> one permission. Let's say you have a typical Edit Item screen. The >>>>>>>>>> screen >>>>>>>>>> should be viewable only to users who have the VIEW permission. >>>>>>>>>> Users >>>>>>>>>> who >>>>>>>>>> have the UPDATE permission can edit the item. Users who have the >>>>>>>>>> CREATE >>>>>>>>>> permission see a "New Item" button. Users who have DELETE >>>>>>>>>> permission >>>>>>>>>> see >>>>>>>>>> a >>>>>>>>>> "Delete Item" button. Users who have the ADMIN permission have >>>>>>>>>> unrestricted >>>>>>>>>> access to the screen. Wow. Five permission elements (and five >>>>>>>>>> service >>>>>>>>>> calls) >>>>>>>>>> are needed to control one screen. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here's my idea: have a permission service that returns ALL of the >>>>>>>>>> user's >>>>>>>>>> permissions in a Map. You call the service with the permission to >>>>>>>>>> check >>>>>>>>>> - >>>>>>>>>> "ACCOUNTING" for example. The service returns a Map containing all >>>>>>>>>> of >>>>>>>>>> the >>>>>>>>>> user's ACCOUNTING permissions stored as Boolean objects. Let's say >>>>>>>>>> the >>>>>>>>>> returned Map is called permissionsMap and the user has >>>>>>>>>> ACCOUNTING_VIEW >>>>>>>>>> and >>>>>>>>>> ACCOUNTING_UPDATE permissions, then the Map would contain these >>>>>>>>>> elements: >>>>>>>>>> >>>>>>>>>> CREATE=false >>>>>>>>>> UPDATE=true >>>>>>>>>> DELETE=false >>>>>>>>>> VIEW=true >>>>>>>>>> ADMIN=false >>>>>>>>>> >>>>>>>>>> If the service call is put in the screen's <actions> element, then >>>>>>>>>> the >>>>>>>>>> Map >>>>>>>>>> elements could be used to control the display of screen widget >>>>>>>>>> sections, >>>>>>>>>> menu items, and form fields. >>>>>>>>>> >>>>>>>>>> Freemarker code would be simpler too: >>>>>>>>>> >>>>>>>>>> <#if permissionsMap.CREATE> >>>>>>>>>> <!-- Render a Create New button --> >>>>>>>>>> </#if> >>>>>>>>>> <#if permissionsMap.DELETE> >>>>>>>>>> <!-- Render a Delete button --> >>>>>>>>>> </#if> >>>>>>>>>> >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> |
Re: Discussion: Permissions Checking Enhancement
|
|
Bruno,
I never got around to implementing that idea. I would still like to work on it though. -Adrian --- On Sat, 11/29/08, Bruno Busco <[hidden email]> wrote: > From: Bruno Busco <[hidden email]> > Subject: Re: Discussion: Permissions Checking Enhancement > To: [hidden email] > Date: Saturday, November 29, 2008, 10:30 AM > Hi Adrian, > I am thinking to something similar to what you proposed in > this thread. > What I would like to do is to simplify the UI to users who > should not > perform some operations. > > For instance, in the catalog application, when looking to > the EditProduct > screen, I would like that the following tabmenus: > Geos, IDs, Keywords, Associations, Manufacturing, Costs, > Attributes, > Agreements, Accounts, Maintenance, Meters, Workefforts > > should not be visible to standard users while they should > be visible to > admin. > > I am thinking to implement several permissions (may be some > are already > there) and to check for them in the menu items. > What do you think? > Did you implement something about it? > > Thank you, > -Bruno > > 2008/6/6 Adrian Crum <[hidden email]> > > > Correct. > > > > > > Bruno Busco wrote: > > > >> Thank you, > >> it make sense; so a CREATE permission check will > be sufficient for the > >> CREATE button rendering. > >> -Bruno > >> > >> 2008/6/6 Adrian Crum <[hidden email]>: > >> > >> The pattern used so far is that the ADMIN > permission is checked first, > >>> then > >>> the other permissions. So if a user has the > ADMIN permission, they don't > >>> need the additional permissions. > >>> > >>> I'll probably have all of the permissions > Map elements set to true if the > >>> user has the ADMIN permission. > >>> > >>> -Adrian > >>> > >>> > >>> Bruno Busco wrote: > >>> > >>> Adrian, > >>>> may be a newbie question but... > >>>> ...in the example you give what will > happen if a user has the ADMIN > >>>> permission but not the CREATE one? > >>>> Will the Create New button be rendered? > >>>> > >>>> In other words who is responsible for the > permission hierarchy ? > >>>> In order to display the CREATE button, > should a user be given with the > >>>> CREATE permission explicitly or the ADMIN > is sufficient? > >>>> > >>>> Thank you > >>>> -Bruno > >>>> > >>>> > >>>> > >>>> 2008/6/6 Adrian Crum > <[hidden email]>: > >>>> > >>>> I'll work on it this weekend. > >>>> > >>>>> -Adrian > >>>>> > >>>>> > >>>>> Ashish Vijaywargiya wrote: > >>>>> > >>>>> +1 > >>>>> > >>>>>> Adrian I liked your idea. > >>>>>> > >>>>>> On Thu, Jun 5, 2008 at 12:46 AM, > Sumit Pandit < > >>>>>> [hidden email]> > >>>>>> wrote: > >>>>>> > >>>>>> +1 > >>>>>> > >>>>>> -- > >>>>>>> Sumit Pandit > >>>>>>> > >>>>>>> > >>>>>>> On Jun 5, 2008, at 3:04 AM, > Jacques Le Roux wrote: > >>>>>>> > >>>>>>> Yes this sounds good to me > too > >>>>>>> > >>>>>>> Jacques > >>>>>>> > >>>>>>>> From: "Bruno > Busco" <[hidden email]> > >>>>>>>> > >>>>>>>> Wonderfull !!!! > >>>>>>>> > >>>>>>>> Looking forward to having > it !!! ;-) > >>>>>>>>> This will let me also > define a more granular permissions to > >>>>>>>>> simplify > >>>>>>>>> the > >>>>>>>>> interface for > not-so-skilled users. > >>>>>>>>> -Bruno > >>>>>>>>> 2008/6/4 Adrian Crum > <[hidden email]>: > >>>>>>>>> > >>>>>>>>> In the screen > widgets, you can check permissions with the > >>>>>>>>> > >>>>>>>>> > <if-has-permission> or <if-service-permission> > elements. That's > >>>>>>>>>> fine > >>>>>>>>>> if > >>>>>>>>>> you > >>>>>>>>>> only need to check > a single permission to control access to the > >>>>>>>>>> entire > >>>>>>>>>> screen. > >>>>>>>>>> > >>>>>>>>>> Things get > complicated when a screen's elements are controlled by > >>>>>>>>>> more > >>>>>>>>>> than > >>>>>>>>>> one permission. > Let's say you have a typical Edit Item screen. The > >>>>>>>>>> screen > >>>>>>>>>> should be viewable > only to users who have the VIEW permission. > >>>>>>>>>> Users > >>>>>>>>>> who > >>>>>>>>>> have the UPDATE > permission can edit the item. Users who have the > >>>>>>>>>> CREATE > >>>>>>>>>> permission see a > "New Item" button. Users who have DELETE > >>>>>>>>>> permission > >>>>>>>>>> see > >>>>>>>>>> a > >>>>>>>>>> "Delete > Item" button. Users who have the ADMIN permission have > >>>>>>>>>> unrestricted > >>>>>>>>>> access to the > screen. Wow. Five permission elements (and five > >>>>>>>>>> service > >>>>>>>>>> calls) > >>>>>>>>>> are needed to > control one screen. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Here's my > idea: have a permission service that returns ALL of the > >>>>>>>>>> user's > >>>>>>>>>> permissions in a > Map. You call the service with the permission to > >>>>>>>>>> check > >>>>>>>>>> - > >>>>>>>>>> > "ACCOUNTING" for example. The service returns a > Map containing all > >>>>>>>>>> of > >>>>>>>>>> the > >>>>>>>>>> user's > ACCOUNTING permissions stored as Boolean objects. Let's > say > >>>>>>>>>> the > >>>>>>>>>> returned Map is > called permissionsMap and the user has > >>>>>>>>>> ACCOUNTING_VIEW > >>>>>>>>>> and > >>>>>>>>>> ACCOUNTING_UPDATE > permissions, then the Map would contain these > >>>>>>>>>> elements: > >>>>>>>>>> > >>>>>>>>>> CREATE=false > >>>>>>>>>> UPDATE=true > >>>>>>>>>> DELETE=false > >>>>>>>>>> VIEW=true > >>>>>>>>>> ADMIN=false > >>>>>>>>>> > >>>>>>>>>> If the service > call is put in the screen's <actions> element, > then > >>>>>>>>>> the > >>>>>>>>>> Map > >>>>>>>>>> elements could be > used to control the display of screen widget > >>>>>>>>>> sections, > >>>>>>>>>> menu items, and > form fields. > >>>>>>>>>> > >>>>>>>>>> Freemarker code > would be simpler too: > >>>>>>>>>> > >>>>>>>>>> <#if > permissionsMap.CREATE> > >>>>>>>>>> <!-- Render a > Create New button --> > >>>>>>>>>> </#if> > >>>>>>>>>> <#if > permissionsMap.DELETE> > >>>>>>>>>> <!-- Render a > Delete button --> > >>>>>>>>>> </#if> > >>>>>>>>>> > >>>>>>>>>> What do you think? > >>>>>>>>>> > >>>>>>>>>> -Adrian > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >> |
Re: Discussion: Permissions Checking Enhancement
|
|
I need to simplify the UI has I described.
To do this I think the Map should contain ALL user permissions, not restricted to a single application. Could we think to specific permissions to hide the TabBar options? I understand that OFBiz UI is designed to have ALL there because at least everybody sees that a feature is available but this creates a problem when deplying to end user. I understand also that the perfect UI is the one that reproduces the very specific users workflow and so it must be written ad hoc. But having an 80% fitting UI with only permissions setting (user profiling) could be a good result. This IMO is another key factor for spreading OFBiz and having more people using it. I would like to hear other idea about this and, possibly, some user profiling pattern ideas. For sure the Portlet system will help in this direction but could we think to a UI profiling through permission too? -Bruno 2008/11/30 Adrian Crum <[hidden email]> > Bruno, > > I never got around to implementing that idea. I would still like to work on > it though. > > -Adrian > > > --- On Sat, 11/29/08, Bruno Busco <[hidden email]> wrote: > > > From: Bruno Busco <[hidden email]> > > Subject: Re: Discussion: Permissions Checking Enhancement > > To: [hidden email] > > Date: Saturday, November 29, 2008, 10:30 AM > > Hi Adrian, > > I am thinking to something similar to what you proposed in > > this thread. > > What I would like to do is to simplify the UI to users who > > should not > > perform some operations. > > > > For instance, in the catalog application, when looking to > > the EditProduct > > screen, I would like that the following tabmenus: > > Geos, IDs, Keywords, Associations, Manufacturing, Costs, > > Attributes, > > Agreements, Accounts, Maintenance, Meters, Workefforts > > > > should not be visible to standard users while they should > > be visible to > > admin. > > > > I am thinking to implement several permissions (may be some > > are already > > there) and to check for them in the menu items. > > What do you think? > > Did you implement something about it? > > > > Thank you, > > -Bruno > > > > 2008/6/6 Adrian Crum <[hidden email]> > > > > > Correct. > > > > > > > > > Bruno Busco wrote: > > > > > >> Thank you, > > >> it make sense; so a CREATE permission check will > > be sufficient for the > > >> CREATE button rendering. > > >> -Bruno > > >> > > >> 2008/6/6 Adrian Crum <[hidden email]>: > > >> > > >> The pattern used so far is that the ADMIN > > permission is checked first, > > >>> then > > >>> the other permissions. So if a user has the > > ADMIN permission, they don't > > >>> need the additional permissions. > > >>> > > >>> I'll probably have all of the permissions > > Map elements set to true if the > > >>> user has the ADMIN permission. > > >>> > > >>> -Adrian > > >>> > > >>> > > >>> Bruno Busco wrote: > > >>> > > >>> Adrian, > > >>>> may be a newbie question but... > > >>>> ...in the example you give what will > > happen if a user has the ADMIN > > >>>> permission but not the CREATE one? > > >>>> Will the Create New button be rendered? > > >>>> > > >>>> In other words who is responsible for the > > permission hierarchy ? > > >>>> In order to display the CREATE button, > > should a user be given with the > > >>>> CREATE permission explicitly or the ADMIN > > is sufficient? > > >>>> > > >>>> Thank you > > >>>> -Bruno > > >>>> > > >>>> > > >>>> > > >>>> 2008/6/6 Adrian Crum > > <[hidden email]>: > > >>>> > > >>>> I'll work on it this weekend. > > >>>> > > >>>>> -Adrian > > >>>>> > > >>>>> > > >>>>> Ashish Vijaywargiya wrote: > > >>>>> > > >>>>> +1 > > >>>>> > > >>>>>> Adrian I liked your idea. > > >>>>>> > > >>>>>> On Thu, Jun 5, 2008 at 12:46 AM, > > Sumit Pandit < > > >>>>>> [hidden email]> > > >>>>>> wrote: > > >>>>>> > > >>>>>> +1 > > >>>>>> > > >>>>>> -- > > >>>>>>> Sumit Pandit > > >>>>>>> > > >>>>>>> > > >>>>>>> On Jun 5, 2008, at 3:04 AM, > > Jacques Le Roux wrote: > > >>>>>>> > > >>>>>>> Yes this sounds good to me > > too > > >>>>>>> > > >>>>>>> Jacques > > >>>>>>> > > >>>>>>>> From: "Bruno > > Busco" <[hidden email]> > > >>>>>>>> > > >>>>>>>> Wonderfull !!!! > > >>>>>>>> > > >>>>>>>> Looking forward to having > > it !!! ;-) > > >>>>>>>>> This will let me also > > define a more granular permissions to > > >>>>>>>>> simplify > > >>>>>>>>> the > > >>>>>>>>> interface for > > not-so-skilled users. > > >>>>>>>>> -Bruno > > >>>>>>>>> 2008/6/4 Adrian Crum > > <[hidden email]>: > > >>>>>>>>> > > >>>>>>>>> In the screen > > widgets, you can check permissions with the > > >>>>>>>>> > > >>>>>>>>> > > <if-has-permission> or <if-service-permission> > > elements. That's > > >>>>>>>>>> fine > > >>>>>>>>>> if > > >>>>>>>>>> you > > >>>>>>>>>> only need to check > > a single permission to control access to the > > >>>>>>>>>> entire > > >>>>>>>>>> screen. > > >>>>>>>>>> > > >>>>>>>>>> Things get > > complicated when a screen's elements are controlled by > > >>>>>>>>>> more > > >>>>>>>>>> than > > >>>>>>>>>> one permission. > > Let's say you have a typical Edit Item screen. The > > >>>>>>>>>> screen > > >>>>>>>>>> should be viewable > > only to users who have the VIEW permission. > > >>>>>>>>>> Users > > >>>>>>>>>> who > > >>>>>>>>>> have the UPDATE > > permission can edit the item. Users who have the > > >>>>>>>>>> CREATE > > >>>>>>>>>> permission see a > > "New Item" button. Users who have DELETE > > >>>>>>>>>> permission > > >>>>>>>>>> see > > >>>>>>>>>> a > > >>>>>>>>>> "Delete > > Item" button. Users who have the ADMIN permission have > > >>>>>>>>>> unrestricted > > >>>>>>>>>> access to the > > screen. Wow. Five permission elements (and five > > >>>>>>>>>> service > > >>>>>>>>>> calls) > > >>>>>>>>>> are needed to > > control one screen. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Here's my > > idea: have a permission service that returns ALL of the > > >>>>>>>>>> user's > > >>>>>>>>>> permissions in a > > Map. You call the service with the permission to > > >>>>>>>>>> check > > >>>>>>>>>> - > > >>>>>>>>>> > > "ACCOUNTING" for example. The service returns a > > Map containing all > > >>>>>>>>>> of > > >>>>>>>>>> the > > >>>>>>>>>> user's > > ACCOUNTING permissions stored as Boolean objects. Let's > > say > > >>>>>>>>>> the > > >>>>>>>>>> returned Map is > > called permissionsMap and the user has > > >>>>>>>>>> ACCOUNTING_VIEW > > >>>>>>>>>> and > > >>>>>>>>>> ACCOUNTING_UPDATE > > permissions, then the Map would contain these > > >>>>>>>>>> elements: > > >>>>>>>>>> > > >>>>>>>>>> CREATE=false > > >>>>>>>>>> UPDATE=true > > >>>>>>>>>> DELETE=false > > >>>>>>>>>> VIEW=true > > >>>>>>>>>> ADMIN=false > > >>>>>>>>>> > > >>>>>>>>>> If the service > > call is put in the screen's <actions> element, > > then > > >>>>>>>>>> the > > >>>>>>>>>> Map > > >>>>>>>>>> elements could be > > used to control the display of screen widget > > >>>>>>>>>> sections, > > >>>>>>>>>> menu items, and > > form fields. > > >>>>>>>>>> > > >>>>>>>>>> Freemarker code > > would be simpler too: > > >>>>>>>>>> > > >>>>>>>>>> <#if > > permissionsMap.CREATE> > > >>>>>>>>>> <!-- Render a > > Create New button --> > > >>>>>>>>>> </#if> > > >>>>>>>>>> <#if > > permissionsMap.DELETE> > > >>>>>>>>>> <!-- Render a > > Delete button --> > > >>>>>>>>>> </#if> > > >>>>>>>>>> > > >>>>>>>>>> What do you think? > > >>>>>>>>>> > > >>>>>>>>>> -Adrian > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >> > > > > |
Re: Discussion: Permissions Checking Enhancement
|
|
One option for this (or at least part of it), and one that I think has been discussed before, would be to introduce a convention for naming permissions (or more to the point, "ID-ing" permissions) based on screen names and locations. A few aspects of this: 1. We could configure specific screens to always require the screen- specific permission, or to require either a general permission (probably specified in the screen def) or the screen-specific permission 2. this would be a view-only permission for rendering the screen 3. doing it for each screen defined would allow for permissions on sub- screens and such as well -David On Nov 30, 2008, at 12:32 AM, Bruno Busco wrote: > I need to simplify the UI has I described. > To do this I think the Map should contain ALL user permissions, not > restricted to a single application. > Could we think to specific permissions to hide the TabBar options? > > I understand that OFBiz UI is designed to have ALL there because at > least > everybody sees that a feature is available but this creates a > problem when > deplying to end user. > I understand also that the perfect UI is the one that reproduces the > very > specific users workflow and so it must be written ad hoc. > But having an 80% fitting UI with only permissions setting (user > profiling) > could be a good result. > > This IMO is another key factor for spreading OFBiz and having more > people > using it. > > I would like to hear other idea about this and, possibly, some user > profiling pattern ideas. > For sure the Portlet system will help in this direction but could we > think > to a UI profiling through permission too? > > -Bruno > > 2008/11/30 Adrian Crum <[hidden email]> > >> Bruno, >> >> I never got around to implementing that idea. I would still like to >> work on >> it though. >> >> -Adrian >> >> >> --- On Sat, 11/29/08, Bruno Busco <[hidden email]> wrote: >> >>> From: Bruno Busco <[hidden email]> >>> Subject: Re: Discussion: Permissions Checking Enhancement >>> To: [hidden email] >>> Date: Saturday, November 29, 2008, 10:30 AM >>> Hi Adrian, >>> I am thinking to something similar to what you proposed in >>> this thread. >>> What I would like to do is to simplify the UI to users who >>> should not >>> perform some operations. >>> >>> For instance, in the catalog application, when looking to >>> the EditProduct >>> screen, I would like that the following tabmenus: >>> Geos, IDs, Keywords, Associations, Manufacturing, Costs, >>> Attributes, >>> Agreements, Accounts, Maintenance, Meters, Workefforts >>> >>> should not be visible to standard users while they should >>> be visible to >>> admin. >>> >>> I am thinking to implement several permissions (may be some >>> are already >>> there) and to check for them in the menu items. >>> What do you think? >>> Did you implement something about it? >>> >>> Thank you, >>> -Bruno >>> >>> 2008/6/6 Adrian Crum <[hidden email]> >>> >>>> Correct. >>>> >>>> >>>> Bruno Busco wrote: >>>> >>>>> Thank you, >>>>> it make sense; so a CREATE permission check will >>> be sufficient for the >>>>> CREATE button rendering. >>>>> -Bruno >>>>> >>>>> 2008/6/6 Adrian Crum <[hidden email]>: >>>>> >>>>> The pattern used so far is that the ADMIN >>> permission is checked first, >>>>>> then >>>>>> the other permissions. So if a user has the >>> ADMIN permission, they don't >>>>>> need the additional permissions. >>>>>> >>>>>> I'll probably have all of the permissions >>> Map elements set to true if the >>>>>> user has the ADMIN permission. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> Bruno Busco wrote: >>>>>> >>>>>> Adrian, >>>>>>> may be a newbie question but... >>>>>>> ...in the example you give what will >>> happen if a user has the ADMIN >>>>>>> permission but not the CREATE one? >>>>>>> Will the Create New button be rendered? >>>>>>> >>>>>>> In other words who is responsible for the >>> permission hierarchy ? >>>>>>> In order to display the CREATE button, >>> should a user be given with the >>>>>>> CREATE permission explicitly or the ADMIN >>> is sufficient? >>>>>>> >>>>>>> Thank you >>>>>>> -Bruno >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2008/6/6 Adrian Crum >>> <[hidden email]>: >>>>>>> >>>>>>> I'll work on it this weekend. >>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> Ashish Vijaywargiya wrote: >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>>> Adrian I liked your idea. >>>>>>>>> >>>>>>>>> On Thu, Jun 5, 2008 at 12:46 AM, >>> Sumit Pandit < >>>>>>>>> [hidden email]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> -- >>>>>>>>>> Sumit Pandit >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jun 5, 2008, at 3:04 AM, >>> Jacques Le Roux wrote: >>>>>>>>>> >>>>>>>>>> Yes this sounds good to me >>> too >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>>> From: "Bruno >>> Busco" <[hidden email]> >>>>>>>>>>> >>>>>>>>>>> Wonderfull !!!! >>>>>>>>>>> >>>>>>>>>>> Looking forward to having >>> it !!! ;-) >>>>>>>>>>>> This will let me also >>> define a more granular permissions to >>>>>>>>>>>> simplify >>>>>>>>>>>> the >>>>>>>>>>>> interface for >>> not-so-skilled users. >>>>>>>>>>>> -Bruno >>>>>>>>>>>> 2008/6/4 Adrian Crum >>> <[hidden email]>: >>>>>>>>>>>> >>>>>>>>>>>> In the screen >>> widgets, you can check permissions with the >>>>>>>>>>>> >>>>>>>>>>>> >>> <if-has-permission> or <if-service-permission> >>> elements. That's >>>>>>>>>>>>> fine >>>>>>>>>>>>> if >>>>>>>>>>>>> you >>>>>>>>>>>>> only need to check >>> a single permission to control access to the >>>>>>>>>>>>> entire >>>>>>>>>>>>> screen. >>>>>>>>>>>>> >>>>>>>>>>>>> Things get >>> complicated when a screen's elements are controlled by >>>>>>>>>>>>> more >>>>>>>>>>>>> than >>>>>>>>>>>>> one permission. >>> Let's say you have a typical Edit Item screen. The >>>>>>>>>>>>> screen >>>>>>>>>>>>> should be viewable >>> only to users who have the VIEW permission. >>>>>>>>>>>>> Users >>>>>>>>>>>>> who >>>>>>>>>>>>> have the UPDATE >>> permission can edit the item. Users who have the >>>>>>>>>>>>> CREATE >>>>>>>>>>>>> permission see a >>> "New Item" button. Users who have DELETE >>>>>>>>>>>>> permission >>>>>>>>>>>>> see >>>>>>>>>>>>> a >>>>>>>>>>>>> "Delete >>> Item" button. Users who have the ADMIN permission have >>>>>>>>>>>>> unrestricted >>>>>>>>>>>>> access to the >>> screen. Wow. Five permission elements (and five >>>>>>>>>>>>> service >>>>>>>>>>>>> calls) >>>>>>>>>>>>> are needed to >>> control one screen. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Here's my >>> idea: have a permission service that returns ALL of the >>>>>>>>>>>>> user's >>>>>>>>>>>>> permissions in a >>> Map. You call the service with the permission to >>>>>>>>>>>>> check >>>>>>>>>>>>> - >>>>>>>>>>>>> >>> "ACCOUNTING" for example. The service returns a >>> Map containing all >>>>>>>>>>>>> of >>>>>>>>>>>>> the >>>>>>>>>>>>> user's >>> ACCOUNTING permissions stored as Boolean objects. Let's >>> say >>>>>>>>>>>>> the >>>>>>>>>>>>> returned Map is >>> called permissionsMap and the user has >>>>>>>>>>>>> ACCOUNTING_VIEW >>>>>>>>>>>>> and >>>>>>>>>>>>> ACCOUNTING_UPDATE >>> permissions, then the Map would contain these >>>>>>>>>>>>> elements: >>>>>>>>>>>>> >>>>>>>>>>>>> CREATE=false >>>>>>>>>>>>> UPDATE=true >>>>>>>>>>>>> DELETE=false >>>>>>>>>>>>> VIEW=true >>>>>>>>>>>>> ADMIN=false >>>>>>>>>>>>> >>>>>>>>>>>>> If the service >>> call is put in the screen's <actions> element, >>> then >>>>>>>>>>>>> the >>>>>>>>>>>>> Map >>>>>>>>>>>>> elements could be >>> used to control the display of screen widget >>>>>>>>>>>>> sections, >>>>>>>>>>>>> menu items, and >>> form fields. >>>>>>>>>>>>> >>>>>>>>>>>>> Freemarker code >>> would be simpler too: >>>>>>>>>>>>> >>>>>>>>>>>>> <#if >>> permissionsMap.CREATE> >>>>>>>>>>>>> <!-- Render a >>> Create New button --> >>>>>>>>>>>>> </#if> >>>>>>>>>>>>> <#if >>> permissionsMap.DELETE> >>>>>>>>>>>>> <!-- Render a >>> Delete button --> >>>>>>>>>>>>> </#if> >>>>>>>>>>>>> >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> -Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>> >> >> >> >> |
Re: Discussion: Permissions Checking Enhancement
|
|
David,
I like this idea. So we should add a screen property to specify a permission. The same permission should be checked to render the menu item that takes to that screen (sub-screen). Is this what you mean? This could be done even without the "getAllPermissions" service proposed, am I right? -Bruno 2008/12/3 David E Jones <[hidden email]> > > One option for this (or at least part of it), and one that I think has been > discussed before, would be to introduce a convention for naming permissions > (or more to the point, "ID-ing" permissions) based on screen names and > locations. A few aspects of this: > > 1. We could configure specific screens to always require the > screen-specific permission, or to require either a general permission > (probably specified in the screen def) or the screen-specific permission > > 2. this would be a view-only permission for rendering the screen > > 3. doing it for each screen defined would allow for permissions on > sub-screens and such as well > > -David > > > > On Nov 30, 2008, at 12:32 AM, Bruno Busco wrote: > > I need to simplify the UI has I described. >> To do this I think the Map should contain ALL user permissions, not >> restricted to a single application. >> Could we think to specific permissions to hide the TabBar options? >> >> I understand that OFBiz UI is designed to have ALL there because at least >> everybody sees that a feature is available but this creates a problem when >> deplying to end user. >> I understand also that the perfect UI is the one that reproduces the very >> specific users workflow and so it must be written ad hoc. >> But having an 80% fitting UI with only permissions setting (user >> profiling) >> could be a good result. >> >> This IMO is another key factor for spreading OFBiz and having more people >> using it. >> >> I would like to hear other idea about this and, possibly, some user >> profiling pattern ideas. >> For sure the Portlet system will help in this direction but could we think >> to a UI profiling through permission too? >> >> -Bruno >> >> 2008/11/30 Adrian Crum <[hidden email]> >> >> Bruno, >>> >>> I never got around to implementing that idea. I would still like to work >>> on >>> it though. >>> >>> -Adrian >>> >>> >>> --- On Sat, 11/29/08, Bruno Busco <[hidden email]> wrote: >>> >>> From: Bruno Busco <[hidden email]> >>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>> To: [hidden email] >>>> Date: Saturday, November 29, 2008, 10:30 AM >>>> Hi Adrian, >>>> I am thinking to something similar to what you proposed in >>>> this thread. >>>> What I would like to do is to simplify the UI to users who >>>> should not >>>> perform some operations. >>>> >>>> For instance, in the catalog application, when looking to >>>> the EditProduct >>>> screen, I would like that the following tabmenus: >>>> Geos, IDs, Keywords, Associations, Manufacturing, Costs, >>>> Attributes, >>>> Agreements, Accounts, Maintenance, Meters, Workefforts >>>> >>>> should not be visible to standard users while they should >>>> be visible to >>>> admin. >>>> >>>> I am thinking to implement several permissions (may be some >>>> are already >>>> there) and to check for them in the menu items. >>>> What do you think? >>>> Did you implement something about it? >>>> >>>> Thank you, >>>> -Bruno >>>> >>>> 2008/6/6 Adrian Crum <[hidden email]> >>>> >>>> Correct. >>>>> >>>>> >>>>> Bruno Busco wrote: >>>>> >>>>> Thank you, >>>>>> it make sense; so a CREATE permission check will >>>>>> >>>>> be sufficient for the >>>> >>>>> CREATE button rendering. >>>>>> -Bruno >>>>>> >>>>>> 2008/6/6 Adrian Crum <[hidden email]>: >>>>>> >>>>>> The pattern used so far is that the ADMIN >>>>>> >>>>> permission is checked first, >>>> >>>>> then >>>>>>> the other permissions. So if a user has the >>>>>>> >>>>>> ADMIN permission, they don't >>>> >>>>> need the additional permissions. >>>>>>> >>>>>>> I'll probably have all of the permissions >>>>>>> >>>>>> Map elements set to true if the >>>> >>>>> user has the ADMIN permission. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> Bruno Busco wrote: >>>>>>> >>>>>>> Adrian, >>>>>>> >>>>>>>> may be a newbie question but... >>>>>>>> ...in the example you give what will >>>>>>>> >>>>>>> happen if a user has the ADMIN >>>> >>>>> permission but not the CREATE one? >>>>>>>> Will the Create New button be rendered? >>>>>>>> >>>>>>>> In other words who is responsible for the >>>>>>>> >>>>>>> permission hierarchy ? >>>> >>>>> In order to display the CREATE button, >>>>>>>> >>>>>>> should a user be given with the >>>> >>>>> CREATE permission explicitly or the ADMIN >>>>>>>> >>>>>>> is sufficient? >>>> >>>>> >>>>>>>> Thank you >>>>>>>> -Bruno >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2008/6/6 Adrian Crum >>>>>>>> >>>>>>> <[hidden email]>: >>>> >>>>> >>>>>>>> I'll work on it this weekend. >>>>>>>> >>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> Ashish Vijaywargiya wrote: >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Adrian I liked your idea. >>>>>>>>>> >>>>>>>>>> On Thu, Jun 5, 2008 at 12:46 AM, >>>>>>>>>> >>>>>>>>> Sumit Pandit < >>>> >>>>> [hidden email]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>>> Sumit Pandit >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jun 5, 2008, at 3:04 AM, >>>>>>>>>>> >>>>>>>>>> Jacques Le Roux wrote: >>>> >>>>> >>>>>>>>>>> Yes this sounds good to me >>>>>>>>>>> >>>>>>>>>> too >>>> >>>>> >>>>>>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> From: "Bruno >>>>>>>>>>>> >>>>>>>>>>> Busco" <[hidden email]> >>>> >>>>> >>>>>>>>>>>> Wonderfull !!!! >>>>>>>>>>>> >>>>>>>>>>>> Looking forward to having >>>>>>>>>>>> >>>>>>>>>>> it !!! ;-) >>>> >>>>> This will let me also >>>>>>>>>>>>> >>>>>>>>>>>> define a more granular permissions to >>>> >>>>> simplify >>>>>>>>>>>>> the >>>>>>>>>>>>> interface for >>>>>>>>>>>>> >>>>>>>>>>>> not-so-skilled users. >>>> >>>>> -Bruno >>>>>>>>>>>>> 2008/6/4 Adrian Crum >>>>>>>>>>>>> >>>>>>>>>>>> <[hidden email]>: >>>> >>>>> >>>>>>>>>>>>> In the screen >>>>>>>>>>>>> >>>>>>>>>>>> widgets, you can check permissions with the >>>> >>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <if-has-permission> or <if-service-permission> >>>> elements. That's >>>> >>>>> fine >>>>>>>>>>>>>> if >>>>>>>>>>>>>> you >>>>>>>>>>>>>> only need to check >>>>>>>>>>>>>> >>>>>>>>>>>>> a single permission to control access to the >>>> >>>>> entire >>>>>>>>>>>>>> screen. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Things get >>>>>>>>>>>>>> >>>>>>>>>>>>> complicated when a screen's elements are controlled by >>>> >>>>> more >>>>>>>>>>>>>> than >>>>>>>>>>>>>> one permission. >>>>>>>>>>>>>> >>>>>>>>>>>>> Let's say you have a typical Edit Item screen. The >>>> >>>>> screen >>>>>>>>>>>>>> should be viewable >>>>>>>>>>>>>> >>>>>>>>>>>>> only to users who have the VIEW permission. >>>> >>>>> Users >>>>>>>>>>>>>> who >>>>>>>>>>>>>> have the UPDATE >>>>>>>>>>>>>> >>>>>>>>>>>>> permission can edit the item. Users who have the >>>> >>>>> CREATE >>>>>>>>>>>>>> permission see a >>>>>>>>>>>>>> >>>>>>>>>>>>> "New Item" button. Users who have DELETE >>>> >>>>> permission >>>>>>>>>>>>>> see >>>>>>>>>>>>>> a >>>>>>>>>>>>>> "Delete >>>>>>>>>>>>>> >>>>>>>>>>>>> Item" button. Users who have the ADMIN permission have >>>> >>>>> unrestricted >>>>>>>>>>>>>> access to the >>>>>>>>>>>>>> >>>>>>>>>>>>> screen. Wow. Five permission elements (and five >>>> >>>>> service >>>>>>>>>>>>>> calls) >>>>>>>>>>>>>> are needed to >>>>>>>>>>>>>> >>>>>>>>>>>>> control one screen. >>>> >>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here's my >>>>>>>>>>>>>> >>>>>>>>>>>>> idea: have a permission service that returns ALL of the >>>> >>>>> user's >>>>>>>>>>>>>> permissions in a >>>>>>>>>>>>>> >>>>>>>>>>>>> Map. You call the service with the permission to >>>> >>>>> check >>>>>>>>>>>>>> - >>>>>>>>>>>>>> >>>>>>>>>>>>>> "ACCOUNTING" for example. The service returns a >>>> Map containing all >>>> >>>>> of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> user's >>>>>>>>>>>>>> >>>>>>>>>>>>> ACCOUNTING permissions stored as Boolean objects. Let's >>>> say >>>> >>>>> the >>>>>>>>>>>>>> returned Map is >>>>>>>>>>>>>> >>>>>>>>>>>>> called permissionsMap and the user has >>>> >>>>> ACCOUNTING_VIEW >>>>>>>>>>>>>> and >>>>>>>>>>>>>> ACCOUNTING_UPDATE >>>>>>>>>>>>>> >>>>>>>>>>>>> permissions, then the Map would contain these >>>> >>>>> elements: >>>>>>>>>>>>>> >>>>>>>>>>>>>> CREATE=false >>>>>>>>>>>>>> UPDATE=true >>>>>>>>>>>>>> DELETE=false >>>>>>>>>>>>>> VIEW=true >>>>>>>>>>>>>> ADMIN=false >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the service >>>>>>>>>>>>>> >>>>>>>>>>>>> call is put in the screen's <actions> element, >>>> then >>>> >>>>> the >>>>>>>>>>>>>> Map >>>>>>>>>>>>>> elements could be >>>>>>>>>>>>>> >>>>>>>>>>>>> used to control the display of screen widget >>>> >>>>> sections, >>>>>>>>>>>>>> menu items, and >>>>>>>>>>>>>> >>>>>>>>>>>>> form fields. >>>> >>>>> >>>>>>>>>>>>>> Freemarker code >>>>>>>>>>>>>> >>>>>>>>>>>>> would be simpler too: >>>> >>>>> >>>>>>>>>>>>>> <#if >>>>>>>>>>>>>> >>>>>>>>>>>>> permissionsMap.CREATE> >>>> >>>>> <!-- Render a >>>>>>>>>>>>>> >>>>>>>>>>>>> Create New button --> >>>> >>>>> </#if> >>>>>>>>>>>>>> <#if >>>>>>>>>>>>>> >>>>>>>>>>>>> permissionsMap.DELETE> >>>> >>>>> <!-- Render a >>>>>>>>>>>>>> >>>>>>>>>>>>> Delete button --> >>>> >>>>> </#if> >>>>>>>>>>>>>> >>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> >>> >>> >>> >>> > |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
So refering to defintions in http://docs.ofbiz.org/display/OFBTECH/OFBiz+security this would be between the component menu level and
the screen level (which use "<if-has-permission" and "<if-service-permission" tags), that's it ? It would be great to be able to hide menus as Bruno suggested (having a parameter in menu-item like David sugested for screens def). It could be then named the menu level permission (we should then rename the component menu level to component level or even application level) In a 1st and generic approach we could use 2 user categories : experts and novices. By default the expert mode would be used (all shown OOTB) but users could change this in their preferences to novice mode. So this would need to define what novice could and should not see in all OFBiz (and should be updated later, being visible by default). Later contributors could defines specific categories and they could be added to users's preferences choice. Could not roles be used for that or is it really orthogonal ? (customer service can't see some accounting screens, but are able to view some other etc.). My 2 cts Jacques From: "Bruno Busco" <[hidden email]> > David, > I like this idea. > > So we should add a screen property to specify a permission. > The same permission should be checked to render the menu item that takes to > that screen (sub-screen). > Is this what you mean? > > This could be done even without the "getAllPermissions" service proposed, am > I right? > > -Bruno > > > > 2008/12/3 David E Jones <[hidden email]> > >> >> One option for this (or at least part of it), and one that I think has been >> discussed before, would be to introduce a convention for naming permissions >> (or more to the point, "ID-ing" permissions) based on screen names and >> locations. A few aspects of this: >> >> 1. We could configure specific screens to always require the >> screen-specific permission, or to require either a general permission >> (probably specified in the screen def) or the screen-specific permission >> >> 2. this would be a view-only permission for rendering the screen >> >> 3. doing it for each screen defined would allow for permissions on >> sub-screens and such as well >> >> -David >> >> >> >> On Nov 30, 2008, at 12:32 AM, Bruno Busco wrote: >> >> I need to simplify the UI has I described. >>> To do this I think the Map should contain ALL user permissions, not >>> restricted to a single application. >>> Could we think to specific permissions to hide the TabBar options? >>> >>> I understand that OFBiz UI is designed to have ALL there because at least >>> everybody sees that a feature is available but this creates a problem when >>> deplying to end user. >>> I understand also that the perfect UI is the one that reproduces the very >>> specific users workflow and so it must be written ad hoc. >>> But having an 80% fitting UI with only permissions setting (user >>> profiling) >>> could be a good result. >>> >>> This IMO is another key factor for spreading OFBiz and having more people >>> using it. >>> >>> I would like to hear other idea about this and, possibly, some user >>> profiling pattern ideas. >>> For sure the Portlet system will help in this direction but could we think >>> to a UI profiling through permission too? >>> >>> -Bruno >>> >>> 2008/11/30 Adrian Crum <[hidden email]> >>> >>> Bruno, >>>> >>>> I never got around to implementing that idea. I would still like to work >>>> on >>>> it though. >>>> >>>> -Adrian >>>> >>>> >>>> --- On Sat, 11/29/08, Bruno Busco <[hidden email]> wrote: >>>> >>>> From: Bruno Busco <[hidden email]> >>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>> To: [hidden email] >>>>> Date: Saturday, November 29, 2008, 10:30 AM >>>>> Hi Adrian, >>>>> I am thinking to something similar to what you proposed in >>>>> this thread. >>>>> What I would like to do is to simplify the UI to users who >>>>> should not >>>>> perform some operations. >>>>> >>>>> For instance, in the catalog application, when looking to >>>>> the EditProduct >>>>> screen, I would like that the following tabmenus: >>>>> Geos, IDs, Keywords, Associations, Manufacturing, Costs, >>>>> Attributes, >>>>> Agreements, Accounts, Maintenance, Meters, Workefforts >>>>> >>>>> should not be visible to standard users while they should >>>>> be visible to >>>>> admin. >>>>> >>>>> I am thinking to implement several permissions (may be some >>>>> are already >>>>> there) and to check for them in the menu items. >>>>> What do you think? >>>>> Did you implement something about it? >>>>> >>>>> Thank you, >>>>> -Bruno >>>>> >>>>> 2008/6/6 Adrian Crum <[hidden email]> >>>>> >>>>> Correct. >>>>>> >>>>>> >>>>>> Bruno Busco wrote: >>>>>> >>>>>> Thank you, >>>>>>> it make sense; so a CREATE permission check will >>>>>>> >>>>>> be sufficient for the >>>>> >>>>>> CREATE button rendering. >>>>>>> -Bruno >>>>>>> >>>>>>> 2008/6/6 Adrian Crum <[hidden email]>: >>>>>>> >>>>>>> The pattern used so far is that the ADMIN >>>>>>> >>>>>> permission is checked first, >>>>> >>>>>> then >>>>>>>> the other permissions. So if a user has the >>>>>>>> >>>>>>> ADMIN permission, they don't >>>>> >>>>>> need the additional permissions. >>>>>>>> >>>>>>>> I'll probably have all of the permissions >>>>>>>> >>>>>>> Map elements set to true if the >>>>> >>>>>> user has the ADMIN permission. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> Bruno Busco wrote: >>>>>>>> >>>>>>>> Adrian, >>>>>>>> >>>>>>>>> may be a newbie question but... >>>>>>>>> ...in the example you give what will >>>>>>>>> >>>>>>>> happen if a user has the ADMIN >>>>> >>>>>> permission but not the CREATE one? >>>>>>>>> Will the Create New button be rendered? >>>>>>>>> >>>>>>>>> In other words who is responsible for the >>>>>>>>> >>>>>>>> permission hierarchy ? >>>>> >>>>>> In order to display the CREATE button, >>>>>>>>> >>>>>>>> should a user be given with the >>>>> >>>>>> CREATE permission explicitly or the ADMIN >>>>>>>>> >>>>>>>> is sufficient? >>>>> >>>>>> >>>>>>>>> Thank you >>>>>>>>> -Bruno >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2008/6/6 Adrian Crum >>>>>>>>> >>>>>>>> <[hidden email]>: >>>>> >>>>>> >>>>>>>>> I'll work on it this weekend. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ashish Vijaywargiya wrote: >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> Adrian I liked your idea. >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 5, 2008 at 12:46 AM, >>>>>>>>>>> >>>>>>>>>> Sumit Pandit < >>>>> >>>>>> [hidden email]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>>> Sumit Pandit >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Jun 5, 2008, at 3:04 AM, >>>>>>>>>>>> >>>>>>>>>>> Jacques Le Roux wrote: >>>>> >>>>>> >>>>>>>>>>>> Yes this sounds good to me >>>>>>>>>>>> >>>>>>>>>>> too >>>>> >>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> From: "Bruno >>>>>>>>>>>>> >>>>>>>>>>>> Busco" <[hidden email]> >>>>> >>>>>> >>>>>>>>>>>>> Wonderfull !!!! >>>>>>>>>>>>> >>>>>>>>>>>>> Looking forward to having >>>>>>>>>>>>> >>>>>>>>>>>> it !!! ;-) >>>>> >>>>>> This will let me also >>>>>>>>>>>>>> >>>>>>>>>>>>> define a more granular permissions to >>>>> >>>>>> simplify >>>>>>>>>>>>>> the >>>>>>>>>>>>>> interface for >>>>>>>>>>>>>> >>>>>>>>>>>>> not-so-skilled users. >>>>> >>>>>> -Bruno >>>>>>>>>>>>>> 2008/6/4 Adrian Crum >>>>>>>>>>>>>> >>>>>>>>>>>>> <[hidden email]>: >>>>> >>>>>> >>>>>>>>>>>>>> In the screen >>>>>>>>>>>>>> >>>>>>>>>>>>> widgets, you can check permissions with the >>>>> >>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> <if-has-permission> or <if-service-permission> >>>>> elements. That's >>>>> >>>>>> fine >>>>>>>>>>>>>>> if >>>>>>>>>>>>>>> you >>>>>>>>>>>>>>> only need to check >>>>>>>>>>>>>>> >>>>>>>>>>>>>> a single permission to control access to the >>>>> >>>>>> entire >>>>>>>>>>>>>>> screen. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Things get >>>>>>>>>>>>>>> >>>>>>>>>>>>>> complicated when a screen's elements are controlled by >>>>> >>>>>> more >>>>>>>>>>>>>>> than >>>>>>>>>>>>>>> one permission. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Let's say you have a typical Edit Item screen. The >>>>> >>>>>> screen >>>>>>>>>>>>>>> should be viewable >>>>>>>>>>>>>>> >>>>>>>>>>>>>> only to users who have the VIEW permission. >>>>> >>>>>> Users >>>>>>>>>>>>>>> who >>>>>>>>>>>>>>> have the UPDATE >>>>>>>>>>>>>>> >>>>>>>>>>>>>> permission can edit the item. Users who have the >>>>> >>>>>> CREATE >>>>>>>>>>>>>>> permission see a >>>>>>>>>>>>>>> >>>>>>>>>>>>>> "New Item" button. Users who have DELETE >>>>> >>>>>> permission >>>>>>>>>>>>>>> see >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> "Delete >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Item" button. Users who have the ADMIN permission have >>>>> >>>>>> unrestricted >>>>>>>>>>>>>>> access to the >>>>>>>>>>>>>>> >>>>>>>>>>>>>> screen. Wow. Five permission elements (and five >>>>> >>>>>> service >>>>>>>>>>>>>>> calls) >>>>>>>>>>>>>>> are needed to >>>>>>>>>>>>>>> >>>>>>>>>>>>>> control one screen. >>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here's my >>>>>>>>>>>>>>> >>>>>>>>>>>>>> idea: have a permission service that returns ALL of the >>>>> >>>>>> user's >>>>>>>>>>>>>>> permissions in a >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Map. You call the service with the permission to >>>>> >>>>>> check >>>>>>>>>>>>>>> - >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "ACCOUNTING" for example. The service returns a >>>>> Map containing all >>>>> >>>>>> of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> user's >>>>>>>>>>>>>>> >>>>>>>>>>>>>> ACCOUNTING permissions stored as Boolean objects. Let's >>>>> say >>>>> >>>>>> the >>>>>>>>>>>>>>> returned Map is >>>>>>>>>>>>>>> >>>>>>>>>>>>>> called permissionsMap and the user has >>>>> >>>>>> ACCOUNTING_VIEW >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> ACCOUNTING_UPDATE >>>>>>>>>>>>>>> >>>>>>>>>>>>>> permissions, then the Map would contain these >>>>> >>>>>> elements: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> CREATE=false >>>>>>>>>>>>>>> UPDATE=true >>>>>>>>>>>>>>> DELETE=false >>>>>>>>>>>>>>> VIEW=true >>>>>>>>>>>>>>> ADMIN=false >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If the service >>>>>>>>>>>>>>> >>>>>>>>>>>>>> call is put in the screen's <actions> element, >>>>> then >>>>> >>>>>> the >>>>>>>>>>>>>>> Map >>>>>>>>>>>>>>> elements could be >>>>>>>>>>>>>>> >>>>>>>>>>>>>> used to control the display of screen widget >>>>> >>>>>> sections, >>>>>>>>>>>>>>> menu items, and >>>>>>>>>>>>>>> >>>>>>>>>>>>>> form fields. >>>>> >>>>>> >>>>>>>>>>>>>>> Freemarker code >>>>>>>>>>>>>>> >>>>>>>>>>>>>> would be simpler too: >>>>> >>>>>> >>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>> >>>>>>>>>>>>>> permissionsMap.CREATE> >>>>> >>>>>> <!-- Render a >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Create New button --> >>>>> >>>>>> </#if> >>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>> >>>>>>>>>>>>>> permissionsMap.DELETE> >>>>> >>>>>> <!-- Render a >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Delete button --> >>>>> >>>>>> </#if> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>> >>>> >>>> >>>> >>>> >> > |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
In reply to this post by Adrian Crum
I have another requirement : being able to dissalow acces to some pages for some users if a number of hits in a pre-defined period
of time is exceeded. I have an idea of how to do that but do you thing it could be interesting to be commited ? Maybe in a more generic way ? The purpose is security : this would prevent any kind of robot to pull out confidential data from the system. Thanks Jacques From: "Jacques Le Roux" <[hidden email]> > So refering to defintions in http://docs.ofbiz.org/display/OFBTECH/OFBiz+security this would be between the component menu level > and > the screen level (which use "<if-has-permission" and "<if-service-permission" tags), that's it ? > > It would be great to be able to hide menus as Bruno suggested (having a parameter in menu-item like David sugested for screens > def). It could be then named the menu level permission (we should then rename the component menu level to component level or even > application level) > > In a 1st and generic approach we could use 2 user categories : experts and novices. By default the expert mode would be used (all > shown OOTB) but users could change this in their preferences to novice mode. So this would need to define what novice could and > should not see in all OFBiz (and should be updated later, being visible by default). > > Later contributors could defines specific categories and they could be added to users's preferences choice. Could not roles be > used > for that or is it really orthogonal ? (customer service can't see some accounting screens, but are able to view some other etc.). > > My 2 cts > > Jacques > > From: "Bruno Busco" <[hidden email]> >> David, >> I like this idea. >> >> So we should add a screen property to specify a permission. >> The same permission should be checked to render the menu item that takes to >> that screen (sub-screen). >> Is this what you mean? >> >> This could be done even without the "getAllPermissions" service proposed, am >> I right? >> >> -Bruno >> >> >> >> 2008/12/3 David E Jones <[hidden email]> >> >>> >>> One option for this (or at least part of it), and one that I think has been >>> discussed before, would be to introduce a convention for naming permissions >>> (or more to the point, "ID-ing" permissions) based on screen names and >>> locations. A few aspects of this: >>> >>> 1. We could configure specific screens to always require the >>> screen-specific permission, or to require either a general permission >>> (probably specified in the screen def) or the screen-specific permission >>> >>> 2. this would be a view-only permission for rendering the screen >>> >>> 3. doing it for each screen defined would allow for permissions on >>> sub-screens and such as well >>> >>> -David >>> >>> >>> >>> On Nov 30, 2008, at 12:32 AM, Bruno Busco wrote: >>> >>> I need to simplify the UI has I described. >>>> To do this I think the Map should contain ALL user permissions, not >>>> restricted to a single application. >>>> Could we think to specific permissions to hide the TabBar options? >>>> >>>> I understand that OFBiz UI is designed to have ALL there because at least >>>> everybody sees that a feature is available but this creates a problem when >>>> deplying to end user. >>>> I understand also that the perfect UI is the one that reproduces the very >>>> specific users workflow and so it must be written ad hoc. >>>> But having an 80% fitting UI with only permissions setting (user >>>> profiling) >>>> could be a good result. >>>> >>>> This IMO is another key factor for spreading OFBiz and having more people >>>> using it. >>>> >>>> I would like to hear other idea about this and, possibly, some user >>>> profiling pattern ideas. >>>> For sure the Portlet system will help in this direction but could we think >>>> to a UI profiling through permission too? >>>> >>>> -Bruno >>>> >>>> 2008/11/30 Adrian Crum <[hidden email]> >>>> >>>> Bruno, >>>>> >>>>> I never got around to implementing that idea. I would still like to work >>>>> on >>>>> it though. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> --- On Sat, 11/29/08, Bruno Busco <[hidden email]> wrote: >>>>> >>>>> From: Bruno Busco <[hidden email]> >>>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>>> To: [hidden email] >>>>>> Date: Saturday, November 29, 2008, 10:30 AM >>>>>> Hi Adrian, >>>>>> I am thinking to something similar to what you proposed in >>>>>> this thread. >>>>>> What I would like to do is to simplify the UI to users who >>>>>> should not >>>>>> perform some operations. >>>>>> >>>>>> For instance, in the catalog application, when looking to >>>>>> the EditProduct >>>>>> screen, I would like that the following tabmenus: >>>>>> Geos, IDs, Keywords, Associations, Manufacturing, Costs, >>>>>> Attributes, >>>>>> Agreements, Accounts, Maintenance, Meters, Workefforts >>>>>> >>>>>> should not be visible to standard users while they should >>>>>> be visible to >>>>>> admin. >>>>>> >>>>>> I am thinking to implement several permissions (may be some >>>>>> are already >>>>>> there) and to check for them in the menu items. >>>>>> What do you think? >>>>>> Did you implement something about it? >>>>>> >>>>>> Thank you, >>>>>> -Bruno >>>>>> >>>>>> 2008/6/6 Adrian Crum <[hidden email]> >>>>>> >>>>>> Correct. >>>>>>> >>>>>>> >>>>>>> Bruno Busco wrote: >>>>>>> >>>>>>> Thank you, >>>>>>>> it make sense; so a CREATE permission check will >>>>>>>> >>>>>>> be sufficient for the >>>>>> >>>>>>> CREATE button rendering. >>>>>>>> -Bruno >>>>>>>> >>>>>>>> 2008/6/6 Adrian Crum <[hidden email]>: >>>>>>>> >>>>>>>> The pattern used so far is that the ADMIN >>>>>>>> >>>>>>> permission is checked first, >>>>>> >>>>>>> then >>>>>>>>> the other permissions. So if a user has the >>>>>>>>> >>>>>>>> ADMIN permission, they don't >>>>>> >>>>>>> need the additional permissions. >>>>>>>>> >>>>>>>>> I'll probably have all of the permissions >>>>>>>>> >>>>>>>> Map elements set to true if the >>>>>> >>>>>>> user has the ADMIN permission. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> Bruno Busco wrote: >>>>>>>>> >>>>>>>>> Adrian, >>>>>>>>> >>>>>>>>>> may be a newbie question but... >>>>>>>>>> ...in the example you give what will >>>>>>>>>> >>>>>>>>> happen if a user has the ADMIN >>>>>> >>>>>>> permission but not the CREATE one? >>>>>>>>>> Will the Create New button be rendered? >>>>>>>>>> >>>>>>>>>> In other words who is responsible for the >>>>>>>>>> >>>>>>>>> permission hierarchy ? >>>>>> >>>>>>> In order to display the CREATE button, >>>>>>>>>> >>>>>>>>> should a user be given with the >>>>>> >>>>>>> CREATE permission explicitly or the ADMIN >>>>>>>>>> >>>>>>>>> is sufficient? >>>>>> >>>>>>> >>>>>>>>>> Thank you >>>>>>>>>> -Bruno >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2008/6/6 Adrian Crum >>>>>>>>>> >>>>>>>>> <[hidden email]>: >>>>>> >>>>>>> >>>>>>>>>> I'll work on it this weekend. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ashish Vijaywargiya wrote: >>>>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>> Adrian I liked your idea. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 5, 2008 at 12:46 AM, >>>>>>>>>>>> >>>>>>>>>>> Sumit Pandit < >>>>>> >>>>>>> [hidden email]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>>> Sumit Pandit >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Jun 5, 2008, at 3:04 AM, >>>>>>>>>>>>> >>>>>>>>>>>> Jacques Le Roux wrote: >>>>>> >>>>>>> >>>>>>>>>>>>> Yes this sounds good to me >>>>>>>>>>>>> >>>>>>>>>>>> too >>>>>> >>>>>>> >>>>>>>>>>>>> Jacques >>>>>>>>>>>>> >>>>>>>>>>>>> From: "Bruno >>>>>>>>>>>>>> >>>>>>>>>>>>> Busco" <[hidden email]> >>>>>> >>>>>>> >>>>>>>>>>>>>> Wonderfull !!!! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Looking forward to having >>>>>>>>>>>>>> >>>>>>>>>>>>> it !!! ;-) >>>>>> >>>>>>> This will let me also >>>>>>>>>>>>>>> >>>>>>>>>>>>>> define a more granular permissions to >>>>>> >>>>>>> simplify >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> interface for >>>>>>>>>>>>>>> >>>>>>>>>>>>>> not-so-skilled users. >>>>>> >>>>>>> -Bruno >>>>>>>>>>>>>>> 2008/6/4 Adrian Crum >>>>>>>>>>>>>>> >>>>>>>>>>>>>> <[hidden email]>: >>>>>> >>>>>>> >>>>>>>>>>>>>>> In the screen >>>>>>>>>>>>>>> >>>>>>>>>>>>>> widgets, you can check permissions with the >>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <if-has-permission> or <if-service-permission> >>>>>> elements. That's >>>>>> >>>>>>> fine >>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>> only need to check >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> a single permission to control access to the >>>>>> >>>>>>> entire >>>>>>>>>>>>>>>> screen. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Things get >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> complicated when a screen's elements are controlled by >>>>>> >>>>>>> more >>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>> one permission. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Let's say you have a typical Edit Item screen. The >>>>>> >>>>>>> screen >>>>>>>>>>>>>>>> should be viewable >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> only to users who have the VIEW permission. >>>>>> >>>>>>> Users >>>>>>>>>>>>>>>> who >>>>>>>>>>>>>>>> have the UPDATE >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> permission can edit the item. Users who have the >>>>>> >>>>>>> CREATE >>>>>>>>>>>>>>>> permission see a >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "New Item" button. Users who have DELETE >>>>>> >>>>>>> permission >>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>> "Delete >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Item" button. Users who have the ADMIN permission have >>>>>> >>>>>>> unrestricted >>>>>>>>>>>>>>>> access to the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> screen. Wow. Five permission elements (and five >>>>>> >>>>>>> service >>>>>>>>>>>>>>>> calls) >>>>>>>>>>>>>>>> are needed to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> control one screen. >>>>>> >>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Here's my >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> idea: have a permission service that returns ALL of the >>>>>> >>>>>>> user's >>>>>>>>>>>>>>>> permissions in a >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Map. You call the service with the permission to >>>>>> >>>>>>> check >>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "ACCOUNTING" for example. The service returns a >>>>>> Map containing all >>>>>> >>>>>>> of >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> user's >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ACCOUNTING permissions stored as Boolean objects. Let's >>>>>> say >>>>>> >>>>>>> the >>>>>>>>>>>>>>>> returned Map is >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> called permissionsMap and the user has >>>>>> >>>>>>> ACCOUNTING_VIEW >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> ACCOUNTING_UPDATE >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> permissions, then the Map would contain these >>>>>> >>>>>>> elements: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CREATE=false >>>>>>>>>>>>>>>> UPDATE=true >>>>>>>>>>>>>>>> DELETE=false >>>>>>>>>>>>>>>> VIEW=true >>>>>>>>>>>>>>>> ADMIN=false >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the service >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> call is put in the screen's <actions> element, >>>>>> then >>>>>> >>>>>>> the >>>>>>>>>>>>>>>> Map >>>>>>>>>>>>>>>> elements could be >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> used to control the display of screen widget >>>>>> >>>>>>> sections, >>>>>>>>>>>>>>>> menu items, and >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> form fields. >>>>>> >>>>>>> >>>>>>>>>>>>>>>> Freemarker code >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> would be simpler too: >>>>>> >>>>>>> >>>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> permissionsMap.CREATE> >>>>>> >>>>>>> <!-- Render a >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Create New button --> >>>>>> >>>>>>> </#if> >>>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> permissionsMap.DELETE> >>>>>> >>>>>>> <!-- Render a >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Delete button --> >>>>>> >>>>>>> </#if> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>>> >>> >> > |
Re: Discussion: Permissions Checking Enhancement
|
|
Jacques:
my first reaction is if a robot can pull out confidential data then ofbiz would not pass the PCI audit. the focus should be to not allow log in to confidential data, unless a strict protocol is followed. The other is to find all the ways a hack can be done, like DOS that may also allow access into the system. SATAN (Security Administrator Tool for Analyzing Networks) (1990)test very thoroughly. using it as a basis of testing would further ofbiz. http://d4rk-c0de.org/2008/11/15/satan-securitry-administrator/. Jacques Le Roux sent the following on 12/5/2008 8:25 AM: > I have another requirement : being able to dissalow acces to some pages > for some users if a number of hits in a pre-defined period of time is > exceeded. I have an idea of how to do that but do you thing it could be > interesting to be commited ? Maybe in a more generic way ? > > The purpose is security : this would prevent any kind of robot to pull > out confidential data from the system. > > Thanks > > Jacques > > From: "Jacques Le Roux" <[hidden email]> >> So refering to defintions in >> http://docs.ofbiz.org/display/OFBTECH/OFBiz+security this would be >> between the component menu level and >> the screen level (which use "<if-has-permission" and >> "<if-service-permission" tags), that's it ? >> >> It would be great to be able to hide menus as Bruno suggested (having >> a parameter in menu-item like David sugested for screens >> def). It could be then named the menu level permission (we should >> then rename the component menu level to component level or even >> application level) >> >> In a 1st and generic approach we could use 2 user categories : experts >> and novices. By default the expert mode would be used (all >> shown OOTB) but users could change this in their preferences to novice >> mode. So this would need to define what novice could and >> should not see in all OFBiz (and should be updated later, being >> visible by default). >> >> Later contributors could defines specific categories and they could be >> added to users's preferences choice. Could not roles be used >> for that or is it really orthogonal ? (customer service can't see >> some accounting screens, but are able to view some other etc.). >> >> My 2 cts >> >> Jacques >> >> From: "Bruno Busco" <[hidden email]> >>> David, >>> I like this idea. >>> >>> So we should add a screen property to specify a permission. >>> The same permission should be checked to render the menu item that >>> takes to >>> that screen (sub-screen). >>> Is this what you mean? >>> >>> This could be done even without the "getAllPermissions" service >>> proposed, am >>> I right? >>> >>> -Bruno >>> >>> >>> >>> 2008/12/3 David E Jones <[hidden email]> >>> >>>> >>>> One option for this (or at least part of it), and one that I think >>>> has been >>>> discussed before, would be to introduce a convention for naming >>>> permissions >>>> (or more to the point, "ID-ing" permissions) based on screen names and >>>> locations. A few aspects of this: >>>> >>>> 1. We could configure specific screens to always require the >>>> screen-specific permission, or to require either a general permission >>>> (probably specified in the screen def) or the screen-specific >>>> permission >>>> >>>> 2. this would be a view-only permission for rendering the screen >>>> >>>> 3. doing it for each screen defined would allow for permissions on >>>> sub-screens and such as well >>>> >>>> -David >>>> >>>> >>>> >>>> On Nov 30, 2008, at 12:32 AM, Bruno Busco wrote: >>>> >>>> I need to simplify the UI has I described. >>>>> To do this I think the Map should contain ALL user permissions, not >>>>> restricted to a single application. >>>>> Could we think to specific permissions to hide the TabBar options? >>>>> >>>>> I understand that OFBiz UI is designed to have ALL there because at >>>>> least >>>>> everybody sees that a feature is available but this creates a >>>>> problem when >>>>> deplying to end user. >>>>> I understand also that the perfect UI is the one that reproduces >>>>> the very >>>>> specific users workflow and so it must be written ad hoc. >>>>> But having an 80% fitting UI with only permissions setting (user >>>>> profiling) >>>>> could be a good result. >>>>> >>>>> This IMO is another key factor for spreading OFBiz and having more >>>>> people >>>>> using it. >>>>> >>>>> I would like to hear other idea about this and, possibly, some user >>>>> profiling pattern ideas. >>>>> For sure the Portlet system will help in this direction but could >>>>> we think >>>>> to a UI profiling through permission too? >>>>> >>>>> -Bruno >>>>> >>>>> 2008/11/30 Adrian Crum <[hidden email]> >>>>> >>>>> Bruno, >>>>>> >>>>>> I never got around to implementing that idea. I would still like >>>>>> to work >>>>>> on >>>>>> it though. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> --- On Sat, 11/29/08, Bruno Busco <[hidden email]> wrote: >>>>>> >>>>>> From: Bruno Busco <[hidden email]> >>>>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>>>> To: [hidden email] >>>>>>> Date: Saturday, November 29, 2008, 10:30 AM >>>>>>> Hi Adrian, >>>>>>> I am thinking to something similar to what you proposed in >>>>>>> this thread. >>>>>>> What I would like to do is to simplify the UI to users who >>>>>>> should not >>>>>>> perform some operations. >>>>>>> >>>>>>> For instance, in the catalog application, when looking to >>>>>>> the EditProduct >>>>>>> screen, I would like that the following tabmenus: >>>>>>> Geos, IDs, Keywords, Associations, Manufacturing, Costs, >>>>>>> Attributes, >>>>>>> Agreements, Accounts, Maintenance, Meters, Workefforts >>>>>>> >>>>>>> should not be visible to standard users while they should >>>>>>> be visible to >>>>>>> admin. >>>>>>> >>>>>>> I am thinking to implement several permissions (may be some >>>>>>> are already >>>>>>> there) and to check for them in the menu items. >>>>>>> What do you think? >>>>>>> Did you implement something about it? >>>>>>> >>>>>>> Thank you, >>>>>>> -Bruno >>>>>>> >>>>>>> 2008/6/6 Adrian Crum <[hidden email]> >>>>>>> >>>>>>> Correct. >>>>>>>> >>>>>>>> >>>>>>>> Bruno Busco wrote: >>>>>>>> >>>>>>>> Thank you, >>>>>>>>> it make sense; so a CREATE permission check will >>>>>>>>> >>>>>>>> be sufficient for the >>>>>>> >>>>>>>> CREATE button rendering. >>>>>>>>> -Bruno >>>>>>>>> >>>>>>>>> 2008/6/6 Adrian Crum <[hidden email]>: >>>>>>>>> >>>>>>>>> The pattern used so far is that the ADMIN >>>>>>>>> >>>>>>>> permission is checked first, >>>>>>> >>>>>>>> then >>>>>>>>>> the other permissions. So if a user has the >>>>>>>>>> >>>>>>>>> ADMIN permission, they don't >>>>>>> >>>>>>>> need the additional permissions. >>>>>>>>>> >>>>>>>>>> I'll probably have all of the permissions >>>>>>>>>> >>>>>>>>> Map elements set to true if the >>>>>>> >>>>>>>> user has the ADMIN permission. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bruno Busco wrote: >>>>>>>>>> >>>>>>>>>> Adrian, >>>>>>>>>> >>>>>>>>>>> may be a newbie question but... >>>>>>>>>>> ...in the example you give what will >>>>>>>>>>> >>>>>>>>>> happen if a user has the ADMIN >>>>>>> >>>>>>>> permission but not the CREATE one? >>>>>>>>>>> Will the Create New button be rendered? >>>>>>>>>>> >>>>>>>>>>> In other words who is responsible for the >>>>>>>>>>> >>>>>>>>>> permission hierarchy ? >>>>>>> >>>>>>>> In order to display the CREATE button, >>>>>>>>>>> >>>>>>>>>> should a user be given with the >>>>>>> >>>>>>>> CREATE permission explicitly or the ADMIN >>>>>>>>>>> >>>>>>>>>> is sufficient? >>>>>>> >>>>>>>> >>>>>>>>>>> Thank you >>>>>>>>>>> -Bruno >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2008/6/6 Adrian Crum >>>>>>>>>>> >>>>>>>>>> <[hidden email]>: >>>>>>> >>>>>>>> >>>>>>>>>>> I'll work on it this weekend. >>>>>>>>>>> >>>>>>>>>>> -Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Ashish Vijaywargiya wrote: >>>>>>>>>>>> >>>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>>> Adrian I liked your idea. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jun 5, 2008 at 12:46 AM, >>>>>>>>>>>>> >>>>>>>>>>>> Sumit Pandit < >>>>>>> >>>>>>>> [hidden email]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> +1 >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>>> Sumit Pandit >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Jun 5, 2008, at 3:04 AM, >>>>>>>>>>>>>> >>>>>>>>>>>>> Jacques Le Roux wrote: >>>>>>> >>>>>>>> >>>>>>>>>>>>>> Yes this sounds good to me >>>>>>>>>>>>>> >>>>>>>>>>>>> too >>>>>>> >>>>>>>> >>>>>>>>>>>>>> Jacques >>>>>>>>>>>>>> >>>>>>>>>>>>>> From: "Bruno >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Busco" <[hidden email]> >>>>>>> >>>>>>>> >>>>>>>>>>>>>>> Wonderfull !!!! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looking forward to having >>>>>>>>>>>>>>> >>>>>>>>>>>>>> it !!! ;-) >>>>>>> >>>>>>>> This will let me also >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> define a more granular permissions to >>>>>>> >>>>>>>> simplify >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> interface for >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> not-so-skilled users. >>>>>>> >>>>>>>> -Bruno >>>>>>>>>>>>>>>> 2008/6/4 Adrian Crum >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <[hidden email]>: >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> In the screen >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> widgets, you can check permissions with the >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <if-has-permission> or <if-service-permission> >>>>>>> elements. That's >>>>>>> >>>>>>>> fine >>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>> only need to check >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> a single permission to control access to the >>>>>>> >>>>>>>> entire >>>>>>>>>>>>>>>>> screen. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Things get >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> complicated when a screen's elements are controlled by >>>>>>> >>>>>>>> more >>>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>> one permission. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Let's say you have a typical Edit Item screen. The >>>>>>> >>>>>>>> screen >>>>>>>>>>>>>>>>> should be viewable >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> only to users who have the VIEW permission. >>>>>>> >>>>>>>> Users >>>>>>>>>>>>>>>>> who >>>>>>>>>>>>>>>>> have the UPDATE >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> permission can edit the item. Users who have the >>>>>>> >>>>>>>> CREATE >>>>>>>>>>>>>>>>> permission see a >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "New Item" button. Users who have DELETE >>>>>>> >>>>>>>> permission >>>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>> "Delete >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Item" button. Users who have the ADMIN permission have >>>>>>> >>>>>>>> unrestricted >>>>>>>>>>>>>>>>> access to the >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> screen. Wow. Five permission elements (and five >>>>>>> >>>>>>>> service >>>>>>>>>>>>>>>>> calls) >>>>>>>>>>>>>>>>> are needed to >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> control one screen. >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Here's my >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> idea: have a permission service that returns ALL of the >>>>>>> >>>>>>>> user's >>>>>>>>>>>>>>>>> permissions in a >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Map. You call the service with the permission to >>>>>>> >>>>>>>> check >>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "ACCOUNTING" for example. The service returns a >>>>>>> Map containing all >>>>>>> >>>>>>>> of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> user's >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ACCOUNTING permissions stored as Boolean objects. Let's >>>>>>> say >>>>>>> >>>>>>>> the >>>>>>>>>>>>>>>>> returned Map is >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> called permissionsMap and the user has >>>>>>> >>>>>>>> ACCOUNTING_VIEW >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> ACCOUNTING_UPDATE >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> permissions, then the Map would contain these >>>>>>> >>>>>>>> elements: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> CREATE=false >>>>>>>>>>>>>>>>> UPDATE=true >>>>>>>>>>>>>>>>> DELETE=false >>>>>>>>>>>>>>>>> VIEW=true >>>>>>>>>>>>>>>>> ADMIN=false >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If the service >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> call is put in the screen's <actions> element, >>>>>>> then >>>>>>> >>>>>>>> the >>>>>>>>>>>>>>>>> Map >>>>>>>>>>>>>>>>> elements could be >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> used to control the display of screen widget >>>>>>> >>>>>>>> sections, >>>>>>>>>>>>>>>>> menu items, and >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> form fields. >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> Freemarker code >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> would be simpler too: >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> permissionsMap.CREATE> >>>>>>> >>>>>>>> <!-- Render a >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Create New button --> >>>>>>> >>>>>>>> </#if> >>>>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> permissionsMap.DELETE> >>>>>>> >>>>>>>> <!-- Render a >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Delete button --> >>>>>>> >>>>>>>> </#if> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >> > > > |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
BJ,
The client concern is in case a login/pwd couple is used but not by the right person (lost, stolen, etc.). Only biometric security could deal with that I guess. By limiting the number of time a page can be visited in a period of time you don't really prevent using UI to pull out confidential data but you make it so long (years) that it's not usable. It's something used in spam fighting known as tarpitting. It has proven to be very efficient and is now used in the gray list concept wich works great. Anyway for the moment it's the requirement I have BTW I wonder if it should not better block the account and send a message to the admin in such case. He/she would then be able to reset the login/pwd to secure anew the login. I will put the check in at end of RequestHandler.renderView just after the block where ServerHitBin.countView is used. This would clearly separate this new security aspect. And having it at the framework level is clearly easier : you only have to define a list of pages to constrain by PartyRoles. In the check I will need . PartyRole(s), . The list of pages to constrain access by PartyRoles. I will be an ConstrainViewByRole entity with 2 fields : partyRole viewName (pages are actually views in OFBiz) . Max number of page access allowed, and the period of time for counting the number of page accesses in security.properties . An AccessedPage entity with fields loginId viewAccessed dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) I think it's a feature generic enough to be used in Framework if someone is interested in future (if nothing is defined in security.properties the block would be simply skipped so it's harmful). So if nobody see a problem with that I will implement and commit. Any comments welcome Thanks Jacques From: "BJ Freeman" <[hidden email]> > Jacques: > my first reaction is if a robot can pull out confidential data then > ofbiz would not pass the PCI audit. > > > the focus should be to not allow log in to confidential data, unless a > strict protocol is followed. > > The other is to find all the ways a hack can be done, like DOS that may > also allow access into the system. > > SATAN (Security Administrator Tool for Analyzing Networks) (1990)test > very thoroughly. using it as a basis of testing would further ofbiz. > http://d4rk-c0de.org/2008/11/15/satan-securitry-administrator/. > > > Jacques Le Roux sent the following on 12/5/2008 8:25 AM: >> I have another requirement : being able to dissalow acces to some pages >> for some users if a number of hits in a pre-defined period of time is >> exceeded. I have an idea of how to do that but do you thing it could be >> interesting to be commited ? Maybe in a more generic way ? >> >> The purpose is security : this would prevent any kind of robot to pull >> out confidential data from the system. >> >> Thanks >> >> Jacques >> >> From: "Jacques Le Roux" <[hidden email]> >>> So refering to defintions in >>> http://docs.ofbiz.org/display/OFBTECH/OFBiz+security this would be >>> between the component menu level and >>> the screen level (which use "<if-has-permission" and >>> "<if-service-permission" tags), that's it ? >>> >>> It would be great to be able to hide menus as Bruno suggested (having >>> a parameter in menu-item like David sugested for screens >>> def). It could be then named the menu level permission (we should >>> then rename the component menu level to component level or even >>> application level) >>> >>> In a 1st and generic approach we could use 2 user categories : experts >>> and novices. By default the expert mode would be used (all >>> shown OOTB) but users could change this in their preferences to novice >>> mode. So this would need to define what novice could and >>> should not see in all OFBiz (and should be updated later, being >>> visible by default). >>> >>> Later contributors could defines specific categories and they could be >>> added to users's preferences choice. Could not roles be used >>> for that or is it really orthogonal ? (customer service can't see >>> some accounting screens, but are able to view some other etc.). >>> >>> My 2 cts >>> >>> Jacques >>> >>> From: "Bruno Busco" <[hidden email]> >>>> David, >>>> I like this idea. >>>> >>>> So we should add a screen property to specify a permission. >>>> The same permission should be checked to render the menu item that >>>> takes to >>>> that screen (sub-screen). >>>> Is this what you mean? >>>> >>>> This could be done even without the "getAllPermissions" service >>>> proposed, am >>>> I right? >>>> >>>> -Bruno >>>> >>>> >>>> >>>> 2008/12/3 David E Jones <[hidden email]> >>>> >>>>> >>>>> One option for this (or at least part of it), and one that I think >>>>> has been >>>>> discussed before, would be to introduce a convention for naming >>>>> permissions >>>>> (or more to the point, "ID-ing" permissions) based on screen names and >>>>> locations. A few aspects of this: >>>>> >>>>> 1. We could configure specific screens to always require the >>>>> screen-specific permission, or to require either a general permission >>>>> (probably specified in the screen def) or the screen-specific >>>>> permission >>>>> >>>>> 2. this would be a view-only permission for rendering the screen >>>>> >>>>> 3. doing it for each screen defined would allow for permissions on >>>>> sub-screens and such as well >>>>> >>>>> -David >>>>> >>>>> >>>>> >>>>> On Nov 30, 2008, at 12:32 AM, Bruno Busco wrote: >>>>> >>>>> I need to simplify the UI has I described. >>>>>> To do this I think the Map should contain ALL user permissions, not >>>>>> restricted to a single application. >>>>>> Could we think to specific permissions to hide the TabBar options? >>>>>> >>>>>> I understand that OFBiz UI is designed to have ALL there because at >>>>>> least >>>>>> everybody sees that a feature is available but this creates a >>>>>> problem when >>>>>> deplying to end user. >>>>>> I understand also that the perfect UI is the one that reproduces >>>>>> the very >>>>>> specific users workflow and so it must be written ad hoc. >>>>>> But having an 80% fitting UI with only permissions setting (user >>>>>> profiling) >>>>>> could be a good result. >>>>>> >>>>>> This IMO is another key factor for spreading OFBiz and having more >>>>>> people >>>>>> using it. >>>>>> >>>>>> I would like to hear other idea about this and, possibly, some user >>>>>> profiling pattern ideas. >>>>>> For sure the Portlet system will help in this direction but could >>>>>> we think >>>>>> to a UI profiling through permission too? >>>>>> >>>>>> -Bruno >>>>>> >>>>>> 2008/11/30 Adrian Crum <[hidden email]> >>>>>> >>>>>> Bruno, >>>>>>> >>>>>>> I never got around to implementing that idea. I would still like >>>>>>> to work >>>>>>> on >>>>>>> it though. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> --- On Sat, 11/29/08, Bruno Busco <[hidden email]> wrote: >>>>>>> >>>>>>> From: Bruno Busco <[hidden email]> >>>>>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>>>>> To: [hidden email] >>>>>>>> Date: Saturday, November 29, 2008, 10:30 AM >>>>>>>> Hi Adrian, >>>>>>>> I am thinking to something similar to what you proposed in >>>>>>>> this thread. >>>>>>>> What I would like to do is to simplify the UI to users who >>>>>>>> should not >>>>>>>> perform some operations. >>>>>>>> >>>>>>>> For instance, in the catalog application, when looking to >>>>>>>> the EditProduct >>>>>>>> screen, I would like that the following tabmenus: >>>>>>>> Geos, IDs, Keywords, Associations, Manufacturing, Costs, >>>>>>>> Attributes, >>>>>>>> Agreements, Accounts, Maintenance, Meters, Workefforts >>>>>>>> >>>>>>>> should not be visible to standard users while they should >>>>>>>> be visible to >>>>>>>> admin. >>>>>>>> >>>>>>>> I am thinking to implement several permissions (may be some >>>>>>>> are already >>>>>>>> there) and to check for them in the menu items. >>>>>>>> What do you think? >>>>>>>> Did you implement something about it? >>>>>>>> >>>>>>>> Thank you, >>>>>>>> -Bruno >>>>>>>> >>>>>>>> 2008/6/6 Adrian Crum <[hidden email]> >>>>>>>> >>>>>>>> Correct. >>>>>>>>> >>>>>>>>> >>>>>>>>> Bruno Busco wrote: >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>>> it make sense; so a CREATE permission check will >>>>>>>>>> >>>>>>>>> be sufficient for the >>>>>>>> >>>>>>>>> CREATE button rendering. >>>>>>>>>> -Bruno >>>>>>>>>> >>>>>>>>>> 2008/6/6 Adrian Crum <[hidden email]>: >>>>>>>>>> >>>>>>>>>> The pattern used so far is that the ADMIN >>>>>>>>>> >>>>>>>>> permission is checked first, >>>>>>>> >>>>>>>>> then >>>>>>>>>>> the other permissions. So if a user has the >>>>>>>>>>> >>>>>>>>>> ADMIN permission, they don't >>>>>>>> >>>>>>>>> need the additional permissions. >>>>>>>>>>> >>>>>>>>>>> I'll probably have all of the permissions >>>>>>>>>>> >>>>>>>>>> Map elements set to true if the >>>>>>>> >>>>>>>>> user has the ADMIN permission. >>>>>>>>>>> >>>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Bruno Busco wrote: >>>>>>>>>>> >>>>>>>>>>> Adrian, >>>>>>>>>>> >>>>>>>>>>>> may be a newbie question but... >>>>>>>>>>>> ...in the example you give what will >>>>>>>>>>>> >>>>>>>>>>> happen if a user has the ADMIN >>>>>>>> >>>>>>>>> permission but not the CREATE one? >>>>>>>>>>>> Will the Create New button be rendered? >>>>>>>>>>>> >>>>>>>>>>>> In other words who is responsible for the >>>>>>>>>>>> >>>>>>>>>>> permission hierarchy ? >>>>>>>> >>>>>>>>> In order to display the CREATE button, >>>>>>>>>>>> >>>>>>>>>>> should a user be given with the >>>>>>>> >>>>>>>>> CREATE permission explicitly or the ADMIN >>>>>>>>>>>> >>>>>>>>>>> is sufficient? >>>>>>>> >>>>>>>>> >>>>>>>>>>>> Thank you >>>>>>>>>>>> -Bruno >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2008/6/6 Adrian Crum >>>>>>>>>>>> >>>>>>>>>>> <[hidden email]>: >>>>>>>> >>>>>>>>> >>>>>>>>>>>> I'll work on it this weekend. >>>>>>>>>>>> >>>>>>>>>>>> -Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Ashish Vijaywargiya wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> +1 >>>>>>>>>>>>> >>>>>>>>>>>>> Adrian I liked your idea. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Jun 5, 2008 at 12:46 AM, >>>>>>>>>>>>>> >>>>>>>>>>>>> Sumit Pandit < >>>>>>>> >>>>>>>>> [hidden email]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> +1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sumit Pandit >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Jun 5, 2008, at 3:04 AM, >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Jacques Le Roux wrote: >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> Yes this sounds good to me >>>>>>>>>>>>>>> >>>>>>>>>>>>>> too >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> Jacques >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From: "Bruno >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Busco" <[hidden email]> >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>> Wonderfull !!!! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Looking forward to having >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> it !!! ;-) >>>>>>>> >>>>>>>>> This will let me also >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> define a more granular permissions to >>>>>>>> >>>>>>>>> simplify >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> interface for >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> not-so-skilled users. >>>>>>>> >>>>>>>>> -Bruno >>>>>>>>>>>>>>>>> 2008/6/4 Adrian Crum >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <[hidden email]>: >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>>> In the screen >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> widgets, you can check permissions with the >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <if-has-permission> or <if-service-permission> >>>>>>>> elements. That's >>>>>>>> >>>>>>>>> fine >>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>> only need to check >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> a single permission to control access to the >>>>>>>> >>>>>>>>> entire >>>>>>>>>>>>>>>>>> screen. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Things get >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> complicated when a screen's elements are controlled by >>>>>>>> >>>>>>>>> more >>>>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>>> one permission. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Let's say you have a typical Edit Item screen. The >>>>>>>> >>>>>>>>> screen >>>>>>>>>>>>>>>>>> should be viewable >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> only to users who have the VIEW permission. >>>>>>>> >>>>>>>>> Users >>>>>>>>>>>>>>>>>> who >>>>>>>>>>>>>>>>>> have the UPDATE >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> permission can edit the item. Users who have the >>>>>>>> >>>>>>>>> CREATE >>>>>>>>>>>>>>>>>> permission see a >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "New Item" button. Users who have DELETE >>>>>>>> >>>>>>>>> permission >>>>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>> "Delete >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Item" button. Users who have the ADMIN permission have >>>>>>>> >>>>>>>>> unrestricted >>>>>>>>>>>>>>>>>> access to the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> screen. Wow. Five permission elements (and five >>>>>>>> >>>>>>>>> service >>>>>>>>>>>>>>>>>> calls) >>>>>>>>>>>>>>>>>> are needed to >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> control one screen. >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Here's my >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> idea: have a permission service that returns ALL of the >>>>>>>> >>>>>>>>> user's >>>>>>>>>>>>>>>>>> permissions in a >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Map. You call the service with the permission to >>>>>>>> >>>>>>>>> check >>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> "ACCOUNTING" for example. The service returns a >>>>>>>> Map containing all >>>>>>>> >>>>>>>>> of >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> user's >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ACCOUNTING permissions stored as Boolean objects. Let's >>>>>>>> say >>>>>>>> >>>>>>>>> the >>>>>>>>>>>>>>>>>> returned Map is >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> called permissionsMap and the user has >>>>>>>> >>>>>>>>> ACCOUNTING_VIEW >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> ACCOUNTING_UPDATE >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> permissions, then the Map would contain these >>>>>>>> >>>>>>>>> elements: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> CREATE=false >>>>>>>>>>>>>>>>>> UPDATE=true >>>>>>>>>>>>>>>>>> DELETE=false >>>>>>>>>>>>>>>>>> VIEW=true >>>>>>>>>>>>>>>>>> ADMIN=false >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If the service >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> call is put in the screen's <actions> element, >>>>>>>> then >>>>>>>> >>>>>>>>> the >>>>>>>>>>>>>>>>>> Map >>>>>>>>>>>>>>>>>> elements could be >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> used to control the display of screen widget >>>>>>>> >>>>>>>>> sections, >>>>>>>>>>>>>>>>>> menu items, and >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> form fields. >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>>>> Freemarker code >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> would be simpler too: >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> permissionsMap.CREATE> >>>>>>>> >>>>>>>>> <!-- Render a >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Create New button --> >>>>>>>> >>>>>>>>> </#if> >>>>>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> permissionsMap.DELETE> >>>>>>>> >>>>>>>>> <!-- Render a >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Delete button --> >>>>>>>> >>>>>>>>> </#if> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> >> >> > |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
In reply to this post by Adrian Crum
Some afterthoughts
From: "Jacques Le Roux" <[hidden email]> > BJ, > > The client concern is in case a login/pwd couple is used but not by the right person (lost, stolen, etc.). Only biometric security > could deal with that I guess. > > By limiting the number of time a page can be visited in a period of time you don't really prevent using UI to pull out > confidential > data but you make it so long (years) that it's not usable. It's something used in spam fighting known as tarpitting. It has proven > to be very efficient and is now used in the gray list concept wich works great. Anyway for the moment it's the requirement I have > BTW I wonder if it should not better block the account and send a message to the admin in such case. He/she would then be able to > reset the login/pwd to secure anew the login. > > I will put the check in at end of RequestHandler.renderView just after the block where ServerHitBin.countView is used. This would > clearly separate this new security aspect. And having it at the framework level is clearly easier : you only have to define a list > of pages to constrain by PartyRoles. Actually it rather should be in RequestHandler.doRequest. Just after the first visit block using an else block. In case a limit would be reached the eventReturnString would be "lock" and a "lock" response used if present. Then a view would be rendered or more certainly a request chained to deal with other aspect like sending an email to the admin and finally a view. Ray, who is also involved in this feature, suggested to use an event. This of course would avoid core framework changes. But I can't see how to use an event if a required even is already in place. > In the check I will need > . PartyRole(s), > . The list of pages to constrain access by PartyRoles. I will be an ConstrainViewByRole entity with 2 fields : partyRole viewName > (pages are actually views in OFBiz) > . Max number of page access allowed, and the period of time for counting the number of page accesses in security.properties Ray suggested to put also these 2 parameters in the ConstrainViewByRole entity. This would allow a more finely grained solution. So the fields would be partyRole, viewName, maxViewAllowed and maxViewAllowedDuration > . An AccessedPage entity with fields loginId viewAccessed dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) > I think it's a feature generic enough to be used in Framework if someone is interested in future (if nothing is defined in > security.properties the block would be simply skipped so it's harmful). So if nobody see a problem with that I will implement and > commit. Any comments welcome I replace "if nothing is defined in security.properties the block would be simply skipped" by "if nothing is defined in ConstrainViewByRole for the current view the block would be simply skipped" Jacques > Thanks > > Jacques > > From: "BJ Freeman" <[hidden email]> >> Jacques: >> my first reaction is if a robot can pull out confidential data then >> ofbiz would not pass the PCI audit. >> >> >> the focus should be to not allow log in to confidential data, unless a >> strict protocol is followed. >> >> The other is to find all the ways a hack can be done, like DOS that may >> also allow access into the system. >> >> SATAN (Security Administrator Tool for Analyzing Networks) (1990)test >> very thoroughly. using it as a basis of testing would further ofbiz. >> http://d4rk-c0de.org/2008/11/15/satan-securitry-administrator/. >> >> >> Jacques Le Roux sent the following on 12/5/2008 8:25 AM: >>> I have another requirement : being able to dissalow acces to some pages >>> for some users if a number of hits in a pre-defined period of time is >>> exceeded. I have an idea of how to do that but do you thing it could be >>> interesting to be commited ? Maybe in a more generic way ? >>> >>> The purpose is security : this would prevent any kind of robot to pull >>> out confidential data from the system. >>> >>> Thanks >>> >>> Jacques |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |