The "authenticated" part comes into play when clients attempt to write to the database. Writes fail with an "authentication violation" unless a connection variable has been set that identifies the client program. The command to authenticate looks like this:
set temporary option connection_authentication='Company=companyname;
Application=applicationname;
Signature=hexstring'
Once the right authentication string is sent, writes are enabled. Interestingly enough, writes are always allowed in the first 30 seconds of the connection, a kind of grace period. Since I didn't know about this initially, I was very confused as to why some writes would work and then the rest would fail.
Now, you might think that this is a security feature, but it's basically completely pointless in that role. No connection can be established to the database without a username and password, and in most cases read access is plenty. The authentication string is constant for each application and can't be easily changed, so once it's extracted from a client program (or from the network), other applications can just send the right string and be on their merry way. I believe this feature is actually designed to combat piracy, making it a little more difficult to use a database that came as part of a certain application as a generic database server.
No comments:
Post a Comment