QFQ

Idea: choosing a username when multiple potential accounts are known

This idea is dropped due to minimal usage

QFQ have no direct access to fe_users table and it might be non clear, what is their username. For instance, we may found several accounts in math_db: UZH shortname, I-MATH, T3 local, ...

Multi-row query

Assume that the usernames are fetched in a desired order of preference. Then evaluating the rows one-by-one stops at the first match, because a redirection is triggered.

10.sql = SELECT name AS _authenticated FROM Account
          WHERE pId = {{personId:R}}
          ORDER BY (CASE
             WHEN source = 'math' THEN 0
             WHEN source = 'uzh_shortname' THEN 1
             WHEN source = 't3_local' THEN 2
             WHEN source = 'eduid' THEN 3
          END CASE AS priority) ASC

Multi-username mode

Instead of trying all of them one-by-one, we can allow to specify several usernames at once and let QFQ to pick the best choice. This process can be configured by specifying how the usernames should be prioritized.

10.sql = SELECT 'user1,user,user@email.ch' AS _authenticated

There are three types of usernames:

• non-existing
• locked
• unlocked

At the first step we restrict the list to those that can be authenticated:

• drop locked users if local accounts cannot be unlocked (parameter u:[0|1])
• drop non-existing users if local accounts cannot be created (parameter c:[0|1])

Then the parameter p:<value> (preference or priority) specifies which username is picked. The following modes can be implemented.

Mode	Value	First choice	Second choice	Third choice
none	0	All usernames	---	---
existing	1	Existing usernames	Non-existing	---
unlocked	2	Unlocked or non-existing	Locked usernames	---
available	3	Unlocked and existing	Locked usernames	Non-existing usernames

The value of the p: parameter can be either the number or the mode string.

General usage

1. On a successful authentication an HTTP redirection is triggered and the rendering of the page stops
2. Errors are passed via the {{authResult:V}} variable:
   • LOCKED if the account is disabled, i.e. disable = 1
   • INACTIVE if the account will be enabled in future, i.e. starttime > CURRENT_TIMESTAMP
   • EXPIRED if the account is no longer enabled, i.e. endtime < CURRENT_TIMESTAMP and non-zero
   • NOT_FOUND if no account with the desired username exists

User data
User data: fe_user fields provided as a query string and used when a user is created or modified:

user1|first_name=Joe&last_name=Doe&email=joe.doe@email.com&zip=1234

Internally this string will be encoded in a sip store

Authentication features

• create - a user record is created if none is found
• unlock - a user record is unlocked if disabled
• force - authenticate an existing user even when inactive or locked, but does not activate or unlocks them. This might be useful for the switch user feature. [removed because disabled an inactive accounts are not accepted by Typo3]
• update - the fe_user record is updated with provided data
• activate - an inactive user is activated for a provided time (default in settings)
  • enableUntil - the new expiration timestamp (takes precedence)
  • enableBy - for how long an expired account will be valid

Rendering

The authenticate column extends link with the following syntax

   <username>|<user data>|<auth features>|<link parameters>... 

The rendering mode is picked as follows:

• if the link generates a text, image, button, then the default rendering mode is 0
• otherwise the default rendering mode is 9

Note: the authentication column adds extra parameters once the link URL is already generated. Hence, these extra parameters are not taken into account in rendering mode 8 (pure sip).