Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of mposolda@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <4F953ECA.4010701@redhat.com>
Date: Mon, 23 Apr 2012 13:36:42 +0200
From: Marek Posolda <mposolda@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: deltaspike-dev@incubator.apache.org
CC: Shane Bryzak <sbryzak@redhat.com>,
        Christian Kaltepoth <christian@kaltepoth.de>
Subject: Re: [DISCUSS] DELTASPIKE-79 Authorization API
References: <4F8DF44A.9020704@redhat.com>	<4F8F3A25.1020200@redhat.com>
	<4F8F4693.7040702@redhat.com>	<4F8FE5B9.8050700@redhat.com>
	<4F8FFD82.3030002@redhat.com>	<4F900066.5070701@redhat.com>
 <CAEXeC6yGWiuUMGn_9TDz7XQTK6srV35M2BijcWZ4GuTr5iSLPg@mail.gmail.com>
 <4F950CD2.9080803@redhat.com> <4F9520BA.8040700@redhat.com>
In-Reply-To: <4F9520BA.8040700@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>> So after all, my opinion is to have two methods:
>>
>> Identity.hasPermission(Object object, Operation operation) throws 
>> AuthorizationException;
>> Identity.hasPermission(ResourceIdentifier resourceIdentifier, 
>> Operation operation) throws AuthorizationException;
>
> +1, I think that having two methods is the best solution, with the 
> caveat that overloading like this doesn't cause issues with EL.  The 
> Object parameter version of this method will most likely delegate to 
> the ResourceIdentifier method anyway, as a ResourceIdentifier will be 
> required for all lookups.  By the way, we should make this as 
> transparent as possible - out of the box, DeltaSpike should provide a 
> ResourceIdentifier implementation for entity beans that will build a 
> unique identifier based on the class name and the primary key value.  
> Another alternative that we should support is allowing the user to 
> specify which ResourceIdentifier to use on the domain class itself:
>
> @Entity
> @Identifier(CustomerResourceIdentifier.class)
> public class Customer
> {
>
> }
>
> Yet another alternative that we should support is the packaging of 
> additional ResourceIdentifier implementations with an application, 
> that are automatically discovered and iterated through when the 
> permission check can't determine which ResourceIdentifier to use.  
> With that in mind, the ResourceIdentifier interface should look like 
> this:
>
> public interface ResourceIdentifier
> {
>     boolean canIdentify(Class targetClass);
>     String getIdentifier(Object resource);
> }
>
> The canIdentify() method will return true if the specified class is 
> one that this ResourceIdentifier is capable of generating identifier 
> strings for.
That will be nice. Another idea can be to have some interface, which 
needs to be implemented by the Resource object and ResourceIdentifier 
can use it then. Like:

public interface Resource
{
   public ResourceIdentifier getIdentifier();
}

public class Customer implements Resource
{

   private customerId;

   // snippet


   public ResourceIdentifier getIdentifier
   {
       return  new ResourceIdentifier(Customer.class.getName(), 
getCustomerId());
   }

}

And then Identity like

public Identity
{

   public hasPermission(Object resource, String action)
   {
      if (resource instanceof Resource)
      {
            return hasPermission((Resource)resource.getIdentifier(), 
action);
      }
      else
      {
          // use other ways to map ResourceIdentifier from Object
       }
   }

   public hasPermission(ResourceIdentifier resIdentifier, action)
   {
        // snipet
    }

}

With this design, it would be easy to map ResourceIdentifier for various 
type of objects. Of course, limitation is that Object needs to implement 
the Resource interface. which can't be always done. So we will need 
toher ways for ResourceIdentifier mapping anyway.

>
>>
>>
>> Thanks,
>> Marek
>
>