db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [Grant/Revoke]Proposal for invoker/definer model
Date Wed, 15 Mar 2006 15:19:02 GMT
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.


View raw message