db.Ping() returns Error op_response:92 for Firebird 3.0

[gabrielruschel]

Hello, I've been using this library to connect to a few different FirebirdSQL databases and came across this error. I'm using go1.19 and sqlx to connect to the databases.

Basically, I'm just creating the sqlx.DB connections, and if no error occurred, call db.Ping() to check if it can connect to the database.

The first FirebirdSQL databases that I tested were running with firebird version 2.5 and had no issues with the Ping() and further operations, however, testing with two different databases running with firebird 3.0 returned the error Error op_response:92 after db.Ping()

I'm using the connection string as instructed in the README with no params. In the cases that the error occurred with firebird 3.0, both the application and database were running on Windows 10

db, err = sqlx.Open("firebirdsql", "user:password@localhost:3050/C:\\path\\to\\database"
if err != nil {
    return nil, err
}

db.SetMaxOpenConns(10)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(5 * time.Minute)

err = db.Ping() // <- returns Error op_response:92
if err != nil {
    return
}

I need some help understanding what is causing this error and how to resolve it, I couldn't find anything related in the issues, is there any configs or params that I'm missing? Please let me know if you need more info.

[nakagami]

I think there is an error in authentication. I think you are giving the wrong user or password.

The error message is confusing and should be fixed if it is handled well.

[gabrielruschel]

I tested a connection with an user and password that didn't exist and the error was indeed the same, Error op_response:92.

However, I tested againt with different valid credentials and still had the same error. I could assure that these were valid credentials because I could authenticate with them in the database using different clients, without using this lib or any golang code. I think there is a problem with authentication but I think that a wrong user/password is not the problem here, could it be something else?

[nakagami]

Thanks for your report. I just remembered. A user to login must be in uppercase. Does your Firebird user name contain lowercase letters?

For example, it should be SYSDBA, not sysdba. The connection process is converting the user name to uppercase in an internal process.

I could stop the process of ToUppser(), but that would stop the existing program from working, so I have not changed it.

[gabrielruschel]

In the different Firebird databases that I connected I had both cases where the user was in lowercase and also in uppercase, and both cases were working. This issue only appeared when I tried to connect to a Firebird 3.0 database. In this case where I had this error, I tried to pass the user name with uppercase and still had the same error, so I believe this is not the problem. Maybe something specific to Firebird 3.0?

Just to be sure, the credentials that were given to me the user was lowercase and before opening the connection on the go code I converted to uppercase. I believe is not required that the original database user name to be uppercase, right?

[nakagami]

sorry, I did not communicate well due to my poor language.

• The database user name must be uppercase.
• The database user name in the program can be lowercase, it will be converted to uppercase in the driver.
• The authentication method changed a lot when going from 2.5 to 3.0

[gabrielruschel]

No problem, later I understood what you meant, but unfortunately I believe this is not the reason.

I checked again the credentials I was testing before the user was already uppercase in the database. To doublecheck, a new user "TEST" was created and using this new credentials still returned the same error, so I think the problem is something else.

[nakagami]

Can you tell me what the value of AuthServer in firebird.conf ? It may be commented out and not specified.

For example, a line that looks like this

AuthServer = Srp256,Srp,Legacy_Auth

[gabrielruschel]

In one of the databases with this issue the AuthServer is like this: AuthServer = Legacy_Auth, Srp, Win_Sspi

[nakagami]

I use Ubuntu for both server and client as my testing environment.

Perhaps your environments are both windows? I haven't heard any issue, but Windows client may not handle Legacy_Auth well.

You may need to change your server's firebird.conf to

AuthServer = Srp, Legacy_Auth, Win_Sspi

or

AuthServer = Srp, Win_Sspi

in the server's firebird.conf.

[gabrielruschel]

Yeah, in my case both the application and database are running on a Windows environment. Unfortunately, probably I won't be allowed to change the database configs

Is there a possibility where changing this AuthServer value could break another application that connects to this database? Also, if I can't change this config, is there anything else I could do to try to solve this issue?

[nakagami]

I see, so you are saying that it is difficult to change the server settings?

If the following changes are made

AuthServer = Srp, Legacy_Auth, Win_Sspi

I think it will work with the existing client without any change, since the order of the plugins to try will only change.

Sorry, it doesn't seem possible to connect with this driver without changing the server configuration.

[nakagami]

You may want to specify Srp in auth_plugin_name as follows.

db, err = sqlx.Open("firebirdsql", "user:password@localhost:3050/C:\\path\\to\\database?auth_plugin_name=Srp"

[gabrielruschel]

You may want to specify Srp in auth_plugin_name as follows.

db, err = sqlx.Open("firebirdsql", "user:password@localhost:3050/C:\\path\\to\\database?auth_plugin_name=Srp"

I tested this before changing the firebird.conf configs and it worked on both cases where I had this issue!

What's exactly the difference on using this Srp auth plugin? I'm gonna set this as default for now, but I also wanted to know which options on this argument are available that I may use in the future

[nakagami]

SRP is a highly secure challenge-response type authentication method https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Legacy_Auth, on the other hand, is a much older DES-based password hashing scheme

[gabrielruschel]

Ok then, I think we can close this issue now, thank you very much for your help!