Im not sure how using a Shiro role would work since they are predefined yet organizations can be added/removed dynamically
On Thu, Nov 20, 2014 at 10:37 AM, Martin Grigorov <[email protected]> wrote: > Hi, > > I am not familiar with isis security module but isn't it possible to use a > (Shiro) Role as an Organization ? > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Nov 20, 2014 at 10:31 AM, <[email protected]> wrote: > > > > > > > > > - Hi Martin, maybe you can try a solution that I made and that works for > > me at the moment; > > I defined a 'an abstrat secure object' that has the properties you are > > looking for [1] > > > > [1] > > > > > https://github.com/johandoornenbal/matching/blob/master/dom/src/main/java/info/matchingservice/dom/MatchingSecureMutableObject.java > > > > Thanks I agree, option 1 is much better. > > > > As for my user case: I have a system that hosts a number or organizations > > orthogonally. What I need to do is associate each user to exactly 1 org > so > > that he/she can only see and modify information belonging to that org. > > > > After looking at the problem, I figure that the best way to do it would > be > > to use the security module and add an Organization property to > > ApplicationUser. Unfortunately it seems I would have to fork the module > and > > add my custom Orgnization domain object to it. > > > > > > > > > > > > On Wed, Nov 19, 2014 at 5:54 PM, Dan Haywood > > wrote: > > > > > On 19 November 2014 16:41, Jeroen van der Wal wrote: > > > > > > > Just double-checked: the master branch of isis-module-security uses > the > > > > latest and greatest version of Isis, 1.8.0-SNAPSHOT > > > > > > > > [1] > > > > > > > > > > > > > > https://github.com/isisaddons/isis-module-security/blob/master/pom.xml#L32-L36 > > > > > > > > > > > (though the screenshots in the README are still of 1.7.0) > > > > > > > > > > > > > > > > > > > On Wed, Nov 19, 2014 at 4:33 PM, Jeroen van der Wal > > > > > wrote: > > > > > > > > > Hi Martin, > > > > > > > > > > I would advice against option 2 because you lose an easy update > path > > to > > > > > newer versions of the security module. > > > > > > > > > > > > > > > +1 to that advice. > > > > > > > > > > > > > > > > > Tell us more about your use-case so we can see what the options > are. > > > > > > > > > > > > > > > In particular, is the additional information you need to store > mandatory > > > with no sensible default (ie would need to prompt for it), or would the > > > current signatures of the methods in ApplicationUsers domain service > > > suffice? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > Jeroen > > > > > > > > > > On Wed, Nov 19, 2014 at 2:24 PM, Martin Balmaceda < > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > -- > > to do is to be. dobedobedo > > > > > > > > > -- to do is to be. dobedobedo
