|Version 2 (modified by 5 years ago) (diff),|
Db storage organization for CryptoPlugin
Right now I can think of only two requirements for plugin-specific information:
- user <--> key associations
- (detached) signature storage
Common "parasite" storage
Session attributes are easily accessible related on a client sessions base in Trac's Request object (
req.session), without the need for a direct db connection.
So entries in Trac db table
session_attribute seem like a perfect match for the first requirement - no need for an own db table here.
I've chosen the following dedicated names for related association types:
- 'auth_key' (future)
Their meaning should be easily guessable from these names.
Dedicated "private" storage
For storing signature data we could resort to inline signed data, but I felt that this choice would restrict possible use cases too much. So I chose detached signatures as the default. Resources stay unaltered by signing, and you will be able to sign text content as well as arbitrary binary/file data.
After 3 internal iterations current db schema draft is like so:
table `crypto_sign` * realm, * id, * version, * fragment, i * key_id, signature i time, Legend: * primary key i has dedicated index