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:

  • 'sign_key'
  • 'crypt_key'
  • '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,
i   time,

  * primary key
i   has dedicated index

Discussion welcome.

Last modified 10 years ago Last modified on Jun 25, 2012, 7:57:43 PM