I agree that ultimately the access needs to be controlled at the service tier
rather than woven into presentation but I think i created a diversion by
mentioning security in with this issue.
What I'm more keen to investigate is a neat way to have multiple flavours of
the same functionality and for a ui app to be capable of satisfying the
needs of different types of users but without that necessarily being
permissions based, more based around what is the view that is relevant for a
type (role). I'm saying 'role' here because I'd see that as simplest way to
group users together given that we would have those roles available in
whatever security solution is chosen for sculptor.
To date I've played with lockdown of functionailty using regular JEE
declarative authorisation via url-patterns and JEE roles described inside
web.xml - i completely agree thats not the total solution for authorisation
but it gives me a way to move forward now with current version of sculptor.
Using that approach i can lock down flows as needed but more to the point
I'm logically assigning some flows as being relevant particular roles
(irrespective of what data content is visible).
The example i gave was probably too simplistic but just say we had two
different types of admin, one concerned with male persons and one with
female persons. They both maybe needed to occasionaly look at detail of the
opposite sex (so they are permitted to look at the other data) but in
general they wanted a ListPerson to list only persons of the sex relevant to
them. You see what I'm after is for a way to do the option like
ListTask [male-admin] for Person { ..
searchWith PersonService.findAllMales
ListTask [female-admin] for Person { ..
searchWith PersonService.findAllFemales
as well as a 'default' for those users who aren't so 'focussed'
ListTask for Person { ..
A webapp may have all of the above available together and optionally to be
used by any users as they see fit. This highlighting the point that a UI
could be needed to expose multiple ways to want presentation of the same UI
'tasks' ie. sharing of control logic for different 'views.
Another thought though to enable grouping of those 'related' tasks (eg. to
enable simple generation of a male-admin menu as distinct from a female
admin menu) would be to enable naming of multiple sculptor 'modules' be
defined within a single 'gui' (at present it doesn't look like they can be
named, just each being 'for' an underlying domain module). That could be a
simplistic way to enable the generation and would be especially neat for
partitioning the entire gui into role-relevant spaces.
eg.
Module male-admin for milkyway { ..
ListTask for Person { ..
searchWith PersonService.findAllMales
Module female-admin for milkyway { ..
ListTask for Person { ..
searchWith PersonService.findAllFemales
or maybe something similar could done up at defn of the 'gui' - though i'd
expect that would tend to head us toward mutiple webapps as opposed to
side-by-side modules inside a single webapp. Also obviously that last one
could be achieved by simply defining multiple discrete gui's - which
incidentally seems like the way i might head with this stuff in the
short-term.
Thanks heaps for your feedback guys - also should say the acegi/spring
security will be great to have so pls don't misinterpret my comments above,
just that my burning need is a way to re-use various UI tasks
PaloT wrote:
>
> Some of my ideas:
> - we have to consider supporting security on different levels:
> - Service access (easy with Spring security and annotations or xml
> config)
> - Column access (read, write, search privileges)
> - Row access (read, write, delete, create privileges)
>
> Row access:
> Should be done in user code in services (find, save, ...).
>
> Column access:
> With existing paging support isn't problem to simply nullify columns
> in find service which can't be accessed by some users. I don't know if
> hibernate somehow directly support this.
>
> My opinion is that you HAVE TO implement security on service tier not
> VISUAL tier. Of course hiding columns for visualization purpose is
> good feature.
>
> I guess you need "hint" feature also for Sculptor GUI because with:
> ListTask for Person {
> name.first
> birthDate hints="role=admin, advisor"
> ssn hints="role=advisor, accountant"
> sex
> }
> and little tweak in SpecialCases you will be done ;-).
>
> Security is difficult because you can SLOW down your application too
> much. That's why on this level is usually custom build.
>
> Regards
>
> Pavel
>
> 2010/4/21 Andreas Källberg <andreas.kallb...@gmail.com>:
>> Hi,
>> Nice suggestions, but you are a bit ahead of us here.
>> There is plans for supporting authentication and authorization. When that
>> is
>> in place it would be nice to have dsl support for user roles.
>> I guess it also could be possible to have multiple variations of tasks,
>> i.e:
>> ListTask for Person {
>> name.first
>> sex
>> }
>> ListTask [admin] for Person {
>> name.first
>> birthDate
>> ssn
>> sex
>> }
>>
>> But it isn't something we have discussed
>> If you feel it is something we should consider, think it through and add
>> a
>> suggestion in the tracker.
>>
>> .../Andreas
>>
>> On Wed, Apr 21, 2010 at 1:31 PM, greatfooty <greatfo...@gmail.com> wrote:
>>>
>>> I'm playing with setup of a sculptor site to contain multiple versions
>>> of
>>> various UI task-types (these to be invoked depending on auth role of the
>>> user).
>>>
>>> For example I'd want to define a 'public' ListTask for Person like
>>> this:
>>>
>>> ListTask for Person {
>>> name.first
>>> sex
>>> }
>>>
>>> and an 'admin' ListTask for Person like this:
>>>
>>> ListTask for Person {
>>> name.first
>>> birthDate
>>> sex
>>> ssn
>>> }
>>>
>>> Thats a simple example and obviously i can achieve this particular one
>>> by
>>> doing say role-based suppression of output within the list_include.html
>>> but
>>> there can be many more complex examples where declarative definition in
>>> the
>>> DSL would be way easier.
>>>
>>> Is there already any way to do this? eg. maybe some hidden DSL options
>>> for
>>> naming tasks??
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/-Sculptor--Multiple-UI-tasks-per-%27task-type%27--tp28288008s17564p28288008.html
>>> Sent from the Fornax-Platform mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Fornax-developer mailing list
>>> Fornax-developer@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Fornax-developer mailing list
>> Fornax-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>>
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Fornax-developer mailing list
> Fornax-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>
>
--
View this message in context:
http://old.nabble.com/-Sculptor--Multiple-UI-tasks-per-%27task-type%27--tp28288008s17564p28323801.html
Sent from the Fornax-Platform mailing list archive at Nabble.com.
------------------------------------------------------------------------------
_______________________________________________
Fornax-developer mailing list
Fornax-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fornax-developer
