[ 
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570007#action_12570007
 ] 

Rick Hillegas commented on DERBY-3327:
--------------------------------------

Thanks for the patch, Dag. As usual, I don't have much to add that's 
substantive. Just a couple points:

o I understand your misgivings about the management of the current schema. The 
existing code is pretty organic at this point.

o There are a couple places in the LCC where you lookup the session context 
based on the Activation. It seems to me that a method like the following might 
be a useful abstraction:

public SQLSessionContext    getCurrentSQLSessionContext( Activation caller )
{
                if (caller == null ) { return getTopLevelSQLSessionContext(); }
                else { return caller.getNestedSQLSessionContext(); }
}


> SQL roles: Implement authorization stack
> ----------------------------------------
>
>                 Key: DERBY-3327
>                 URL: https://issues.apache.org/jira/browse/DERBY-3327
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security, SQL
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>             Fix For: 10.4.0.0
>
>         Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff, 
> DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat, 
> DERBY-3327-4-full.diff, DERBY-3327-4-full.stat
>
>
> The current LanguageConnectionContext keeps the user authorization identifier 
> for an SQL session.
> The lcc is shared context also for nested connections (opened from stored 
> procedures).
> So far, for roles, the current role has been stored in the lcc also. However, 
> SQL requires that
> authorization identifers be pushed on a "authorization stack" when calling a 
> stored procedure, cf.
> SQL 2003, vol 2, section 4.34.1.1 and 4.27.3.
> This allows a caller to keep its current role after a call even if changed by 
> the stored procedure.
> This issue will implement the current role name part ("cell") of the 
> authorization stack. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to