Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44183066.1080107@apache.org>
Date: Wed, 15 Mar 2006 07:19:02 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [Grant/Revoke]Proposal for invoker/definer model
References: <d9619e4a0603131049l3f0d8154l6976eac2ea0be351@mail.gmail.com>
	 <441625D8.1070904@apache.org>
	 <d9619e4a0603132102r15fa5757gb862f54695fe0c11@mail.gmail.com>
 <d9619e4a0603150127w7a559c1ai6951900d1ff6591@mail.gmail.com>
In-Reply-To: <d9619e4a0603150127w7a559c1ai6951900d1ff6591@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mamta Satoor wrote:

> Here is the proposal for invoker/definer model based on StatementContext.

Thanks for the changes, this looks like the correct direction.

>  
> I am proposing that we continue to keep the "invoker" authorizer
> information in GenericeLanguageConnectionContext. In addition to that,
> we will keep a stack of authorizers and corresponding default schema
> descriptors in a StatementContext. When authorizer information (like
> getAuthorizationId, getDefaultSchema, getCurrentSchemaName etc) will be
> requested from LanguageConnectionContext, it will check if it has an
> active StatementContext. If it does have an active
> StatementContext, then the authorization information requested will be
> obtained from authorizer at the top of StatementContext's authorizer
> stack. But if there is no active StatementContext, then authorization
> information requested will come from LanguageConnectionContext's invoker
> authorizer. 

This paragraph talks about a stack of default schemas and current
schemas, but there are no more details of how this will be implemented.
Also, I don't remember anything in the functional spec about how current
or default schema was changing, but I can't get to Jira to check & I
don't have a local copy of the functional spec from DEBRY-464. Just want
to understand what functionality you are proposing to be implemented.

> When authorizer information (like
> getAuthorizationId, getDefaultSchema, getCurrentSchemaName etc)

The etc. is a little worrying in a design spec, which methods are you
changing the behaviour of, is LCC.getAuthorizationId one of them?

Might I suggest some method name changes, for readability and
clarity of meaning?

  addAuthorizerToTopOfStack -> pushAuthorizer
  removeAuthorizerFromTopOfStack -> popAuthorizer

Also, I think for the term "invoker", you really mean "session" in some
cases. E.g. it's not the invoker user identifier or Authorizer, it's the
session's user identifier or Authorizer.


> If an object needs to switch to invoker's authorization, code should be
> generated to get the invoker authorizer from
> GenericLanguageConnectionContext and put that authorizer to the top of
> authorizer stack by generating code addAuthorizerToTopOfStack(Authorizer
> invokerAuthorizer). To get the invoker authorizer, I am planning on
> adding method getInvokerAuthorizer to GenericLanguageConnectionContext.

When can this happen? I don't think this code and the associated new
methods (getInvokeAuthorizer and addAuthorizerToTopOfStack(Authorizer)
are required.

Thanks,
Dan.