At 09:14 AM 14/06/2007, Max Renshaw-Fox wrote:

>Since roles are kept at database level I assume it would complicate admin
>unduly to use roles for this - even though the engine should know the role
>that is connecting - similarly, I assume, basing it on user name only
>would straight-jacket functionality... Here I run out of knowledge - I'm
>at the level of a user-story - rather than a use-case - for a generic
>implementation.

Roles are an SQL thing. Their function is to "package up" a set of
SQL privileges inside a database. At server level (where
authentication occurs) they are meaningless.

Yes, at the *interface* the client supplies the role to the server by
way of the DBP. But a role can't be tested until the server actually
connects to the database and establishes (a) that the role exists and
(b) that the user (which is by now authenticated at server level) has
permissions for the role.

But the idea of providing the ability to apply roles somehow in the
security database is interesting, if it were tied somehow to a new
table (currently non-existent) in the sec db that mapped alias names
to users and database owners...that might or might not be compatible
with the security structure that Jim Starkey laid out for Vulcan -->
Firebird 3.

I see that Woody and others have moved this thread to firebird-devel,
without supplying much that is useful about requirements. Might I
suggest that the thread be taken instead to firebird-architect, where
it has a better chance of not getting buried in the coal-face debris
of day-to-day development?

When you move threads, it's unhelpful to refer to threads that have
been running in other lists, in anticipation of some kind of osmosis
occurring. Start new threads, supplying all the info that was
interesting when the original thread began in the wrong place....

./heLen