This repository contains the development data of the server for a cloud infrastructure service for Optolith Character Generator (https://github.com/elyukai/optolith-client).
The user is supposed to identify himself via a POST request with a JSON body containing the credentials. As return a httpOnly cookie is to be used, which from then on should be sent back by the client to confirm the session.
This is to be done with regard to the fact that httpOnly cookies cannot be accessed via JavaScript.
This type of cookie is automatically sent with every request, but is not readable in JavaScript, which makes it safe from theft by other JavaScript.
Problem
Users should be able to reset their password.
The functionality does not need to be included in the API, as this is not necessarily a CRUD operation.
Possible Solution
A route respectively a controller must accept the email address (the unique identifier) and then send an email with a secret that ensures that the user can reset his password.
Whether the reset is done with a confirmation code/AppURL in a client or a form opened in the browser must be decided.
Alternative Solution
Alternatively, the e-mail can also contain a link that sets a temporary password after confirmation. This password will be sent to the user again by e-mail and the user can change it after successful login.
Should providing a routing endpoint for confirmation of both accounts an emails.
Also should implementing the sending of confirmation mails in user-dependent languages.
The controller should be available as a service to inject it in other actions or controllers, for example, to trigger sending of confirmation emails.
The User Entity should meet the following security requirements in conjunction with the API platform
Can be created at any time
The user must not be activated by default
The e-mail address must not be validated by default
Changes only by the user himself (valid session) or administrators
Delete only by the user himself (valid session) or administrators
Email address and password changes only with valid session and additional confirmation with the current password.
The user has read-only access to attributes relating to the activation and validation process of the account and e-mail address.
Administrators may also have write access to attributes related to the activation and validation process of the account and email address, for example to perform manual activations.
Media objects like images for users and heroes shouldn't be embedded in their respective entity, because of the encoding and persisting of binary data in databases is very inefficient and encoding costs up to 20% more space.
The storage should be done as an API-supported file upload so that other entities should not process the images. Entities that require media data can thus reference one or more MediaObjects. This can be efficiently provided by the web server as a static file, while only a reference of the relative position of the image needs to be stored in the database. This reference should be communicated to the client so that the client can obtain the image in a suitable way. This also ensures that the image data only has to be loaded by the client in case of any changes and that not always the entire image information is provided encoded, for example in the queried user or character entity.
In the first implementation, the character of a user should provide the JSON hero data. The server should automatically maintain the last modification date when a hero is created or updated, to prevent clients that are working with an incorrect time from causing inconsistencies. The owner of a hero should be automatically assigned based on the user session. Avatar and name should be stored as additional meta-data (therefore outside of the JSON hero data) in the database, as they may be needed for preview purposes.
It should be considered if a kind of checksum is created using the hero JSON data to quickly capture changes. But maybe the last change time is already exact enough for this purpose.
The admin area should provide an overview of the collected data and allow necessary changes to them. In the future, the management of additional functions such as status/maintenance management and the control of API functions would be possible. Therefore this should be considered in preparation for this.
Implementation of a custom UserChecker, which checks after authentication if the user is authorized to use services. The return to clients after the failure of such a general authorization should give information about the reason why authorization for use is denied after successful authentication. This includes reasons such as a non-activated user account, for example, because the account activation email was not confirmed by the user.