Reading a remote db related post in the Sparkle branch of this forum a shiver went down my spine as I might have a hugen conceptual bug in my application that is short to delivery to the client.
As I had to port a lot from an older vcl application I decided to use remote db and JWT authentication. Within the token I transfer username and machinename that is set into session variables of the firebird session to feed the audit trail via triggers.
From what I read in the sparkle forum remote db pools those connections and reuses them. This would mean that user a initiates the connection with his credentials but an other user could by chance get this database session and write data to the database with the db environment variables created by the first user?
Of course they have different Tokens as I access the databasr with one fixed user but authenticate against a self written user/role system in the database for more flexibility on login and get the Token in return.
Do I have to revise the complete system as I cannot rely on user X never writing with a database session initiated by user Y? OMG...
Hi Michael,
Can you please point to the exact discussion you've read, to better clarify?
Currently RemoteDB doesn't ensure one client will always be using the same server-side database. It can use different ones. But one server-side database cannot (still) be use by different clients. That can change in future, and should not be relied by developers, but probably if we implement it in future we will add a property to enable it and not break existing clients.
What can happen now is this:
1. Client A connects to server. Database-connection X is created for client A
2. Client A keeps using server-side connection X
3. Client A goes idle. Connection X times out and is destroyed.
4. Client A continues working. Database-connection Y is created for client A
5. Client A keeps using server-side connection Y
The above process is transparent to the client. Client A will never know that the server-side connection X was destroyed and a new connection was made. For client A, it will look like it has always been connected.
Wagner
Hi, thanks for the answer nd sorry for forgetting the link, here it ist:
My concern is not a new connection but that an existing connecton is used by a different client. That would lead my audit trail technique using firebird session variables ad absurdum.
So if a server side connection cannot be used by different clients I am safe and happy ;-)
Thanks!
Indeed the mention that "any client can be served by any database from the pool" is wrong. There is no pool, for now. In the context of that thread, I just wanted to mention what I said here: while the client "thinks" it's connected, there might be no server-side connection open there.
Thanks. So my approach is safe. That lets me sleep better ;-)