Replies: 2 comments 3 replies
-
|
thanks for opening this topic @teq0. We're in the process of re-thinking exposed APIs and we'll take this points into consideration. We'll share the initial proposals for an open discussion and contributions |
Beta Was this translation helpful? Give feedback.
-
|
Meanwhile, it's up to the application interacting with immudb server to choose what information to place into the database e.g. you may have a middleware or proxy service that is augmenting the data to be ultimately stored into immudb database |
Beta Was this translation helpful? Give feedback.
-
|
The problem with putting that info into the payload is that it's spoofable. Only the db itself really knows what account was used and the local time that the transaction occurred (up to limits of cluster time sync etc). Even if you put a broker of some sort in front of it (like API facade/gateway or proxy etc) you are just moving the trust to the broker, if it gets compromised then you don't know what data you can trust. Plus you then have to look in two places to get the full audit trail for a value or row. |
Beta Was this translation helpful? Give feedback.
-
|
Agree. The local time is set by the server in the transaction timestamp. The user information could be added into the TxMetadata by the server as well, that's not currently done, would you like to submit a feature request for that? |
Beta Was this translation helpful? Give feedback.
-
|
Sure, I'll create an issue. |
Beta Was this translation helpful? Give feedback.
-
I've been searching the docs and I can't see anything about this. It's important to know that a value/row hasn't been tampered with but it's equally important to know who changed something and when.
This is not the "audit" function (detecting tampering), but it's something an auditor (as in a person) will want to know.
Beta Was this translation helpful? Give feedback.
All reactions