Hi Adam.

We too use a centralised system to identify our "Environments" a user has
access to - reading the aliases.conf file so that site admins only have
one place to make changes (we use prefixes to identify access groups -
works well - though I'd prefer a better solution).

I must admit - it would be nice for us to be able to connect to a Firebird
Server and ask "what database files do you know about that I have
permission to use?" without a registration overhead - using the existing
aliases.conf entries.

None of this would need to break anything existing - or add any extra
steps. I'm not even asking for this as a feature - just saying it would be
a nice convenience (one less thing for us to do).

>
> Unlike the other engines you mention, Firebird has no concept of
> database registration.

I don't think this is a necessary prerequisite - it's OK to be "just what
you know about" - rahter than "all databases".

> Aliases.conf is simply a method of abstracting the file system
> location from the client connection string,

Agreed - but it *can* be used by us, or as a table - but only for a
particular database - it would be *nice*, though not necessary, for
Firebird to provide access to the list - with security.

>
> In Firebird, user credentials are controlled by the server, but user
> permissions are stored within the particular database.

This, I agree, is the sticking point - how would Firebird know what to
return - based only on UserName & Password - future security embedded in a
database will make this more difficult as well.

>
> You are free to simplify this for your customers by writing your own
> custom service that returns the aliases. Perhaps a better approach is
> to have a separate file where the DBA can add a list of public aliases
> (so it is only configured once per customer rather than for every
> client workstation). Adding a line to a text file is probably much
> simpler than the registration routine they would have to go through
> for MS-SQL or MySQL.

This is what we do. We initially used a central file - but moved to
reading aliases.conf because the two got out of sync on some sites. Not
ideal - but works and, for our service at least, is secure - Firebird
doing it "properly" would be nicer.

Max