Skip to content

Latest commit

 

History

History
219 lines (191 loc) · 7.48 KB

epersonregistrations.md

File metadata and controls

219 lines (191 loc) · 7.48 KB

EPerson registration Endpoints

Back to the list of all defined endpoints

Main Endpoint

GET /api/eperson/registrations

As we don't have a use case to iterate over all the existent registrations, the main endpoint is not implemented and a 405 error code is returned according to our general error response codes.

Single EPerson registration

As we don't have a use case to retrieve an eperson registration based on the email, the single endpoint is not implemented and a 405 error code is returned according to our general error response codes.

Search EPerson registration

/api/eperson/registrations/search/findByToken?token=<:token>

Exposes the registered email address based on the token or the netId. Also exposes whether it's a new user registration, or a password reset for an existing user. It can expose also metadata involved during the registration process, with the overridden values. Lastly, the registrationType fields is used to discriminate between the registration flow / procedure.

Examples

  1. User registration not linked to an eperson:
{
  "id": 1,
  "email": "[email protected]",
  "user": null,
  "type": "registration",
  "uniqueType": "eperson.registration"
}
  1. User registration linked to an eperson:
{
  "id": 2,
  "email": "[email protected]",
  "user": "028dcbb8-0da2-4122-a0ea-254be49ca107",
  "type": "registration",
  "uniqueType": "eperson.registration"
}
  1. User registration done using orcid that didn't provide an email:
{
  "id": 3,
  "email": null,
  "user": "028dcbb8-0da2-4122-a0ea-254be49ca107",
  "type": "registration",
  "uniqueType": "eperson.registration",
  "registrationType": "orcid",
  "netId": "0000-1111-2222-3333",
  "registrationMetadata": {
    "eperson.orcid": [
      {
        "value": "0000-1111-2222-3333",
        "language": null,
        "authority": "",
        "confidence": -1,
        "place": -1
      }
    ],
    "eperson.firstname": [
      {
        "value": "Power",
        "language": null,
        "authority": "",
        "confidence": -1,
        "place": -1,
        "overrides": "Power U."
      }
    ],
    "eperson.lastname": [
      {
        "value": "User",
        "language": null,
        "authority": "",
        "confidence": -1,
        "place": -1
      }
    ]
  }
}

Note that the registrationMetadata is filled with metadata coming from the external login provider (i.e. ORCID) and enriched with the overrides field containg metadata value coming from the linked user.

In the previous case the eperson.firstname metadata related to the registration-data overrides the value of the metadata previously setted for that related user (i.e. Power U.).

  1. User registration done using orcid that provided an email:
{
  "id": 4,
  "email": "[email protected]",
  "user": "028dcbb8-0da2-4122-a0ea-254be49ca107",
  "type": "registration",
  "uniqueType": "eperson.registration",
  "registrationType": "orcid",
  "netId": "0000-1111-2222-3333",
  "registrationMetadata": {
    "email": [
      {
        "value": "[email protected]",
        "language": null,
        "authority": "",
        "confidence": -1,
        "place": -1,
        "overrides": "[email protected]"
      }
    ],
    "eperson.orcid": [
      {
        "value": "0000-1111-2222-3333",
        "language": null,
        "authority": "",
        "confidence": -1,
        "place": -1
      }
    ],
    "eperson.firstname": [
      {
        "value": "Power",
        "language": null,
        "authority": "",
        "confidence": -1,
        "place": -1,
        "overrides": "Power U."
      }
    ],
    "eperson.lastname": [
      {
        "value": "User",
        "language": null,
        "authority": "",
        "confidence": -1,
        "place": -1
      }
    ]
  }
}

In the previous case the registration has been confirmed by providing a valid email, or just because the orcid login provided an email-account. This email is treated as an additional metadata, but in fact it's just duplicating the email field to provide the overrides fields.

Updated EPerson registration

PATCH /api/eperson/registrations/<:id>?token=<:token>

To update the EPerson registration, perform a patch with the JSON below to the eperson registrations endpoint, by providing the registration token and the id of the registration.

  1. Replace the existing email inside the registration:
[
  {
    "op": "replace",
    "path": "/email",
    "value": [ "[email protected]" ]
  }
]
  1. Add an email inside the registration:
[
  {
    "op": "add",
    "path": "/email",
    "value": [ "[email protected]" ]
  }
]

The allowed path is the one involving the email field, while the operation allowed are:

  • replace - if a different value was set
  • add - if none already set

This method, if successful, will renew the token and as a side effect it will send a new Email to the provided email value.

We can have the following cases:

  • email related to an account: a validation link for reviewing the information is sent to that email address.
  • new email: a link to the same authentication method provided is sent to that email address

Status codes:

  • 204 Created - if the operation succeed with a new token generated, and e new mail sent to the email provided in the request
  • 401 Unauthorized - if registration is disabled the token provided is not valid or absent
  • 422 Unprocessable Entity - if the email address was omitted or the operation is not valid

Create new EPerson registration

POST /api/eperson/registrations?accountRequestType={requestType_forgot_or_register}

To create a new EPerson registration, perform a post with the JSON below to the eperson registrations endpoint (without being authenticated) in this case the groups field must be empty. In case the groups field contains values, then it is interpret as an invitation to register and join these groups. Such invitation can be created only by user that are administrator of all the specified groups.

{
  "email": "[email protected]",
  "type": "registration"
  "groups":[
           "c7a30034-e63d-4109-b47f-e7baf7ca6cc8",
           "d7k77012-s23c-3310-g49a-e2zag9vv6nm1",
           "r9n29111-r53m-3471-y84d-r5haf4ew6ds3"
          ]
}

Requires query parameter 'accountRequestType' set with either 'register' or 'forgot' value, depending on the action requested.

No other properties can be set (e.g. the name cannot be defined) If successful, an email will be sent with a token allowing the user to continue the registration

Verifying whether a new registration can be created can happen using the "epersonRegistration" feature, verified against the site

Status codes:

  • 201 Created - if the operation succeed
  • 400 Bad Request - if e.g. the query param 'accountRequestType' is not present or contains something else than forgot or register
  • 401 Unauthorized - if registration is disabled, you are not authorized to create a new registration
  • 422 Unprocessable Entity - if the email address was omitted or the e-mail address is in a domain that is not allowed in config authentication-password.domain.valid

Forgot password

The same endpoint as Create new EPerson registration is used.

Using the same endpoint ensures it's not possible for a malicious user to identify which email addresses are registered by attempting a registration and verifying whether the account exists