firebird
firebird copied to clipboard
FirebirdSQL
Remove legacy auth server and user manager
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).
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.
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.
How about removing gsec? It doesn't fully support user management and is outdated. 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. 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.
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.
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 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.
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?