Stateless (Flyweight) and current user

Justin Harris jharris at redhat.com
Thu Apr 1 14:55:47 UTC 2010


----- "Bryan Kearney" <bkearney at 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



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



More information about the candlepin mailing list