Mailing-List: contact jsecurity-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jsecurity-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of daniel.lauk@gmail.com
 designates 74.125.46.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=B5/HtS+AhYm28vut/YaK8EtCchBpBUdz7B3PBypquHXqKNcN8ZUNwfEfWXMMFW+UTP
         jpBhqwAn/Ypp9nRAwzz/a5cZZaO9dbBdWMQ04J0h4YxUl9j6TG9BA8W6z/Iku3mDpKvz
         3jsVgjeznsNVb/Ga27VT1NToiS9p2w78kFtjU=
MIME-Version: 1.0
In-Reply-To: <44b57a610901261151u36379fa6n670fc7a10c408d2b@mail.gmail.com>
References: <f34da72b0901260635v3514e93csd9d3725b80449424@mail.gmail.com>
	 <44b57a610901260722m5b210f54o4f497030e6af6d7c@mail.gmail.com>
	 <44b57a610901260725g420f6e9an5c10d7d9ea34217d@mail.gmail.com>
	 <f34da72b0901260858l1450ed51w6f51c048680fabea@mail.gmail.com>
	 <44b57a610901260926i2a7b8b6do7387c6a88b12552b@mail.gmail.com>
	 <f34da72b0901261125l1e28018eoe5376a8920fb4b7e@mail.gmail.com>
	 <44b57a610901261151u36379fa6n670fc7a10c408d2b@mail.gmail.com>
Date: Tue, 27 Jan 2009 07:22:15 +0100
Message-ID: <f34da72b0901262222s120be32bs661c10897e5c63b7@mail.gmail.com>
Subject: Re: Instance level security w/ Permissions
From: "Daniel J. Lauk" <daniel.lauk@gmail.com>
To: jsecurity-user@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

> You can still do this of course so you don't have to duplicate UI code - it
> is just a trade-off.  More rather than less permissions mean a little extra
> processing time.  But, if you don't assign hundreds per user or role, then
> it won't really matter for most applications.  The performance 'hit' will be
> negligible for most applications, especially if you use 2nd-level caching to
> minimize or eliminate RDBMS round trips.

I have never looked at it that way. Of course execution time is a
tradeoff as well. D'oh.
Thanks for the pointer. I'll have to ponder on all that again.

> One thing that Peter (rightfully) tries to clarify as well is the difference
> between a permission assignment and a permission check.  Both situations use
> a permission instance, so that overlap sometimes confuses people.

Yes, that actually was clear from the beginning. Almost. Not upon
first reading but definitely within my first day trying to learn
JSecurity :-)
The actual problem I had was the way the plugin works. I did not
understand that the domain class "JsecPermission" in fact was not a
JSecurity Permission in the sense of org.jsecurity.authz.Permission.
Instead it's "just" the DB entry to create one.

Anyway, by now I improved on Grails and Groovy and I think I got it now :-)

> Notice how the permission being checked is similar to the permission that
> was originally assigned.  That is because Permissions don't work as a simple
> equality check, there is _implication_ logic that occurs: "user:edit"
> permission (assigned) 'implies' the "user:edit:1234" permission (checked).
>
> This does make permissions sometimes harder to understand, but once you get
> the concept of implication down, you can really harness their power.

Yes. I think that is really powerful.
In particular the WildcardPermission is ingenious! I think I won't
have to code any custom permission classes.
The tradeoff is type safety -- I still don't know if that term
references data types or typing ;-) -- but with Groovy I just gave up
on types and stick to testing ;-)

Cheers,
DJ