Subject | Re: [Firebird-Architect] Re: Database Culture and Progress |
---|---|
Author | Jim Starkey |
Post date | 2005-08-06T22:19:51Z |
Roman Rokytskyy wrote:
prepare. Netfrastructure implements both an API:
Connection::assumeRoles(); // establishes a mark point for
subsequent reversion
Connection::assumeRole(const char *roleName);
Connection::dropRole(const char* roleName);
Connection::revert(); // drops all roles assumed
since prior assumeRoles()
There is also "SQL" syntax for these operations, though I just realized
that I never finished the implementation.
to active roles should affect prepared statements.
>>With the scenario in which the app server passes role names (theIt's an awful lot of work and bookkeeping to pass roles on each
>>first one in my last post), there is no need to re-authenticate. So
>>role name(s) can be passed as parameter to _each_ query.
>>
>>
>
>Yes, this would be also possible.
>
>
prepare. Netfrastructure implements both an API:
Connection::assumeRoles(); // establishes a mark point for
subsequent reversion
Connection::assumeRole(const char *roleName);
Connection::dropRole(const char* roleName);
Connection::revert(); // drops all roles assumed
since prior assumeRoles()
There is also "SQL" syntax for these operations, though I just realized
that I never finished the implementation.
>Prepare time is the right time to check permissions. Subsequent changes
>
>
>>But, taking into account that today in Firebird permissions are
>>checked when a request is prepared ...
>>
>>
>
>That's the problem. And doing it other way would cost some CPU cycles,
>we have to check how many.
>
>
>
to active roles should affect prepared statements.