Hiding the Firebird password when connecting using a macro

[nexturejohn]

Hi, in previous posts I had queried how to connect LIbreOffice 6.3 on a Windows machine to a Firebird 3.0 server.
(Macro to connect LibreOffice Base to Firebird Server).
Wth the help of Ratslinger, this was successfully solved.
I would now like to hide the plainview password that is used in the macro:

 oDocStatus.DataSource.Password = "masterkey"

Is there anyway that this can be hidden? (obviously the password will not be “masterkey”)
This because I am now porting the solution to Lubuntu in a multi-user environment and I am not happy that the password can be viewed (or would this not be viewable by a determined user anyway?).
Thanks for your help.

[Ratslinger]

Hello,

You can protect libraries (other than ‘Standard’) from being viewed by password protecting it.

From menu Tools->Macros->Organize Dialogs. Then on the Libraries tab, create a new library for your macro. Once the library is created single click to highlight it then select the Password... button to enter:

Be aware that libraries other than the Standard library are not loaded initially and need to be loaded before accessible. For more on that see this post → BASIC Calc: How to work with various Libraries ?

[nexturejohn]

Thanks for replying. I am not sure how to structure this, however, so as to avoid a Catch 22 situation.
I have tried the following.

1. moved my "connect_to_database macro into a “safe” library that is password protected
2. at Document Open time, within a non-protected macro called “load_safe_library”, to load the “safe” library
3. to then call the “connect_to_database” macro to enable connection to the Firebird 3 server
   I am not sure “where” and “how” to execute this 3rd point. I have already used the Open Document event to load the “safe” library. If I simply try to call the “connect_to_database” macro from the “load_safe_library”, what name do I use, as the macro is somewhere else and non in the same standard module? Can you clarify these steps? Thanks

[Ratslinger]

There is nothing mysterious in doing this. If you originally had “connect_to_database” sub in Standard and moved it to a safe library you still call it the same way. You simply need to load the library first. So in Standard library called from Open Document event you would have:

Sub load_safe_library
    If Not BasicLibraries.isLibraryLoaded("YOUR_LIBRARY_NAME") then
        BasicLibraries.loadLibrary("YOUR_LIBRARY_NAME")
    Endif
    connect_to_database
End sub

The only situation is that “connect_to_database” cannot be called until the library is loaded.

[nexturejohn]

great! Thanks again for this.
EDIT
I have tried it and it works and the connect_to_database macro is executed within the SafeLibrary. I still have a doubt though, probably unfounded, and I would appreciate your advice. If we come back to my original question, the password is still in plain text in the connect_to_database macro. I was hoping to hide this, perhaps using something similar to the functioning of .htpasswd in Unix, where the password is stored in an encrypted mode. But my question is “is all of this necessary”? “Are the passwords always in plain text in these connect macros”? Will a determined user be able to see the plain-view password? Do I just forget about all of this and leave the password in clear text?
END EDIT

[Ratslinger]

Password protecting the library will help deter seeing the macro and its’ content. Unfortunately, a knowledgeable person with the right tools can still find this password. The actual storage of an encrypted password is in the database. You can either go back to having the user enter a password, or maybe more preferable, create a user just for this purpose which has minimal rights. If so, you can create an optional dialog to allow you to enter different credentials for elevated privileges. With code if the user enters nothing your default is used to log in.

Bottom line is the user name and password is meant to be controlled by the DB not by a front end processor. Some databases even allow a user with no password to be created and used.

Edit: It also is confusing that you want to automatically allow anyone to sign in without a password (thus giving them the password) but still want the password hidden. What then is the purpose of even having a password?

[Ratslinger]

@nexturejohn,

BTW, have been able to have user create DB in FlameRobin. Make certain user has been granted the create - GRANT CREATE DATABASE

From FlameRobin question - Not certain you saw this so thought I’d post here as well.

[nexturejohn]

“What then is the purpose of even having a password”?, you ask. At present I am still experimenting on the Windows machine, and setting up the various mechanisms. Once the Libreoffice program is ported to the Unix server, all users will have to sign in with a password to be able to use the LibreOffice front-end, and through it access the photographs that will be on the Firebird server. I wanted to avoid any malicious user from being able to “see” the password necessary to connect to the databases on the server, or for them to be able to manipulate the photographs, which are copyrighted.

[nexturejohn]

Concerning FlameRobin, yes I did see that, thank you, and yes the user had been granted the create. It still didn’t work though, unless the suer was sysdba.

[Ratslinger]

If you are concerned with user capabilities, create a user with lesser rights such as read only. Seems that is all that is needed.

As for FlameRobin, sorry but can’t help further - works for me. Have no other suggestion.

Edit:

I don’t believe you got my point. With the user automatically signed in (password in macro) whether they can see the password or not they have access to the database. So in effect the password has no value. Also with linked images the actual image is outside of the database itself. For that you need to protect access to the hardware. That is a topic outside of this venue.