Remove legacy auth server and user manager #8411
Conversation
|
One of the probably not very clear to the users consequences of this is impossibility of using non-SRP aware clients to work with FB6. I.e. fbclient before v3 will not connect to the FB6 anymore. Hope, someone more knowledgeable points out the versions of other clients that implements wire protocol by itself (at least .Net and Jaybird). |
OTOH, people stuck to update much more their servers than their clients, and it's generally recommended to match major client and server versions. Also, there is no incompatibility of new clients with applications or old servers, there is? It's near 10 years that Firebird 3.0.0 is released and in this tradeof equation, one part that needs to advance with less unneeded obstacles is the Firebird code. |
|
It is about proper communication with users, not about keeping legacy auth. |
|
How about removing |
|
On 1/27/25 09:24, Simonov Denis wrote:
How about removing |gsec|? It doesn't fully support user management
and is outdated.
On the other hand in a case when user has single security DB (take into
an account that all cases with single DB are here) it does work and
supports legacy scripts. Next, user management services (that were never
deprecated) are implemented on top of gsec. I.e. if we remove gsec we
should reimplement them using SQL security. May be first that services
to be deprecated?
In my opinion, there are much more reasons to remove it than Legacy
plugins. I think it's better to move Legacy plugins to separate
dynamic libraries.
Except client auth they are dynamic libraries.
Those who still want to use them, let them use them. In the future, it
will be easier to remove them, since those who still want to use them
can take assemblies from the previous version.
Should add one more problem - if one wants to connect to firebird using
interbase client the only chance is legacy auth. Did not check during
last 3-5 years - but with say FB3 that worked.
|
I mean that they can be taken out of the Firebird project into a separate subproject with plugins. That is, not supplied as part of Firebird, but if desired, given the ability to download separately and configure. These two plugins are needed by a minority, and if they really need them, and not just because they are lazy, then they will be able to download, configure and install them. |
|
On 1/27/25 15:18, Simonov Denis wrote:
Should add one more problem - if one wants to connect to firebird
using
interbase client the only chance is legacy auth. Did not check during
last 3-5 years - but with say FB3 that worked.
I mean that they can be taken out of the Firebird project into a
separate subproject with plugins. That is, not supplied as part of
Firebird, but if desired, given the ability to download separately and
configure. These two plugins are needed by a minority, and if they
really need them, and not just because they are lazy, then they will
be able to download, configure and install them.
May be that makes sense. We may have a library of old plugins (including
old engines) for separate download.
|
I don't think this is a good idea, for example, to correctly work in a database with schemas, these plugins needs maintenance. |
|
On 1/28/25 03:30, Adriano dos Santos Fernandes wrote:
I mean that they can be taken out of the Firebird project into a
separate subproject with plugins. That is, not supplied as part of
Firebird, but if desired, given the ability to download separately
and configure. These two plugins are needed by a minority, and if
they really need them, and not just because they are lazy, then
they will be able to download, configure and install them.
I don't think this is a good idea, for example, to correctly work in a
database with schemas, these plugins needs maintenance.
I.e. gpre needs additional changes to support schemas for non-engine cases?
|
No description provided.