On Thu, Aug 24, 2017 at 4:17 PM, Kevin Meyer <[email protected]> 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 < > [email protected]> 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.
