Stateless (Flyweight) and current user

[Adam Young]

The current implementation of candlepin is complete oblivious to the 
caller.  We can authenticate, but once we do, we do not tailor the 
output of the calls based on who logged in.

If we are to implement the multi-org functionality, we need to rpovide a 
mechanism for checking "who asked this."


For example, on  ConsumerResource.list is implemented as:

  public List<Consumer> list() {
         return consumerCurator.findAll();
     }


To filter this via user, we have three choices.  I'm going to use 
rincipal for the user, as we don't havea first calss user object yet, 
but we can change that later.

1.  Change the method signature


  public List<Consumer> list(Principal p) {
         return consumerCurator.findByOwner(getOwner(p));
     }


2.  Add it to the ConsumerResource constructor via dependency injection. 
(Note that I wouldn't really implement getOwner this way, just to 
demostrate)


  public List<Consumer> list() {
         return 
consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
     }

3.  Fetch it from a context like JNDI

  public List<Consumer> list() {
         Principal p = (Principal)new 
InitialContext().resolve(Principal.class.getName());
         return consumerCurator.findByOwner(this.getOwner(p));
     }



Option 1 is best for cases where this is going to be only required for 
one or two methods.  THe Principal will be needed for just about every 
method.

Option 2 means that the Resource Objects will no longer be stateless, 
but instead will have to be created either on each request, or once per 
session

Option 3 menas we have non-explicit dependencies.


Do we need a meeting for this?

[Bryan Kearney]

On 04/01/2010 10:40 AM, Adam Young wrote:
>  The current implementation of candlepin is complete oblivious to the
>  caller.  We can authenticate, but once we do, we do not tailor the
>  output of the calls based on who logged in.
>
>  If we are to implement the multi-org functionality, we need to rpovide a
>  mechanism for checking "who asked this."
>
>
>  For example, on  ConsumerResource.list is implemented as:
>
>     public List<Consumer>  list() {
>            return consumerCurator.findAll();
>        }
>
>
>  To filter this via user, we have three choices.  I'm going to use
>  rincipal for the user, as we don't havea first calss user object yet,
>  but we can change that later.
>
>  1.  Change the method signature
>
>
>     public List<Consumer>  list(Principal p) {
>            return consumerCurator.findByOwner(getOwner(p));
>        }
>
>
>  2.  Add it to the ConsumerResource constructor via dependency injection.
>  (Note that I wouldn't really implement getOwner this way, just to
>  demostrate)
>
>
>     public List<Consumer>  list() {
>            return
>  consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
>        }
>
>  3.  Fetch it from a context like JNDI
>
>     public List<Consumer>  list() {
>            Principal p = (Principal)new
>  InitialContext().resolve(Principal.class.getName());
>            return consumerCurator.findByOwner(this.getOwner(p));
>        }
>
>
>
>  Option 1 is best for cases where this is going to be only required for
>  one or two methods.  THe Principal will be needed for just about every
>  method.
>
>  Option 2 means that the Resource Objects will no longer be stateless,
>  but instead will have to be created either on each request, or once per
>  session
>
>  Option 3 menas we have non-explicit dependencies.
>
>
>  Do we need a meeting for this? 
I would say no, and I would be +1 for the Option 3. I would suggest we 
use a Context object which could hide me from JNDI, Guce, or name your 
magic thread local pattern..

-- bk

[Adam Young]

On 04/01/2010 10:47 AM, Bryan Kearney wrote:
>  On 04/01/2010 10:40 AM, Adam Young wrote:
> > The current implementation of candlepin is complete oblivious to the
> > caller.  We can authenticate, but once we do, we do not tailor the
> > output of the calls based on who logged in.
> >
> > If we are to implement the multi-org functionality, we need to rpovide a
> > mechanism for checking "who asked this."
> >
> >
> > For example, on  ConsumerResource.list is implemented as:
> >
> >    public List<Consumer>  list() {
> >           return consumerCurator.findAll();
> >       }
> >
> >
> > To filter this via user, we have three choices.  I'm going to use
> > rincipal for the user, as we don't havea first calss user object yet,
> > but we can change that later.
> >
> > 1.  Change the method signature
> >
> >
> >    public List<Consumer>  list(Principal p) {
> >           return consumerCurator.findByOwner(getOwner(p));
> >       }
> >
> >
> > 2.  Add it to the ConsumerResource constructor via dependency injection.
> > (Note that I wouldn't really implement getOwner this way, just to
> > demostrate)
> >
> >
> >    public List<Consumer>  list() {
> >           return
> > consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
> >       }
> >
> > 3.  Fetch it from a context like JNDI
> >
> >    public List<Consumer>  list() {
> >           Principal p = (Principal)new
> > InitialContext().resolve(Principal.class.getName());
> >           return consumerCurator.findByOwner(this.getOwner(p));
> >       }
> >
> >
> >
> > Option 1 is best for cases where this is going to be only required for
> > one or two methods.  THe Principal will be needed for just about every
> > method.
> >
> > Option 2 means that the Resource Objects will no longer be stateless,
> > but instead will have to be created either on each request, or once per
> > session
> >
> > Option 3 menas we have non-explicit dependencies.
> >
> >
> > Do we need a meeting for this?
>
>  I would say no, and I would be +1 for the Option 3. I would suggest we 
>  use a Context object which could hide me from JNDI, Guce, or name your 
>  magic thread local pattern..
>
>  -- bk
>
>  
I was really sad you said that.  I think that Option 3 is the worst of 
the bunch.

[Bryan Kearney]

On 04/01/2010 10:52 AM, Adam Young wrote:
>  I was really sad you said that.  I think that Option 3 is the worst
> of
>  the bunch. 
I know.. but it is the easiest. Plus.. I worry about maintenance of the

unit tests since everytime we find a new paraemeter everyone needs to 
call it to pass it from the filter down tot he curator.

-- bk

[Justin Harris]

----- "Bryan Kearney" <bkearney(a)redhat.com&gt; wrote:

>  On 04/01/2010 10:40 AM, Adam Young wrote:
>  > The current implementation of candlepin is complete oblivious to
>  the
>  > caller.  We can authenticate, but once we do, we do not tailor the
>  > output of the calls based on who logged in.
>  >
>  > If we are to implement the multi-org functionality, we need to
>  rpovide a
>  > mechanism for checking "who asked this."
>  >
>  >
>  > For example, on  ConsumerResource.list is implemented as:
>  >
>  >    public List<Consumer>  list() {
>  >           return consumerCurator.findAll();
>  >       }
>  >
>  >
>  > To filter this via user, we have three choices.  I'm going to use
>  > rincipal for the user, as we don't havea first calss user object
>  yet,
>  > but we can change that later.
>  >
>  > 1.  Change the method signature
>  >
>  >
>  >    public List<Consumer>  list(Principal p) {
>  >           return consumerCurator.findByOwner(getOwner(p));
>  >       }
>  >
>  >
>  > 2.  Add it to the ConsumerResource constructor via dependency
>  injection.
>  > (Note that I wouldn't really implement getOwner this way, just to
>  > demostrate)
>  >
>  >
>  >    public List<Consumer>  list() {
>  >           return
>  > consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
>  >       }
>  >
>  > 3.  Fetch it from a context like JNDI
>  >
>  >    public List<Consumer>  list() {
>  >           Principal p = (Principal)new
>  > InitialContext().resolve(Principal.class.getName());
>  >           return consumerCurator.findByOwner(this.getOwner(p));
>  >       }
>  >
>  >
>  >
>  > Option 1 is best for cases where this is going to be only required
>  for
>  > one or two methods.  THe Principal will be needed for just about
>  every
>  > method.
>  >
>  > Option 2 means that the Resource Objects will no longer be
>  stateless,
>  > but instead will have to be created either on each request, or once
>  per
>  > session
>  >
>  > Option 3 menas we have non-explicit dependencies.
>  >
>  >
>  > Do we need a meeting for this?
>  
>  I would say no, and I would be +1 for the Option 3. I would suggest we
>  
>  use a Context object which could hide me from JNDI, Guce, or name your
>  
>  magic thread local pattern.. 
I think that this is a losing argument for me, but I am going to echo that I think having
a resource look different depending on who is looking at it violates RESTiness and also
sets us up for a tough road wrt maintenance.  I really would like to explore organizing
our URLs to specify the collections more accurately, and using the user/roles to either
allow or deny access - and that is all.

 - Justin



>  
>  -- bk
>  
>  
>  _______________________________________________
>  candlepin mailing list
>  candlepin(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/candlepin

[Bryan Kearney]

On 04/01/2010 10:55 AM, Justin Harris wrote:
>  ----- "Bryan Kearney"<bkearney(a)redhat.com>  wrote:
>
> > On 04/01/2010 10:40 AM, Adam Young wrote:
> >> The current implementation of candlepin is complete oblivious to
> > the
> >> caller.  We can authenticate, but once we do, we do not tailor the
> >> output of the calls based on who logged in.
> >>
> >> If we are to implement the multi-org functionality, we need to
> > rpovide a
> >> mechanism for checking "who asked this."
> >>
> >>
> >> For example, on  ConsumerResource.list is implemented as:
> >>
> >>     public List<Consumer>   list() {
> >>            return consumerCurator.findAll();
> >>        }
> >>
> >>
> >> To filter this via user, we have three choices.  I'm going to use
> >> rincipal for the user, as we don't havea first calss user object
> > yet,
> >> but we can change that later.
> >>
> >> 1.  Change the method signature
> >>
> >>
> >>     public List<Consumer>   list(Principal p) {
> >>            return consumerCurator.findByOwner(getOwner(p));
> >>        }
> >>
> >>
> >> 2.  Add it to the ConsumerResource constructor via dependency
> > injection.
> >> (Note that I wouldn't really implement getOwner this way, just to
> >> demostrate)
> >>
> >>
> >>     public List<Consumer>   list() {
> >>            return
> >> consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
> >>        }
> >>
> >> 3.  Fetch it from a context like JNDI
> >>
> >>     public List<Consumer>   list() {
> >>            Principal p = (Principal)new
> >> InitialContext().resolve(Principal.class.getName());
> >>            return consumerCurator.findByOwner(this.getOwner(p));
> >>        }
> >>
> >>
> >>
> >> Option 1 is best for cases where this is going to be only required
> > for
> >> one or two methods.  THe Principal will be needed for just about
> > every
> >> method.
> >>
> >> Option 2 means that the Resource Objects will no longer be
> > stateless,
> >> but instead will have to be created either on each request, or once
> > per
> >> session
> >>
> >> Option 3 menas we have non-explicit dependencies.
> >>
> >>
> >> Do we need a meeting for this?
> >
> > I would say no, and I would be +1 for the Option 3. I would suggest we
> >
> > use a Context object which could hide me from JNDI, Guce, or name your
> >
> > magic thread local pattern..
>
>  I think that this is a losing argument for me, but I am going to echo that I think having
> a resource look different depending on who is looking at it violates RESTiness and also
> sets us up for a tough road wrt maintenance.  I really would like to explore organizing
> our URLs to specify the collections more accurately, and using the user/roles to either
> allow or deny access - and that is all.
>
>    - Justin
>  
This is a red herring a bit in the discussion. Think of it how do you 
get data from the resource into the curator.

FWIW.. I dont think it does violate restfullness. I am seeing eaxmples 
of people using media to coerce what comes back. User and security is 
not much different.

-- bk

[Justin Harris]

----- "Bryan Kearney" <bkearney(a)redhat.com&gt; wrote:

>  On 04/01/2010 10:55 AM, Justin Harris wrote:
>  >
>  > ----- "Bryan Kearney&quot;&lt;bkearney(a)redhat.com&gt;  wrote:
>  >
>  >> On 04/01/2010 10:40 AM, Adam Young wrote:
>  >>> The current implementation of candlepin is complete oblivious to
>  >> the
>  >>> caller.  We can authenticate, but once we do, we do not tailor
>  the
>  >>> output of the calls based on who logged in.
>  >>>
>  >>> If we are to implement the multi-org functionality, we need to
>  >> rpovide a
>  >>> mechanism for checking "who asked this."
>  >>>
>  >>>
>  >>> For example, on  ConsumerResource.list is implemented as:
>  >>>
>  >>>     public List<Consumer>   list() {
>  >>>            return consumerCurator.findAll();
>  >>>        }
>  >>>
>  >>>
>  >>> To filter this via user, we have three choices.  I'm going to use
>  >>> rincipal for the user, as we don't havea first calss user object
>  >> yet,
>  >>> but we can change that later.
>  >>>
>  >>> 1.  Change the method signature
>  >>>
>  >>>
>  >>>     public List<Consumer>   list(Principal p) {
>  >>>            return consumerCurator.findByOwner(getOwner(p));
>  >>>        }
>  >>>
>  >>>
>  >>> 2.  Add it to the ConsumerResource constructor via dependency
>  >> injection.
>  >>> (Note that I wouldn't really implement getOwner this way, just to
>  >>> demostrate)
>  >>>
>  >>>
>  >>>     public List<Consumer>   list() {
>  >>>            return
>  >>> consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
>  >>>        }
>  >>>
>  >>> 3.  Fetch it from a context like JNDI
>  >>>
>  >>>     public List<Consumer>   list() {
>  >>>            Principal p = (Principal)new
>  >>> InitialContext().resolve(Principal.class.getName());
>  >>>            return consumerCurator.findByOwner(this.getOwner(p));
>  >>>        }
>  >>>
>  >>>
>  >>>
>  >>> Option 1 is best for cases where this is going to be only
>  required
>  >> for
>  >>> one or two methods.  THe Principal will be needed for just about
>  >> every
>  >>> method.
>  >>>
>  >>> Option 2 means that the Resource Objects will no longer be
>  >> stateless,
>  >>> but instead will have to be created either on each request, or
>  once
>  >> per
>  >>> session
>  >>>
>  >>> Option 3 menas we have non-explicit dependencies.
>  >>>
>  >>>
>  >>> Do we need a meeting for this?
>  >>
>  >> I would say no, and I would be +1 for the Option 3. I would suggest
>  we
>  >>
>  >> use a Context object which could hide me from JNDI, Guce, or name
>  your
>  >>
>  >> magic thread local pattern..
>  >
>  > I think that this is a losing argument for me, but I am going to
>  echo that I think having a resource look different depending on who is
>  looking at it violates RESTiness and also sets us up for a tough road
>  wrt maintenance.  I really would like to explore organizing our URLs
>  to specify the collections more accurately, and using the user/roles
>  to either allow or deny access - and that is all.
>  >
>  >   - Justin
>  >
>  This is a red herring a bit in the discussion. Think of it how do you
>  
>  get data from the resource into the curator.
>  
>  FWIW.. I dont think it does violate restfullness. I am seeing eaxmples
>  
>  of people using media to coerce what comes back. User and security is
>  
>  not much different. 
Yes I see your point now.  Sorry about that. :)   Has anyone looked into if Guice can do a
lot of this for us?  I'm not sure about the component lifecycles for Guice, but I know
that for example Seam will do dependency injection per request, so that we can have our
auth filters set up the current Owner, Roles, etc. and just pass those in as parameters to
the resource (or curators).  Relying on the DI framework can also simplify unit testing
because you just pass in what you want and don't have to worry about mocking out JNDI
contexts which would make me want to punch myself in the face.


>  
>  -- bk

[Dmitri Dolguikh]

On 04/01/2010 12:16 PM, Justin Harris wrote:
>  ----- "Bryan Kearney"<bkearney(a)redhat.com>  wrote:
>
>     
> > On 04/01/2010 10:55 AM, Justin Harris wrote:
> >      
> >> ----- "Bryan Kearney"<bkearney(a)redhat.com>   wrote:
> >>
> >>        
> >>> On 04/01/2010 10:40 AM, Adam Young wrote:
> >>>          
> >>>> The current implementation of candlepin is complete oblivious to
> >>>>            
> >>> the
> >>>          
> >>>> caller.  We can authenticate, but once we do, we do not tailor
> >>>>            
> > the
> >      
> >>>> output of the calls based on who logged in.
> >>>>
> >>>> If we are to implement the multi-org functionality, we need to
> >>>>            
> >>> rpovide a
> >>>          
> >>>> mechanism for checking "who asked this."
> >>>>
> >>>>
> >>>> For example, on  ConsumerResource.list is implemented as:
> >>>>
> >>>>      public List<Consumer>    list() {
> >>>>             return consumerCurator.findAll();
> >>>>         }
> >>>>
> >>>>
> >>>> To filter this via user, we have three choices.  I'm going to use
> >>>> rincipal for the user, as we don't havea first calss user object
> >>>>            
> >>> yet,
> >>>          
> >>>> but we can change that later.
> >>>>
> >>>> 1.  Change the method signature
> >>>>
> >>>>
> >>>>      public List<Consumer>    list(Principal p) {
> >>>>             return consumerCurator.findByOwner(getOwner(p));
> >>>>         }
> >>>>
> >>>>
> >>>> 2.  Add it to the ConsumerResource constructor via dependency
> >>>>            
> >>> injection.
> >>>          
> >>>> (Note that I wouldn't really implement getOwner this way, just to
> >>>> demostrate)
> >>>>
> >>>>
> >>>>      public List<Consumer>    list() {
> >>>>             return
> >>>> consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
> >>>>         }
> >>>>
> >>>> 3.  Fetch it from a context like JNDI
> >>>>
> >>>>      public List<Consumer>    list() {
> >>>>             Principal p = (Principal)new
> >>>> InitialContext().resolve(Principal.class.getName());
> >>>>             return consumerCurator.findByOwner(this.getOwner(p));
> >>>>         }
> >>>>
> >>>>
> >>>>
> >>>> Option 1 is best for cases where this is going to be only
> >>>>            
> > required
> >      
> >>> for
> >>>          
> >>>> one or two methods.  THe Principal will be needed for just about
> >>>>            
> >>> every
> >>>          
> >>>> method.
> >>>>
> >>>> Option 2 means that the Resource Objects will no longer be
> >>>>            
> >>> stateless,
> >>>          
> >>>> but instead will have to be created either on each request, or
> >>>>            
> > once
> >      
> >>> per
> >>>          
> >>>> session
> >>>>
> >>>> Option 3 menas we have non-explicit dependencies.
> >>>>
> >>>>
> >>>> Do we need a meeting for this?
> >>>>            
> >>> I would say no, and I would be +1 for the Option 3. I would suggest
> >>>          
> > we
> >      
> >>> use a Context object which could hide me from JNDI, Guce, or name
> >>>          
> > your
> >      
> >>> magic thread local pattern..
> >>>          
> >> I think that this is a losing argument for me, but I am going to
> >>        
> > echo that I think having a resource look different depending on who is
> > looking at it violates RESTiness and also sets us up for a tough road
> > wrt maintenance.  I really would like to explore organizing our URLs
> > to specify the collections more accurately, and using the user/roles
> > to either allow or deny access - and that is all.
> >      
> >>    - Justin
> >>
> >>        
> > This is a red herring a bit in the discussion. Think of it how do you
> >
> > get data from the resource into the curator.
> >
> > FWIW.. I dont think it does violate restfullness. I am seeing eaxmples
> >
> > of people using media to coerce what comes back. User and security is
> >
> > not much different.
> >      
>  Yes I see your point now.  Sorry about that. :)   Has anyone looked into if Guice can do
> a lot of this for us?  I'm not sure about the component lifecycles for Guice, but I
> know that for example Seam will do dependency injection per request, so that we can have
> our auth filters set up the current Owner, Roles, etc. and just pass those in as
> parameters to the resource (or curators).  Relying on the DI framework can also simplify
> unit testing because you just pass in what you want and don't have to worry about
> mocking out JNDI contexts which would make me want to punch myself in the face.
>      
Yup. we can have http-request-scoped objects. And a custom 'provider'
to 
inject those.
-d
>     
> > -- bk
> >      
>  _______________________________________________
>  candlepin mailing list
>  candlepin(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/candlepin
>

[Adam Young]

On 04/01/2010 11:20 AM, Dmitri Dolguikh wrote:
>  On 04/01/2010 12:16 PM, Justin Harris wrote:
>     
> > ----- "Bryan Kearney"<bkearney(a)redhat.com>   wrote:
> >
> >
> >      
> >> On 04/01/2010 10:55 AM, Justin Harris wrote:
> >>
> >>        
> >>> ----- "Bryan Kearney"<bkearney(a)redhat.com>    wrote:
> >>>
> >>>
> >>>          
> >>>> On 04/01/2010 10:40 AM, Adam Young wrote:
> >>>>
> >>>>            
> >>>>> The current implementation of candlepin is complete oblivious to
> >>>>>
> >>>>>              
> >>>> the
> >>>>
> >>>>            
> >>>>> caller.  We can authenticate, but once we do, we do not tailor
> >>>>>
> >>>>>              
> >> the
> >>
> >>        
> >>>>> output of the calls based on who logged in.
> >>>>>
> >>>>> If we are to implement the multi-org functionality, we need to
> >>>>>
> >>>>>              
> >>>> rpovide a
> >>>>
> >>>>            
> >>>>> mechanism for checking "who asked this."
> >>>>>
> >>>>>
> >>>>> For example, on  ConsumerResource.list is implemented as:
> >>>>>
> >>>>>       public List<Consumer>     list() {
> >>>>>              return consumerCurator.findAll();
> >>>>>          }
> >>>>>
> >>>>>
> >>>>> To filter this via user, we have three choices.  I'm going to
> use
> >>>>> rincipal for the user, as we don't havea first calss user object
> >>>>>
> >>>>>              
> >>>> yet,
> >>>>
> >>>>            
> >>>>> but we can change that later.
> >>>>>
> >>>>> 1.  Change the method signature
> >>>>>
> >>>>>
> >>>>>       public List<Consumer>     list(Principal p) {
> >>>>>              return consumerCurator.findByOwner(getOwner(p));
> >>>>>          }
> >>>>>
> >>>>>
> >>>>> 2.  Add it to the ConsumerResource constructor via dependency
> >>>>>
> >>>>>              
> >>>> injection.
> >>>>
> >>>>            
> >>>>> (Note that I wouldn't really implement getOwner this way, just
> to
> >>>>> demostrate)
> >>>>>
> >>>>>
> >>>>>       public List<Consumer>     list() {
> >>>>>              return
> >>>>> consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
> >>>>>          }
> >>>>>
> >>>>> 3.  Fetch it from a context like JNDI
> >>>>>
> >>>>>       public List<Consumer>     list() {
> >>>>>              Principal p = (Principal)new
> >>>>> InitialContext().resolve(Principal.class.getName());
> >>>>>              return consumerCurator.findByOwner(this.getOwner(p));
> >>>>>          }
> >>>>>
> >>>>>
> >>>>>
> >>>>> Option 1 is best for cases where this is going to be only
> >>>>>
> >>>>>              
> >> required
> >>
> >>        
> >>>> for
> >>>>
> >>>>            
> >>>>> one or two methods.  THe Principal will be needed for just about
> >>>>>
> >>>>>              
> >>>> every
> >>>>
> >>>>            
> >>>>> method.
> >>>>>
> >>>>> Option 2 means that the Resource Objects will no longer be
> >>>>>
> >>>>>              
> >>>> stateless,
> >>>>
> >>>>            
> >>>>> but instead will have to be created either on each request, or
> >>>>>
> >>>>>              
> >> once
> >>
> >>        
> >>>> per
> >>>>
> >>>>            
> >>>>> session
> >>>>>
> >>>>> Option 3 menas we have non-explicit dependencies.
> >>>>>
> >>>>>
> >>>>> Do we need a meeting for this?
> >>>>>
> >>>>>              
> >>>> I would say no, and I would be +1 for the Option 3. I would suggest
> >>>>
> >>>>            
> >> we
> >>
> >>        
> >>>> use a Context object which could hide me from JNDI, Guce, or name
> >>>>
> >>>>            
> >> your
> >>
> >>        
> >>>> magic thread local pattern..
> >>>>
> >>>>            
> >>> I think that this is a losing argument for me, but I am going to
> >>>
> >>>          
> >> echo that I think having a resource look different depending on who is
> >> looking at it violates RESTiness and also sets us up for a tough road
> >> wrt maintenance.  I really would like to explore organizing our URLs
> >> to specify the collections more accurately, and using the user/roles
> >> to either allow or deny access - and that is all.
> >>
> >>        
> >>>     - Justin
> >>>
> >>>
> >>>          
> >> This is a red herring a bit in the discussion. Think of it how do you
> >>
> >> get data from the resource into the curator.
> >>
> >> FWIW.. I dont think it does violate restfullness. I am seeing eaxmples
> >>
> >> of people using media to coerce what comes back. User and security is
> >>
> >> not much different.
> >>
> >>        
> > Yes I see your point now.  Sorry about that. :)   Has anyone looked into if Guice can
> do a lot of this for us?  I'm not sure about the component lifecycles for Guice, but I
> know that for example Seam will do dependency injection per request, so that we can have
> our auth filters set up the current Owner, Roles, etc. and just pass those in as
> parameters to the resource (or curators).  Relying on the DI framework can also simplify
> unit testing because you just pass in what you want and don't have to worry about
> mocking out JNDI contexts which would make me want to punch myself in the face.
> >
> >      
>  Yup. we can have http-request-scoped objects. And a custom 'provider' to
>  inject those.
>  -d
>      


Yep.  The reason to not do that is to limit the amount of DI overhead 
per request call.    We aren't doing that thus far, but we might want to 
do so in the future.


Of course, then you have the question about making all object references 
into instance variables.

What my gut is telling me is that stuff that survives over multple 
requests should be member variables of the Resources, and stuff that is 
per-request should be parameters to functions.  I'd hold off on 
createing a general purpose "context" until we are certain we need it, 
and instead add the Principal or User object to the method calls that 
require it.

I missed the JAAS discussion, as I think it happened prior to me joining 
the team.  Why did we remove JAAS, and why do we think we might want it 
back now?

> >
> >      
> >> -- bk
> >>
> >>        
> > _______________________________________________
> > candlepin mailing list
> > candlepin(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/candlepin
> >
> >      
>  _______________________________________________
>  candlepin mailing list
>  candlepin(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/candlepin
>

[Dmitri Dolguikh]

On 04/01/2010 12:35 PM, Adam Young wrote:
>  On 04/01/2010 11:20 AM, Dmitri Dolguikh wrote:
>     
> > On 04/01/2010 12:16 PM, Justin Harris wrote:
> >
> >      
> >> ----- "Bryan Kearney"<bkearney(a)redhat.com>    wrote:
> >>
> >>
> >>
> >>        
> >>> On 04/01/2010 10:55 AM, Justin Harris wrote:
> >>>
> >>>
> >>>          
> >>>> ----- "Bryan Kearney"<bkearney(a)redhat.com>     wrote:
> >>>>
> >>>>
> >>>>
> >>>>            
> >>>>> On 04/01/2010 10:40 AM, Adam Young wrote:
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> The current implementation of candlepin is complete oblivious to
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>> the
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> caller.  We can authenticate, but once we do, we do not tailor
> >>>>>>
> >>>>>>
> >>>>>>                
> >>> the
> >>>
> >>>
> >>>          
> >>>>>> output of the calls based on who logged in.
> >>>>>>
> >>>>>> If we are to implement the multi-org functionality, we need to
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>> rpovide a
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> mechanism for checking "who asked this."
> >>>>>>
> >>>>>>
> >>>>>> For example, on  ConsumerResource.list is implemented as:
> >>>>>>
> >>>>>>        public List<Consumer>      list() {
> >>>>>>               return consumerCurator.findAll();
> >>>>>>           }
> >>>>>>
> >>>>>>
> >>>>>> To filter this via user, we have three choices.  I'm going to
> use
> >>>>>> rincipal for the user, as we don't havea first calss user
> object
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>> yet,
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> but we can change that later.
> >>>>>>
> >>>>>> 1.  Change the method signature
> >>>>>>
> >>>>>>
> >>>>>>        public List<Consumer>      list(Principal p) {
> >>>>>>               return consumerCurator.findByOwner(getOwner(p));
> >>>>>>           }
> >>>>>>
> >>>>>>
> >>>>>> 2.  Add it to the ConsumerResource constructor via dependency
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>> injection.
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> (Note that I wouldn't really implement getOwner this way,
> just to
> >>>>>> demostrate)
> >>>>>>
> >>>>>>
> >>>>>>        public List<Consumer>      list() {
> >>>>>>               return
> >>>>>> consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
> >>>>>>           }
> >>>>>>
> >>>>>> 3.  Fetch it from a context like JNDI
> >>>>>>
> >>>>>>        public List<Consumer>      list() {
> >>>>>>               Principal p = (Principal)new
> >>>>>> InitialContext().resolve(Principal.class.getName());
> >>>>>>               return
> consumerCurator.findByOwner(this.getOwner(p));
> >>>>>>           }
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Option 1 is best for cases where this is going to be only
> >>>>>>
> >>>>>>
> >>>>>>                
> >>> required
> >>>
> >>>
> >>>          
> >>>>> for
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> one or two methods.  THe Principal will be needed for just about
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>> every
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> method.
> >>>>>>
> >>>>>> Option 2 means that the Resource Objects will no longer be
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>> stateless,
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> but instead will have to be created either on each request, or
> >>>>>>
> >>>>>>
> >>>>>>                
> >>> once
> >>>
> >>>
> >>>          
> >>>>> per
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> session
> >>>>>>
> >>>>>> Option 3 menas we have non-explicit dependencies.
> >>>>>>
> >>>>>>
> >>>>>> Do we need a meeting for this?
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>> I would say no, and I would be +1 for the Option 3. I would suggest
> >>>>>
> >>>>>
> >>>>>              
> >>> we
> >>>
> >>>
> >>>          
> >>>>> use a Context object which could hide me from JNDI, Guce, or name
> >>>>>
> >>>>>
> >>>>>              
> >>> your
> >>>
> >>>
> >>>          
> >>>>> magic thread local pattern..
> >>>>>
> >>>>>
> >>>>>              
> >>>> I think that this is a losing argument for me, but I am going to
> >>>>
> >>>>
> >>>>            
> >>> echo that I think having a resource look different depending on who is
> >>> looking at it violates RESTiness and also sets us up for a tough road
> >>> wrt maintenance.  I really would like to explore organizing our URLs
> >>> to specify the collections more accurately, and using the user/roles
> >>> to either allow or deny access - and that is all.
> >>>
> >>>
> >>>          
> >>>>      - Justin
> >>>>
> >>>>
> >>>>
> >>>>            
> >>> This is a red herring a bit in the discussion. Think of it how do you
> >>>
> >>> get data from the resource into the curator.
> >>>
> >>> FWIW.. I dont think it does violate restfullness. I am seeing eaxmples
> >>>
> >>> of people using media to coerce what comes back. User and security is
> >>>
> >>> not much different.
> >>>
> >>>
> >>>          
> >> Yes I see your point now.  Sorry about that. :)   Has anyone looked into if Guice
> can do a lot of this for us?  I'm not sure about the component lifecycles for Guice,
> but I know that for example Seam will do dependency injection per request, so that we can
> have our auth filters set up the current Owner, Roles, etc. and just pass those in as
> parameters to the resource (or curators).  Relying on the DI framework can also simplify
> unit testing because you just pass in what you want and don't have to worry about
> mocking out JNDI contexts which would make me want to punch myself in the face.
> >>
> >>
> >>        
> > Yup. we can have http-request-scoped objects. And a custom 'provider' to
> > inject those.
> > -d
> >
> >      
>
>
>  Yep.  The reason to not do that is to limit the amount of DI overhead
>  per request call.    We aren't doing that thus far, but we might want to
>  do so in the future.
>      
Majority of DI overhead comes from guice creating proxies, executing aop 
interceptors and such. We use guice already and are paying this price. 
Guice is also one of the faster di frameworks out there.
>  Of course, then you have the question about making all object references
>  into instance variables.
>
>  What my gut is telling me is that stuff that survives over multple
>  requests should be member variables of the Resources, and stuff that is
>  per-request should be parameters to functions.  I'd hold off on
>  createing a general purpose "context" until we are certain we need it,
>  and instead add the Principal or User object to the method calls that
>  require it.
>      
I must admit, i don't quite understand the point of passing a user 
principal object as a parameter on method calls. Since it's a security 
thing (cross-cutting concern), it may end up being used on a lot of 
calls to the db.

Will this make api easier to understand? How are you going to use the 
principal in those calls? Are you planning on making an explicit method 
call to verify authorization?

Personally, I prefer a declarative approach to handle roles-based 
authorization, and guice-aop makes that quite feasible (and less 
intrusive compared to explicit calls to handle security). Bryan posted a 
link to a toy interceptor that I used to verify the above approach, if 
that's of any help.

>  I missed the JAAS discussion, as I think it happened prior to me
> joining
>  the team.  Why did we remove JAAS, and why do we think we might want it
>  back now?
>
>      
JAAS was removed because we can't mix non-JAAS and JAAS authentication 
in the way we need, and it's rather inconvenient to work with (jaas 
module has to be deployed at the container level, and therefore must be 
independent of the rest of the application.) The only reason JAAS was 
looked at was to support SSL-cert authentication, but it can be handled 
with a servlet filter.
> >>
> >>        
> >>> -- bk
> >>>
> >>>
> >>>          
> >> _______________________________________________
> >> candlepin mailing list
> >> candlepin(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/candlepin
> >>
> >>
> >>        
> > _______________________________________________
> > candlepin mailing list
> > candlepin(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/candlepin
> >
> >      
>  _______________________________________________
>  candlepin mailing list
>  candlepin(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/candlepin
>      
-d

[Justin Harris]

----- "Dmitri Dolguikh" <dmitri(a)redhat.com&gt; wrote:

>  On 04/01/2010 12:35 PM, Adam Young wrote:
>  > On 04/01/2010 11:20 AM, Dmitri Dolguikh wrote:
>  >    
>  >> On 04/01/2010 12:16 PM, Justin Harris wrote:
>  >>
>  >>      
>  >>> ----- "Bryan Kearney&quot;&lt;bkearney(a)redhat.com&gt;    wrote:
>  >>>
>  >>>
>  >>>
>  >>>        
>  >>>> On 04/01/2010 10:55 AM, Justin Harris wrote:
>  >>>>
>  >>>>
>  >>>>          
>  >>>>> ----- "Bryan Kearney&quot;&lt;bkearney(a)redhat.com&gt;    
> wrote:
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>>            
>  >>>>>> On 04/01/2010 10:40 AM, Adam Young wrote:
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>>>> The current implementation of candlepin is complete
> oblivious
>  to
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>>>> the
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>>>> caller.  We can authenticate, but once we do, we do not
>  tailor
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>> the
>  >>>>
>  >>>>
>  >>>>          
>  >>>>>>> output of the calls based on who logged in.
>  >>>>>>>
>  >>>>>>> If we are to implement the multi-org functionality, we need
>  to
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>>>> rpovide a
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>>>> mechanism for checking "who asked this."
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> For example, on  ConsumerResource.list is implemented as:
>  >>>>>>>
>  >>>>>>>        public List<Consumer>      list() {
>  >>>>>>>               return consumerCurator.findAll();
>  >>>>>>>           }
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> To filter this via user, we have three choices.  I'm
> going to
>  use
>  >>>>>>> rincipal for the user, as we don't havea first calss
> user
>  object
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>>>> yet,
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>>>> but we can change that later.
>  >>>>>>>
>  >>>>>>> 1.  Change the method signature
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>        public List<Consumer>      list(Principal p) {
>  >>>>>>>               return
>  consumerCurator.findByOwner(getOwner(p));
>  >>>>>>>           }
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> 2.  Add it to the ConsumerResource constructor via
> dependency
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>>>> injection.
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>>>> (Note that I wouldn't really implement getOwner this
> way, just
>  to
>  >>>>>>> demostrate)
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>        public List<Consumer>      list() {
>  >>>>>>>               return
>  >>>>>>>
>  consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
>  >>>>>>>           }
>  >>>>>>>
>  >>>>>>> 3.  Fetch it from a context like JNDI
>  >>>>>>>
>  >>>>>>>        public List<Consumer>      list() {
>  >>>>>>>               Principal p = (Principal)new
>  >>>>>>> InitialContext().resolve(Principal.class.getName());
>  >>>>>>>               return
>  consumerCurator.findByOwner(this.getOwner(p));
>  >>>>>>>           }
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> Option 1 is best for cases where this is going to be only
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>> required
>  >>>>
>  >>>>
>  >>>>          
>  >>>>>> for
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>>>> one or two methods.  THe Principal will be needed for just
>  about
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>>>> every
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>>>> method.
>  >>>>>>>
>  >>>>>>> Option 2 means that the Resource Objects will no longer be
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>>>> stateless,
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>>>> but instead will have to be created either on each request,
>  or
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>> once
>  >>>>
>  >>>>
>  >>>>          
>  >>>>>> per
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>>>> session
>  >>>>>>>
>  >>>>>>> Option 3 menas we have non-explicit dependencies.
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> Do we need a meeting for this?
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>                
>  >>>>>> I would say no, and I would be +1 for the Option 3. I would
>  suggest
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>> we
>  >>>>
>  >>>>
>  >>>>          
>  >>>>>> use a Context object which could hide me from JNDI, Guce, or
>  name
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>> your
>  >>>>
>  >>>>
>  >>>>          
>  >>>>>> magic thread local pattern..
>  >>>>>>
>  >>>>>>
>  >>>>>>              
>  >>>>> I think that this is a losing argument for me, but I am going
>  to
>  >>>>>
>  >>>>>
>  >>>>>            
>  >>>> echo that I think having a resource look different depending on
>  who is
>  >>>> looking at it violates RESTiness and also sets us up for a tough
>  road
>  >>>> wrt maintenance.  I really would like to explore organizing our
>  URLs
>  >>>> to specify the collections more accurately, and using the
>  user/roles
>  >>>> to either allow or deny access - and that is all.
>  >>>>
>  >>>>
>  >>>>          
>  >>>>>      - Justin
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>>            
>  >>>> This is a red herring a bit in the discussion. Think of it how do
>  you
>  >>>>
>  >>>> get data from the resource into the curator.
>  >>>>
>  >>>> FWIW.. I dont think it does violate restfullness. I am seeing
>  eaxmples
>  >>>>
>  >>>> of people using media to coerce what comes back. User and
>  security is
>  >>>>
>  >>>> not much different.
>  >>>>
>  >>>>
>  >>>>          
>  >>> Yes I see your point now.  Sorry about that. :)   Has anyone
>  looked into if Guice can do a lot of this for us?  I'm not sure about
>  the component lifecycles for Guice, but I know that for example Seam
>  will do dependency injection per request, so that we can have our auth
>  filters set up the current Owner, Roles, etc. and just pass those in
>  as parameters to the resource (or curators).  Relying on the DI
>  framework can also simplify unit testing because you just pass in what
>  you want and don't have to worry about mocking out JNDI contexts which
>  would make me want to punch myself in the face.
>  >>>
>  >>>
>  >>>        
>  >> Yup. we can have http-request-scoped objects. And a custom
>  'provider' to
>  >> inject those.
>  >> -d
>  >>
>  >>      
>  >
>  >
>  > Yep.  The reason to not do that is to limit the amount of DI
>  overhead
>  > per request call.    We aren't doing that thus far, but we might
>  want to
>  > do so in the future.
>  >    
>  Majority of DI overhead comes from guice creating proxies, executing
>  aop 
>  interceptors and such. We use guice already and are paying this price.
>  
>  Guice is also one of the faster di frameworks out there. 
Yeah +1 on this.  When we start to single out Guice as bottleneck for 
performance problems, I think we have other issues.


>  >
>  > Of course, then you have the question about making all object
>  references
>  > into instance variables.
>  >
>  > What my gut is telling me is that stuff that survives over multple
>  > requests should be member variables of the Resources, and stuff that
>  is
>  > per-request should be parameters to functions.  I'd hold off on
>  > createing a general purpose "context" until we are certain we need
>  it,
>  > and instead add the Principal or User object to the method calls
>  that
>  > require it.
>  >    
>  I must admit, i don't quite understand the point of passing a user 
>  principal object as a parameter on method calls. Since it's a security
>  
>  thing (cross-cutting concern), it may end up being used on a lot of 
>  calls to the db.
>  
>  Will this make api easier to understand? How are you going to use the
>  
>  principal in those calls? Are you planning on making an explicit
>  method 
>  call to verify authorization?
>  
>  Personally, I prefer a declarative approach to handle roles-based 
>  authorization, and guice-aop makes that quite feasible (and less 
>  intrusive compared to explicit calls to handle security). Bryan posted
>  a 
>  link to a toy interceptor that I used to verify the above approach, if
>  
>  that's of any help.
>  
>  > I missed the JAAS discussion, as I think it happened prior to me
>  joining
>  > the team.  Why did we remove JAAS, and why do we think we might want
>  it
>  > back now?
>  >
>  >    
>  JAAS was removed because we can't mix non-JAAS and JAAS authentication
>  
>  in the way we need, and it's rather inconvenient to work with (jaas 
>  module has to be deployed at the container level, and therefore must
>  be 
>  independent of the rest of the application.) The only reason JAAS was
>  
>  looked at was to support SSL-cert authentication, but it can be
>  handled 
>  with a servlet filter.
>  >>>
>  >>>        
>  >>>> -- bk
>  >>>>
>  >>>>
>  >>>>          
>  >>> _______________________________________________
>  >>> candlepin mailing list
>  >>> candlepin(a)lists.fedorahosted.org
>  >>> https://fedorahosted.org/mailman/listinfo/candlepin
>  >>>
>  >>>
>  >>>        
>  >> _______________________________________________
>  >> candlepin mailing list
>  >> candlepin(a)lists.fedorahosted.org
>  >> https://fedorahosted.org/mailman/listinfo/candlepin
>  >>
>  >>      
>  > _______________________________________________
>  > candlepin mailing list
>  > candlepin(a)lists.fedorahosted.org
>  > https://fedorahosted.org/mailman/listinfo/candlepin
>  >    
>  -d
>  _______________________________________________
>  candlepin mailing list
>  candlepin(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/candlepin

[Adam Young]

On 04/01/2010 12:28 PM, Dmitri Dolguikh wrote:
>  On 04/01/2010 12:35 PM, Adam Young wrote:
>     
> > On 04/01/2010 11:20 AM, Dmitri Dolguikh wrote:
> >
> >      
> >> On 04/01/2010 12:16 PM, Justin Harris wrote:
> >>
> >>
> >>        
> >>> ----- "Bryan Kearney"<bkearney(a)redhat.com>     wrote:
> >>>
> >>>
> >>>
> >>>
> >>>          
> >>>> On 04/01/2010 10:55 AM, Justin Harris wrote:
> >>>>
> >>>>
> >>>>
> >>>>            
> >>>>> ----- "Bryan Kearney"<bkearney(a)redhat.com>     
> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>              
> >>>>>> On 04/01/2010 10:40 AM, Adam Young wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>>>> The current implementation of candlepin is complete oblivious
> to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>>>> the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>>>> caller.  We can authenticate, but once we do, we do not
> tailor
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>> the
> >>>>
> >>>>
> >>>>
> >>>>            
> >>>>>>> output of the calls based on who logged in.
> >>>>>>>
> >>>>>>> If we are to implement the multi-org functionality, we need
> to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>>>> rpovide a
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>>>> mechanism for checking "who asked this."
> >>>>>>>
> >>>>>>>
> >>>>>>> For example, on  ConsumerResource.list is implemented as:
> >>>>>>>
> >>>>>>>         public List<Consumer>       list() {
> >>>>>>>                return consumerCurator.findAll();
> >>>>>>>            }
> >>>>>>>
> >>>>>>>
> >>>>>>> To filter this via user, we have three choices.  I'm
> going to use
> >>>>>>> rincipal for the user, as we don't havea first calss user
> object
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>>>> yet,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>>>> but we can change that later.
> >>>>>>>
> >>>>>>> 1.  Change the method signature
> >>>>>>>
> >>>>>>>
> >>>>>>>         public List<Consumer>       list(Principal p)
> {
> >>>>>>>                return
> consumerCurator.findByOwner(getOwner(p));
> >>>>>>>            }
> >>>>>>>
> >>>>>>>
> >>>>>>> 2.  Add it to the ConsumerResource constructor via
> dependency
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>>>> injection.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>>>> (Note that I wouldn't really implement getOwner this way,
> just to
> >>>>>>> demostrate)
> >>>>>>>
> >>>>>>>
> >>>>>>>         public List<Consumer>       list() {
> >>>>>>>                return
> >>>>>>>
> consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
> >>>>>>>            }
> >>>>>>>
> >>>>>>> 3.  Fetch it from a context like JNDI
> >>>>>>>
> >>>>>>>         public List<Consumer>       list() {
> >>>>>>>                Principal p = (Principal)new
> >>>>>>> InitialContext().resolve(Principal.class.getName());
> >>>>>>>                return
> consumerCurator.findByOwner(this.getOwner(p));
> >>>>>>>            }
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Option 1 is best for cases where this is going to be only
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>> required
> >>>>
> >>>>
> >>>>
> >>>>            
> >>>>>> for
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>>>> one or two methods.  THe Principal will be needed for just
> about
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>>>> every
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>>>> method.
> >>>>>>>
> >>>>>>> Option 2 means that the Resource Objects will no longer be
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>>>> stateless,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>>>> but instead will have to be created either on each request,
> or
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>> once
> >>>>
> >>>>
> >>>>
> >>>>            
> >>>>>> per
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>>>> session
> >>>>>>>
> >>>>>>> Option 3 menas we have non-explicit dependencies.
> >>>>>>>
> >>>>>>>
> >>>>>>> Do we need a meeting for this?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                  
> >>>>>> I would say no, and I would be +1 for the Option 3. I would
> suggest
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>> we
> >>>>
> >>>>
> >>>>
> >>>>            
> >>>>>> use a Context object which could hide me from JNDI, Guce, or
> name
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>> your
> >>>>
> >>>>
> >>>>
> >>>>            
> >>>>>> magic thread local pattern..
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                
> >>>>> I think that this is a losing argument for me, but I am going to
> >>>>>
> >>>>>
> >>>>>
> >>>>>              
> >>>> echo that I think having a resource look different depending on who is
> >>>> looking at it violates RESTiness and also sets us up for a tough road
> >>>> wrt maintenance.  I really would like to explore organizing our URLs
> >>>> to specify the collections more accurately, and using the user/roles
> >>>> to either allow or deny access - and that is all.
> >>>>
> >>>>
> >>>>
> >>>>            
> >>>>>       - Justin
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>              
> >>>> This is a red herring a bit in the discussion. Think of it how do you
> >>>>
> >>>> get data from the resource into the curator.
> >>>>
> >>>> FWIW.. I dont think it does violate restfullness. I am seeing eaxmples
> >>>>
> >>>> of people using media to coerce what comes back. User and security is
> >>>>
> >>>> not much different.
> >>>>
> >>>>
> >>>>
> >>>>            
> >>> Yes I see your point now.  Sorry about that. :)   Has anyone looked into if
> Guice can do a lot of this for us?  I'm not sure about the component lifecycles for
> Guice, but I know that for example Seam will do dependency injection per request, so that
> we can have our auth filters set up the current Owner, Roles, etc. and just pass those in
> as parameters to the resource (or curators).  Relying on the DI framework can also
> simplify unit testing because you just pass in what you want and don't have to worry
> about mocking out JNDI contexts which would make me want to punch myself in the face.
> >>>
> >>>
> >>>
> >>>          
> >> Yup. we can have http-request-scoped objects. And a custom 'provider' to
> >> inject those.
> >> -d
> >>
> >>
> >>        
> >
> > Yep.  The reason to not do that is to limit the amount of DI overhead
> > per request call.    We aren't doing that thus far, but we might want to
> > do so in the future.
> >
> >      
>  Majority of DI overhead comes from guice creating proxies, executing aop
>  interceptors and such. We use guice already and are paying this price.
>  Guice is also one of the faster di frameworks out there.
>     
> > Of course, then you have the question about making all object references
> > into instance variables.
> >
> > What my gut is telling me is that stuff that survives over multple
> > requests should be member variables of the Resources, and stuff that is
> > per-request should be parameters to functions.  I'd hold off on
> > createing a general purpose "context" until we are certain we need it,
> > and instead add the Principal or User object to the method calls that
> > require it.
> >
> >      
>  I must admit, i don't quite understand the point of passing a user
>  principal object as a parameter on method calls. Since it's a security
>  thing (cross-cutting concern), it may end up being used on a lot of
>  calls to the db.
>     
>  Will this make api easier to understand? How are you going to use the
>  principal in those calls? Are you planning on making an explicit method
>  call to verify authorization?
>
>  Personally, I prefer a declarative approach to handle roles-based
>  authorization, and guice-aop makes that quite feasible (and less
>  intrusive compared to explicit calls to handle security). Bryan posted a
>  link to a toy interceptor that I used to verify the above approach, if
>  that's of any help.
>      
It would still be declarative, and possible still be done by Guice.  
Think of it this way:  A parameter list is a method/functions way of 
declaring what it requires, and the caller has to fill those 
dependencies.  If those dependencies have to last for the lifetime of 
the object, that method is the constructor, and it records them in 
member variables.  OTherwise, the references to those dependencies are 
kept on the stack.  Being that this is Java, we only have those two choices.

If you look at a resource object, right now it only have links to things 
that are application scoped, such as the curators.  Thus, one Resource 
object is OK for the whole application.  If, OTOH, we add in elements of 
the session or the request, we will need one Resource object per request 
or session.

Looking at the ConsumerResource, I see that we are already starting to 
deal with this:  it holds on to an Owner object.  If we are going to 
continue this approach, then we don't need to add it as a parameter to 
the method, as we get it DIed into the objects constructor.

I'm fine with that, especially seeing as we are already doing it.


>     
> > I missed the JAAS discussion, as I think it happened prior to me joining
> > the team.  Why did we remove JAAS, and why do we think we might want it
> > back now?
> >
> >
> >      
>  JAAS was removed because we can't mix non-JAAS and JAAS authentication
>  in the way we need, and it's rather inconvenient to work with (jaas
>  module has to be deployed at the container level, and therefore must be
>  independent of the rest of the application.) The only reason JAAS was
>  looked at was to support SSL-cert authentication, but it can be handled
>  with a servlet filter.
>     
> >>>
> >>>          
> >>>> -- bk
> >>>>
> >>>>
> >>>>
> >>>>            
> >>> _______________________________________________
> >>> candlepin mailing list
> >>> candlepin(a)lists.fedorahosted.org
> >>> https://fedorahosted.org/mailman/listinfo/candlepin
> >>>
> >>>
> >>>
> >>>          
> >> _______________________________________________
> >> candlepin mailing list
> >> candlepin(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/candlepin
> >>
> >>
> >>        
> > _______________________________________________
> > candlepin mailing list
> > candlepin(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/candlepin
> >
> >      
>  -d
>  _______________________________________________
>  candlepin mailing list
>  candlepin(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/candlepin
>

[Adam Young]

Regarding this:


  // FIXME Why is this in here?
         if (username != null) {
             this.owner = ownerCurator.lookupByName(username);
             if (owner == null) {
                 owner = ownerCurator.create(new Owner(username));
             }
         }


I think I can answer that question.  All of the other objects injected 
into the ConsumerResource are globally named objects.  Username comes 
from the request, and is resolvable from there.  To get the right  
owner, you bascially have to do the lookup specified in the constructor.

If I understand Guice correctly, we need to register a means of doing 
this lookup that would look something like this:

class OwnerFactory{
     public OwnerFactory(User u, OwnerCurator curator){
     }

     Owner fetch(){
         curator.findByUser(u);
     }
}

[Bryan Kearney]

As I said in the call.. I assume the resolution to this comes out of the 
owner story. While the owner story may not require roles, the soltuion 
for passing data should support roles as well in the future.

-- bk

[Dmitri Dolguikh]

On 04/01/2010 11:55 AM, Justin Harris wrote:
>  ----- "Bryan Kearney"<bkearney(a)redhat.com>  wrote:
>
>     
> > On 04/01/2010 10:40 AM, Adam Young wrote:
> >      
> >> The current implementation of candlepin is complete oblivious to
> >>        
> > the
> >      
> >> caller.  We can authenticate, but once we do, we do not tailor the
> >> output of the calls based on who logged in.
> >>
> >> If we are to implement the multi-org functionality, we need to
> >>        
> > rpovide a
> >      
> >> mechanism for checking "who asked this."
> >>
> >>
> >> For example, on  ConsumerResource.list is implemented as:
> >>
> >>     public List<Consumer>   list() {
> >>            return consumerCurator.findAll();
> >>        }
> >>
> >>
> >> To filter this via user, we have three choices.  I'm going to use
> >> rincipal for the user, as we don't havea first calss user object
> >>        
> > yet,
> >      
> >> but we can change that later.
> >>
> >> 1.  Change the method signature
> >>
> >>
> >>     public List<Consumer>   list(Principal p) {
> >>            return consumerCurator.findByOwner(getOwner(p));
> >>        }
> >>
> >>
> >> 2.  Add it to the ConsumerResource constructor via dependency
> >>        
> > injection.
> >      
> >> (Note that I wouldn't really implement getOwner this way, just to
> >> demostrate)
> >>
> >>
> >>     public List<Consumer>   list() {
> >>            return
> >> consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
> >>        }
> >>
> >> 3.  Fetch it from a context like JNDI
> >>
> >>     public List<Consumer>   list() {
> >>            Principal p = (Principal)new
> >> InitialContext().resolve(Principal.class.getName());
> >>            return consumerCurator.findByOwner(this.getOwner(p));
> >>        }
> >>
> >>
> >>
> >> Option 1 is best for cases where this is going to be only required
> >>        
> > for
> >      
> >> one or two methods.  THe Principal will be needed for just about
> >>        
> > every
> >      
> >> method.
> >>
> >> Option 2 means that the Resource Objects will no longer be
> >>        
> > stateless,
> >      
> >> but instead will have to be created either on each request, or once
> >>        
> > per
> >      
> >> session
> >>
> >> Option 3 menas we have non-explicit dependencies.
> >>
> >>
> >> Do we need a meeting for this?
> >>        
> > I would say no, and I would be +1 for the Option 3. I would suggest we
> >
> > use a Context object which could hide me from JNDI, Guce, or name your
> >
> > magic thread local pattern..
> >      
>  I think that this is a losing argument for me, but I am going to echo that I think having
> a resource look different depending on who is looking at it violates RESTiness and also
> sets us up for a tough road wrt maintenance.  I really would like to explore organizing
> our URLs to specify the collections more accurately, and using the user/roles to either
> allow or deny access - and that is all.
>
>    - Justin
>
>
>
>      
I'm for #3, since we may need user information at various spots (and 
probably should do the authorization check at the curator level, as 
opposed to resource level). I'm also for Justin's idea of better 
organization of collections urls (yes. I changed my mind! I do this all 
the time!).

-d
> > -- bk
> >
> >
> > _______________________________________________
> > candlepin mailing list
> > candlepin(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/candlepin
> >      
>  _______________________________________________
>  candlepin mailing list
>  candlepin(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/candlepin
>

[jesus rodriguez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/01/2010 10:40 AM, Adam Young wrote:
>  The current implementation of candlepin is complete oblivious to the
>
>  caller.  We can authenticate, but once we do, we do not tailor the 
>  output of the calls based on who logged in.
>  
>  If we are to implement the multi-org functionality, we need to rpovide a 
>  mechanism for checking "who asked this."
>  
>  
>  For example, on  ConsumerResource.list is implemented as:
>  
>    public List<Consumer> list() {
>           return consumerCurator.findAll();
>       }
>  
>  
>  To filter this via user, we have three choices.  I'm going to use 
>  rincipal for the user, as we don't havea first calss user object yet, 
>  but we can change that later.
>  
>  1.  Change the method signature
>  
>  
>    public List<Consumer> list(Principal p) {
>           return consumerCurator.findByOwner(getOwner(p));
>       } 
At the risk of bringing up what some folks call 'jerl', we used
this approach in spacewalk at the manager layer (i.e. our curators).
Since we didn't want the managers to worry about request level
details like finding the user. So we made it explicit as part of
the method signature.

At first it feels dirty, but it did make it explicit where the
user was being used to filter the data.

>  2.  Add it to the ConsumerResource constructor via dependency
> injection. 
>  (Note that I wouldn't really implement getOwner this way, just to 
>  demostrate)
>  
>  
>    public List<Consumer> list() {
>           return 
>  consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
>       }
>  
>  3.  Fetch it from a context like JNDI
>  
>    public List<Consumer> list() {
>           Principal p = (Principal)new 
>  InitialContext().resolve(Principal.class.getName());
>           return consumerCurator.findByOwner(this.getOwner(p));
>       } 
I like the idea of a context but *NOT* like the one you described above.

I vote for a combination of *ALL* of the above. In the Resource layer
we have the Context injected into them. Then we lookup the logged in user
from said Context. Then we pass the user down to the Curators.

This allows the resource to use the request context information,
the curators are none the wiser about where the user comes from. It will
make testing the curators easier since you can pass in mock Users. And
the resources can get mock Context objects.

So my vote is for Option 4 :D

jesus

- -- 
jesus m. rodriguez          | jesusr(a)redhat.com
principal software engineer | irc: zeus
red hat systems management  | 919.754.4413 (w)
rhce # 805008586930012      | 919.623.0080 (c)
+---------------------------------------------+
|   "Those who cannot remember the past       |
|    are condemned to repeat it."             |
|                        -- George Santayana  |
+---------------------------------------------+

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAku0teEACgkQvJZ57YntiYM8/wCfaTb1USK60A/ekPElXpHVahMO
> JOAAoI/sR//I62zq5PVNS8AAVkEm6+Bk
> =mFmM
> -----END PGP SIGNATURE-----

[Adam Young]

On 04/01/2010 11:04 AM, Jesus M. Rodriguez wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 04/01/2010 10:40 AM, Adam Young wrote:
>     
> > The current implementation of candlepin is complete oblivious to the
> > caller.  We can authenticate, but once we do, we do not tailor the
> > output of the calls based on who logged in.
> >
> > If we are to implement the multi-org functionality, we need to rpovide a
> > mechanism for checking "who asked this."
> >
> >
> > For example, on  ConsumerResource.list is implemented as:
> >
> >    public List<Consumer>  list() {
> >           return consumerCurator.findAll();
> >       }
> >
> >
> > To filter this via user, we have three choices.  I'm going to use
> > rincipal for the user, as we don't havea first calss user object yet,
> > but we can change that later.
> >
> > 1.  Change the method signature
> >
> >
> >    public List<Consumer>  list(Principal p) {
> >           return consumerCurator.findByOwner(getOwner(p));
> >       }
> >      
>  At the risk of bringing up what some folks call 'jerl', we used
>  this approach in spacewalk at the manager layer (i.e. our curators).
>  Since we didn't want the managers to worry about request level
>  details like finding the user. So we made it explicit as part of
>  the method signature.
>
>  At first it feels dirty, but it did make it explicit where the
>  user was being used to filter the data.
>
>     
> > 2.  Add it to the ConsumerResource constructor via dependency injection.
> > (Note that I wouldn't really implement getOwner this way, just to
> > demostrate)
> >
> >
> >    public List<Consumer>  list() {
> >           return
> > consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
> >       }
> >
> > 3.  Fetch it from a context like JNDI
> >
> >    public List<Consumer>  list() {
> >           Principal p = (Principal)new
> > InitialContext().resolve(Principal.class.getName());
> >           return consumerCurator.findByOwner(this.getOwner(p));
> >       }
> >      
>  I like the idea of a context but *NOT* like the one you described above.
>
>  I vote for a combination of *ALL* of the above. In the Resource layer
>  we have the Context injected into them. Then we lookup the logged in user
>  from said Context. Then we pass the user down to the Curators.
>
>  This allows the resource to use the request context information,
>  the curators are none the wiser about where the user comes from. It will
>  make testing the curators easier since you can pass in mock Users. And
>  the resources can get mock Context objects.
>
>  So my vote is for Option 4 :D
>
>  jesus
>
>  - -- 
>  jesus m. rodriguez          | jesusr(a)redhat.com
>  principal software engineer | irc: zeus
>  red hat systems management  | 919.754.4413 (w)
>  rhce # 805008586930012      | 919.623.0080 (c)
>  +---------------------------------------------+
>  |   "Those who cannot remember the past       |
>  |    are condemned to repeat it."             |
>  |                        -- George Santayana  |
>  +---------------------------------------------+
>
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.9 (GNU/Linux)
> >  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> >
> >  iEYEARECAAYFAku0teEACgkQvJZ57YntiYM8/wCfaTb1USK60A/ekPElXpHVahMO
> >  JOAAoI/sR//I62zq5PVNS8AAVkEm6+Bk
> >  =mFmM
> >  -----END PGP SIGNATURE----- 
>  _______________________________________________
>  candlepin mailing list
>  candlepin(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/candlepin
>      

Be careful we don't end up with reimplementing the Servlet API.  A 
context, or a request object, or whatever you call it, should be type 
safe.  So we specify what is in the context very strictly.  Personally, 
I don't think I want anything more in it than the Principal, as 
everything else can be deduced from that.