You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support for Real Application Security (RAS) Sessions #1258
As a tester
I would like to automate the testing of my RAS Policies using utPLSQL
So that my application becomes (and remains) secure
Real Application Security (RAS) is like VPD on steroids.
It supports stateless application like APEX. The ease of swapping sessions, at the pl/sql level, makes it ease to proxy different users and, thus, automating testing.
Adding RAS support to utPLSQL would simplify automated security policy testing.
Why can't this be simple beforeall and afterall procedures depending on requirements on suite, context or procedure?
It's sounds like we don't getting any functionality other than wrapping existing procedures and creating aliases.
The implementation of that will be quite complex and not sure it outweight benefit and cannot be achieved other, simpler way. Annotations resolution can get pretty complex.
I'm making here also assumption that this feature is free.
What is exactly that you trying to achiev. What is scenario?
I'm making here also assumption that this feature is free.
DB Feature is free but not available on SE (XE/FREE? yes)... oh, and only for 12c+.
Within my fork+branch, I'm trying to ensure base code can still compile on 11g and SE by keeping all RAS related code as an "optional install". Your platform doesn't support RAS? don't install/use that code. (Also, there are some setup things that can't be done as ADMIN - the initial ADB DBA account on OCI).
The core RAS Session management code I have is its own type that can be called within the test procedure body (ie the simpler way). Every test can use a different session with different settings (roles, context) that are persisted between attach_session calls of the same sessionid;
Why can't this be simple beforeall and afterall procedures depending on requirements on suite, context or procedure?
I'm still exploring this option myself.
The problem I see right off is: I don't think you have a --%finalize annotation that I can use to ensure that the DB session is detached and destroy_session is called for all created sessions at the end of a test run, even if errors have occurred.
One theoretical problem I'm keeping an eye on is if usage of RAS (in your suggested pattern) will interfere with currently available reporters. Worst case scenario: in order to avoid any side effects, the SQL statement used by dbms_sql.parse would need to include the attach/detach_session calls. I'm hoping to avoid this too.
Oh .. and transaction control (--%rollback()) might go out the window due to the statelessness of RAS Sessions. Whoever calls detach_session may need to know whether to set the first parameter as TRUE (rollback) or FALSE (commit - default)..
Context information is definitely "lost" when you attach_session; a list of attributes is needed to future-proof the copying of sys_context values to a Namespace (xs_sys_context). That list is also needed for when the installer creates the Namespace (RAS version of Context) in the first place. note I'm improving the code I have ATM to be more 11g/SE friendly.
In order to align with RAS Procedures, annotations were renamed to:
--%xsuser
--%xsextuser
--%xsrole
--%xsextrole
--%xsdisableroles
--%xsnsattr
All annotations are working as expected.
Current Problem: Test results ( ut.expect().to_equal() ) are not being transferred out of the RAS Session and into the Reports causing the Test Pass/Fails counts to not be reported properly (if at all).
Activity
MikeKutz commentedon Jun 25, 2023
forked and branched w/ initial upload.
Right now, I'm trying to figure out how to get the annotation information to the event listener w/o modifying
ut_event_itemlwasylow commentedon Jun 25, 2023
Why can't this be simple beforeall and afterall procedures depending on requirements on suite, context or procedure?
It's sounds like we don't getting any functionality other than wrapping existing procedures and creating aliases.
The implementation of that will be quite complex and not sure it outweight benefit and cannot be achieved other, simpler way. Annotations resolution can get pretty complex.
I'm making here also assumption that this feature is free.
What is exactly that you trying to achiev. What is scenario?
Cheers Lukasz
MikeKutz commentedon Jun 26, 2023
DB Feature is free but not available on SE (XE/FREE? yes)... oh, and only for 12c+.
Within my fork+branch, I'm trying to ensure base code can still compile on 11g and SE by keeping all RAS related code as an "optional install". Your platform doesn't support RAS? don't install/use that code. (Also, there are some setup things that can't be done as
ADMIN- the initial ADB DBA account on OCI).The core RAS Session management code I have is its own type that can be called within the test procedure body (ie the simpler way). Every test can use a different session with different settings (roles, context) that are persisted between
attach_sessioncalls of the samesessionid;I'm still exploring this option myself.
The problem I see right off is: I don't think you have a
--%finalizeannotation that I can use to ensure that the DB session is detached anddestroy_sessionis called for all created sessions at the end of a test run, even if errors have occurred.One theoretical problem I'm keeping an eye on is if usage of RAS (in your suggested pattern) will interfere with currently available reporters. Worst case scenario: in order to avoid any side effects, the SQL statement used by
dbms_sql.parsewould need to include theattach/detach_sessioncalls. I'm hoping to avoid this too.Oh .. and transaction control (
--%rollback()) might go out the window due to the statelessness of RAS Sessions. Whoever callsdetach_sessionmay need to know whether to set the first parameter as TRUE (rollback) or FALSE (commit - default)..Context information is definitely "lost" when you
attach_session; a list of attributes is needed to future-proof the copying ofsys_contextvalues to a Namespace (xs_sys_context). That list is also needed for when the installer creates the Namespace (RAS version of Context) in the first place. note I'm improving the code I have ATM to be more 11g/SE friendly.MikeKutz commentedon Jul 26, 2023
UPDATE
In order to align with RAS Procedures, annotations were renamed to:
--%xsuser--%xsextuser--%xsrole--%xsextrole--%xsdisableroles--%xsnsattrAll annotations are working as expected.
Current Problem: Test results (
ut.expect().to_equal()) are not being transferred out of the RAS Session and into the Reports causing the Test Pass/Fails counts to not be reported properly (if at all).jgebal commentedon May 9, 2026
@MikeKutz
It is quite unclear for me what is it that you are proposing in this issue.
Is this an enhancement request?
How is this helping and what is currently missing in utPLSQL that this would address?