Field level Authorization strategy suggestions?

[David Nedrow-3]

I'm building a database driven application.

I've constructed LoadableDetachableModel for my entities, those LDMs  
then being presented in a Panel via  a SortableDataProvider driven  
DefaultDataTable.

I'd like to automatically expose additional functionality or field  
visibility depending on the authorization level of the user (session).  
For example, editable fields for "admin" users.

At which point is it most appropriate to handle that? Should I somehow  
construct field(column) level models and encapsulate those in a higher-
level model?

Has anyone done something similar or is there an example somewhere  
that I'm overlooking?

-David

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mr Mean]

Well, there are a couple directions you can take.

1 If the number of "admin" fields is relatively small you could try
grouping those fields together in a panel for each page that has these
admin fields and then simply apply your security to the panel instead
of to the individual fields. (Works best with handful of fields)
2 If you only have 1 or 2 "admin" fields/components on a given page
you could apply the security directly to those components.
3 If you want complete control over every field, it might be a good
idea to use a special model.
4 Use a customized propertycolumn and use the field expression to
check for the appropriate permissions

For all of the above you can use swarm.
http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security
Options 1 and 2 can be handled with common secure components.
Option 1 is not really relevant in a datatable but is for other types of pages.
Option 2 might involve wrapping the secure components in a customized column.
For option 3 you might want to take a look at the
SwarmCompoundPropertyModel, in a datatable you probably want to have a
similar model returned by your dataprovider.
Option 4 involves using a securemodel (like
SwarmCompoundPropertyModel) in your column instead of the default
propertymodel.

Well these are just some initial thoughts on how you could accomplish
this. Feel free to ask if you have some more questions.

Maurice

On Sat, Jul 19, 2008 at 12:13 AM, David Nedrow <dnedrow@...> wrote:

> I'm building a database driven application.
>
> I've constructed LoadableDetachableModel for my entities, those LDMs then
> being presented in a Panel via  a SortableDataProvider driven
> DefaultDataTable.
>
> I'd like to automatically expose additional functionality or field
> visibility depending on the authorization level of the user (session). For
> example, editable fields for "admin" users.
>
> At which point is it most appropriate to handle that? Should I somehow
> construct field(column) level models and encapsulate those in a higher-level
> model?
>
> Has anyone done something similar or is there an example somewhere that I'm
> overlooking?
>
> -David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Gabor Szokoli]

Hi,

On Sat, Jul 19, 2008 at 12:13 AM, David Nedrow <dnedrow@...> wrote:
> I'd like to automatically expose additional functionality or field
> visibility depending on the authorization level of the user (session). For
> example, editable fields for "admin" users.
> [...]
> Has anyone done something similar or is there an example somewhere that I'm
> overlooking?

We have an application with similar features. We had to disable and
skip components instead of columns, but the principle might be
relevant:

We created custom components for all form field types we use
(textfield, dropdown, radiochioce, etc.)
The component consists of an "editable" and a "read-only" variant of
the underlying control, but only one or the other is visible depending
on the "enabled" flag of the composite component. (unauthorised users
wouldn't be much interested in what they can not set a radiochoice
field to for example. Disabled textfields are hard to copy-paste
from.)
The "visible" flag is obeyed too. (the markup is a bit nasty because
of this: the form is a table, and the components are table rows so
they can be omitted without visual glitches. Shouldn't be a problem
with table rows.)

We also added convenience constructors to the components, passing the
"enabled" and "visible" flags, matching with convenience service
methods on the logged in user meeting authorisation criteria.

Here we are implicitly relying on wicket being "safe" in the sense
that no client side forgery can result in the activation of a missing
or disabled component. (all operations are double-checked in the
service layer nonetheless.)

We didn't use wicket-auth-roles because the categories were too simple
at first (but then project scope drift started...)

You'll have to substitute table columns for components, it already has
isVisible, and you can just add isEnabled.


Hope it helps!

Gabor Szokoli

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...