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

Knut Anders Hatlen commented on DERBY-3327:
-------------------------------------------

What about changing the names of the methods instead? I don't think it's a bad 
idea to spell out the scope of the role, and I only read Rick's comment as 
saying that it would be good if the names matched.

java.util.Stack is a synchronized collection, by the way, so you may want to 
consider using ArrayList instead. You have already added (push,pop)Caller() 
methods, so the stack abstraction will be preserved even with a different data 
structure.

> 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
>
>
> 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