‘user_templates’

/api/v1/users/{user_id}/templates

/api/v1/users/{user_id}/templates/{auth_t_id}

Access to user’s authentication templates. Requires logged_session_id of user or admin.

GET

List of user’s linked templates:

GET /api/v1/users/123/templates

Returns:

{ 'templates':
    [
        { 'id': 'xxx',
          'method_id': 'xxx',
          'comment': 'xxx'
        }
    ]
}

POST

Action depends on given data.

1. Create new template from existing enroll session.
2. Create empty template for user (to be filled later by PUT)
3. Link existing template to user.

User becomes owner of created template. Existing enrolled session is destroyed (no way to create 2 templates from same enroll session).

Create template, fill it from enroll session and link to user - pass enroll_process_id:

POST /api/v1/users/123/templates
{
    'enroll_process_id': 'xxx',
    'comment' : 'xxx'  # optional
}

Create template without data (not enrolled template) and link to the user - pass method_id:

POST /api/v1/users/123/templates
{
    'method_id': 'xxx',
    'unit_id ' : 'xxx',  # optional
    'comment'  : 'xxx'   # optional
}

Link existing template to user - pass auth_t_id. Passed logged_session_id must be of admin:

POST /api/v1/users/123/templates
{
    'auth_t_id': 'xxx'
}

After that operation, user 123 may login by ‘xxx’ template owned by some other user, but 123 can’t change it.

PUT

Fill auth template from enroll session and/or change comment:

PUT /api/v1/users/{user_id}/templates/{auth_t_id}
{
    'enroll_process_id': 'xxx',  # optional
    'comment': 'xxx'               # optional
}

DELETE

Unlink user and template. Template is deleted if logged_session_id is of template owner, otherwise - remains in db. It is possible that template become orphan in case when admin unlinks template and it is not linked with any user anymore.

Unlink template 456 from user 123:

DELETE /api/v1/users/123/templates/456