Database Token List Persister
This plug-in allows you to specify extra where clauses and search filters to select the set of users.
How this plug-in finds a user record
There are two ways how this plugin finds a user record for getting user data, updating user data and deleting user data. The user record is always fetched using a select statement given a primary key and applying the configured filters (additional where clause). The two variants differ in how the primary key is determined:- The primary key for selecting the user record is the username itself. This is by far the most common and most efficient method to obtain user data.
- The primary key is determined by a separate query including the username. The query can be configured. This way of selecting the user record is more flexible but results in an additional select statement.
Estimate for the Length of the Token List Database Field
The length of the encoded token hash list depends mainly on the number of unused tokens in the list, the used hash function and the encoding of the list. Here is an example using the SHA1PasswordHash as hashfunction (which produces 40 bytes for each token) together with the hashed token list encoding used by this persister implementation (actually it is the encoding provided byTokenListHasher#hashedTokenListToBytes(HashedTokenList) ):Each unused token uses 40 bytes for the hash value, 4 bytes for the index and 4 bytes for the length of the hash value, thus 48 bytes. Due to the nature of the hash function, this figures are independent of the length of the tokens.
Additionally the encoded list holds the number of the tokens (when the list was new) in 4 bytes, the length of the identification string in 4 bytes, the identification string of arbitrary length and the generation timestamp in 8 bytes. This makes another 16 bytes excluding the identification string.
If the list has 100 tokens and the identification string is 20 bytes at most, this makes 100 * 48 + 16 + 20 = 4836 bytes.
sqlDataSource) tokenListTableName) colUserName) userNameResolveQuery) Such a query is useful if the username (used on the login page) is not part of the user table.
The query must be such that - given the username - it returns one value that can be used as primary key in the user table. The query must contain one question mark (?) which will be substituted by the username (a string).
If the query returns no records, it results in the user not being found.
If the query returns more than one record, it results in the username being ambiguous.
If this property is not defined, the username itself is used as primary key in the user table (the usual and efficient way).
Note: If this property is defined, user insertion by this plugin is no more possible.
colTokenList) colNewTokenList) colGenerationTimeStamp) DATETIME or TIMESTAMP colDeliveryTimeStamp) DATETIME or TIMESTAMP colOtherCredentialsDeliveryTimestamps) colListActive) CHAR or NUMBER. The value "0" (zero) is treated as false, any other value is treated as true.
If the column is not specified, all token lists are considered to be active.
colChallengeOpenSince) DATETIME or TIMESTAMP. colUnansweredChallenges) NUMBER. colNewListOrdered) CHAR or NUMBER. The value "0" is treated as false, any other value is treated as true. colNewListOrderedUser) VARCHAR. colNewListOrderedDate) DATETIME or TIMESTAMP. additionalWhereClause) The SQL query without an additional where clause is "SELECT * FROM token-list-table WHERE colusername = 'username'"(real values for "token-list-table", "colusername" are taken from the configuration and "username" is taken from the token list object).
The SQL query with an additional where clause "xyz" is: "SELECT * FROM token-list-table WHERE colusername = 'username' AND xyz".
Example: If the value of this configuration setting is "GROUP = 'a' AND COD = 1" the resulting query is "SELECT * FROM token-list-table WHERE colusername = 'username' AND GROUP = 'a' AND COD = 1"
additionalIteratorWhereClause) iteratorQuery) Specifying such a query is only necessary if the username cannot be used as primary key in the user table (this only if property "user-name-resolve-query" is specified).
The query must be such that it returns one-column records one username (userid) per row.
Note that his query is used both when returning all user ids and when returning only matching user ids (filtered by the user). Thus, the query must be such that LIKE-clauses against context data columns work. This usually means that you must join the result with the user table (even if the user id is not read from the usertable) so the LIKE-clauses can access the context data of the user table. Failing to do so will result in runtime SQL syntax exceptions!Note: If this property is specified, additional-iterator-clauses and the deleted flag is ignored. They must be part of the query itself!
contextDataItems) colVersionId) Such a technical column is used by some applications or libraries (such as Hibernate) to implement optimistic locking.
Note that this plugin still uses its own data-based optimistic locking mechanism. It just increments the value within a transaction in order to be compliant with other components' locking mechanisms.
The column must be of an integer type. Usually a long type is used.
colRecordModificationDate) The type of the column must be compatible with a timestamp.
Note that - if configured (see separate property) - user information may also be written to the database at the same time.
colRecordModificationUser) Note that - if configured (see separate property) - the modification date may also be written to the database at the same time.
recordModificationUser)
type: DatabaseTokenListPersister
id: DatabaseTokenListPersister-xxxxxx
displayName:
comment:
properties:
additionalIteratorWhereClause:
additionalWhereClause:
colChallengeOpenSince:
colDeliveryTimeStamp:
colGenerationTimeStamp:
colListActive:
colNewListOrdered:
colNewListOrderedDate:
colNewListOrderedUser:
colNewTokenList:
colOtherCredentialsDeliveryTimestamps:
colRecordModificationDate:
colRecordModificationUser:
colTokenList:
colUnansweredChallenges:
colUserName:
colVersionId:
contextDataItems:
iteratorQuery:
recordModificationUser: Medusa
sqlDataSource:
tokenListTableName:
userNameResolveQuery: