> > That user function is a brand new issue that I have not as yet
> confirmed.
> > It is on my radar to address. From my recollection, there is no
> > mention of
> > anything that should have changed in the release notes of
> Firebird. If it
> > has changed then the Firebird team may have broken something.
> >
> > Regards,
> > Jason Wharton
>
> to quote FBRelease notes:
> "In Firebird 1.5 the DES algorithm is used twice to hash the
> password: first
> by the client, then by the
> server, before comparing it with the hash stored in security database.
> However, this sequence becomes
> completely broken when the SYSDBA changes a password. The client performs
> the hash calculation
> twice and stores the resulting hash directly in the security database."
> .....
> "To be able to use stronger hashes, another approach was called for. The
> hash to be stored on the server
> should always be calculated on the server side. Such a schema
> already exists
> in Firebird -- in the Services
> API. This led to the decision to use the Services API for any client
> activity related to user management. Now, gsec and the
> isc_user_add(modify,
> delete) API functions all use services to access the
> security database."
>
> The services API does not send or return GROUPNAME which the AlterUser
> session function (which uses the isc_user_add API function) relies on.
>
> Alan

let me clarify further.
The Services API does not provide for the retrieval of GROUPNAME. It does,
however, provide for retrieval of GROUPID and USERID (both integer values).
Previously, direct access to the security DB was the only way to retrieve
GROUPNAME. This has now been denied.
The Services API provides for the creation of a user including GROUPNAME
field value.
The AlterUser function is not "broken" in this regard but since retrieval of
the GROUPNAME value is impossible, it seems rather mindless to have it or
not note that it's a useless excercise to set it.
AlterUser is documented as providing a means of modifying a user's details.
How do you modify unless you know what you are modifying, i.e retrieval of
existing, which IBO functions does not offer. IBOAdmin functions offer the
means of retrieval but since GROUPNAME is not provided in the buffer, then
aleration of this value of impossible.
The AlterUser function, on the other hand does not offer a means of setting
the USERID or GROUPID which is, in fact, retrieved by the services API.
So it's not "broken" but don't you agree that it needs to be tidied up?
Alan