Mailing-List: contact users-help@isis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@isis.apache.org
MIME-Version: 1.0
References: <CAG=ut6KTmSH5nSPGL95j6WLm71D1Nmv9hjntyBvasns=yGqftw@mail.gmail.com>
 <1E2EF628-D16C-44BB-89FA-761578694FA7@kmz.co.za> <CAG=ut6JiLJ-G1Ud=1qWvHjMs2i_U3n0-oSkeaD59TLb6Owfj9w@mail.gmail.com>
In-Reply-To: <CAG=ut6JiLJ-G1Ud=1qWvHjMs2i_U3n0-oSkeaD59TLb6Owfj9w@mail.gmail.com>
From: Dan Haywood <dan@haywood-associates.co.uk>
Date: Thu, 24 Aug 2017 08:34:04 +0000
Message-ID: <CALJOYLHgj5ckahYPm2ujHJj8UCiMN8XFfgdj4z4AxzPhuSb=mA@mail.gmail.com>
Subject: Re: Can I make a specific class instance editable, all others not?
To: users@isis.apache.org
Content-Type: multipart/alternative; boundary="001a1135df1a9d8b6c05577bb144"
archived-at: Thu, 24 Aug 2017 08:34:23 -0000

--001a1135df1a9d8b6c05577bb144
Content-Type: text/plain; charset="UTF-8"

Hi Steve,
As you point out, the user/role/permissions system of the security module
is class-based, not instance-based.

However, the security module also supports application tenancies.  So you
could support these use case by defining an ApplicationTenancy for each
user, and then associating their ApplicatoinUser with that same
ApplicationTenancy.

For example,

ApplicationUser "bill" has associated ApplicationTenancy "/people/bill"
ApplicationUser "mary" has associated ApplicationTenancy "/people/mary"
ApplicationUser "superuser" has associated ApplicationTenancy "/"  (global)

The out-of-the box ApplicationTenancyEvaluator would prevent bill from even
seeing mary's user, and vice-versa, while "superuser" would be able to see
and modify both.  However, you can provide a custom implementation of an
evaluator that could do any other rules.

One limitation of the security module is that ApplicationTenancy is an
entity, so you will end up with these extra objects.  We've been discussing
simply dropping this entity, so that a application tenancy path ("atPath")
is simply a label.

~~
An alternative approach would be to implement some sort of subscriber that
would veto all edits for each user unless they are looking at their own
object.  you can use the security module's MeService for that, I think (or
Isis' UserService otherwise).

HTH
Dan


On Thu, 24 Aug 2017 at 08:54 Stephen Cameron <steve.cameron.62@gmail.com>
wrote:

> On Thu, Aug 24, 2017 at 4:17 PM, Kevin Meyer <kevin@kmz.co.za> wrote:
>
> > Hi Steve,
> >
> > Why not use the isis-addons security module to only authorise users to
> > edit their own profile?
> >
>
> Oh, apologies, that is what I am using, but I think that if you have
> permission to edit your own profile you can edit anyones if you get access
> to it. The editing permission is on that class.
>
> I am using the MyApplicationUser class to represent people in my domain
> model, so that leads to the problem. But I want to have people self
> register (which the security module provides) and then optionally be given
> extra roles to enable them to do more than just edit their own profile.
>
>
> > In the past, I have implemented such security directly in the domain
> > objects by using the isVisible() and disabled() methods on actions (or
> > class level, depending) and then working with the session username...
> >
>
> If I could get a class level disabled to work that would be a solution, but
> am now thinking a view-model approach is more flexible. I never make a
> reference to a MyApplicationUser instance public (visible), and provide a
> view-model of it instead. All except where I allow access to the current
> users profile.
>
> >
> > Cheers,
> > Kevin
> >
> > On 24 August 2017 06:14:47 CEST, Stephen Cameron <
> > steve.cameron.62@gmail.com> wrote:
> > >Hi,
> > >
> > >I have implemented and extended version of ApplicationUser class called
> > >MyApplicationUser to allow users to add more information to their
> > >'profile'
> > >in my web-app. They self-enrol (via initial entry of an email address,
> > >then
> > >following a link in a email sent to that address [1] ) and then add
> > >more
> > >details once they've created a user account.
> > >
> > >I now make use of the class MyApplicationUser more widely in the
> > >application but this leads to the problem that one user can modify the
> > >profile of another. Using the security module we can make all classes,
> > >instances of a class VIEWING or CHANGING. It must be the later to be
> > >able
> > >to change their own record, but generally it should be VIEWING only. Is
> > >there a way to achieve this.
> > >
> > >My alternative is to make use of the MyApplicationUser entity but to
> > >display its property values as a read-only view-model when necessary,
> > >that
> > >is, as a derived property. At the moment, I am having some problems
> > >with
> > >this approach in terms of displaying collections of MyApplicationUser
> > >as
> > >collections (of more view models) in the view-model class.
> > >
> > >I was creating my view-model as a wrapper around a persistent entity,
> > >it's
> > >worked in the past but not working in this case, with some strange
> > >effects,
> > >like "Failed title". So setting actual properties in the view-model
> > >class
> > >(rather than making all getters call a getter of the wrapped object)
> > >might
> > >be necessary to take full advantage of session caching of view model
> > >instances?
> > >
> > >I think using the view model approach might be the solution.
> > >
> > >Cheers
> > >Steve
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

--001a1135df1a9d8b6c05577bb144--