onyxmoon / optolith-cloud Goto Github PK

The MediaObject entity should meet the following security requirements in conjunction with the API platform

• Can be created at any time with a valid session
• The logged-in user is automatically recorded as the owner of the created MediaObject
• The query of the image should only be possible for the owner or administrator.

Documentation should define that a IETF language tag should be used for the locale attribute in user entity.

This project depends on symfony with api platform as flex component.

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.

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.

Add documentation for http methods like in /api/users/{id}/credentials

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.

Describe the bug
The client version could be a nonsense string.

To Reproduce
Make a new character and type a non-semver version-string

Expected behavior
A non-semver string should be forbidden

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 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.

An attribute field should not contain string as type, but the correct referenced type.

The standard error page should get overridden.

An application-wide translation service should be used to provide translations for emails and other pages. The api docs haven't to be translated.

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.

The character entity should meet the following security requirements in conjunction with the API platform

• Can be created at any time with a valid session
• The logged-in user is automatically registered as owner of the created character
• Only the owner or administrator should be able to query the character.
• Only the owner or administrator should be able to delete the character.
• Only the owner or administrator should be able to change the character.