industrial-optimization-group / desdeo-webapi Goto Github PK

Right now, many basic user account management features are missing. These include:

• Password recovery
• Changing password
• Deleting one's account
• Email

An email server interface for the backend must be setup for password recovery to work. Right now, emails are not stored for users, so an email field must be specified for the user model as well.

The main branch of the webapi does not consider a parameter for providing an initial solution although it is allowed in the method implementation.

Right now, when a user starts a new interactive method, the old instance of the method is always replaced with the new one. This makes it impossible for a user to start one method, then utilize another method in the meantime, and then return to the first method and continue from where it left.

It can also be beneficial to store the method at each iteration for the user. If pickling works for this, then use pickles. If not, then something else should be devised.

Issue Description:

Our current system does not sufficiently differentiate between various login error types. It uses the same HTTP status code for different types of login failures, making it harder for the client to handle different cases properly. Additionally, the successful login response could be improved to better facilitate client-side usage.

Tasks:

1. Login Error Handling: Implement unique numeric error codes for different types of login failures. This will help the client differentiate between situations such as incorrect username or password.

2. Security vs User Experience: Review the current approach of revealing to the client whether a login failure was due to a non-existent user account or an incorrect password. Evaluate the balance between user-friendliness and security to decide if this practice should be maintained.

3. Login Response: Add a "username" field to the successful login/registration response. The username is currently returned as part of the message, which could lead to issues as the client shouldn't parse important data from a potentially changeable message content.

Generate intermediate solutions should be an option available at any moment and not as an specific step

Issue Description:

The current backend does not validate usernames during registration, allowing even empty strings or strings consisting only of whitespaces to be registered. This leads to unclear and potentially problematic user experiences.

Tasks:

1. Username and password validation: Update the backend to reject usernames and passwords that consist only of whitespace during registration. Usernames and passwords should be properly validated to maintain data integrity and improve user experience.

2. Error handling: When a username is rejected during validation, the server should return a response with a unique numeric error code and a descriptive error message. This will help the client to understand the specific issue and respond accordingly.

3. Existing username detection: If a registration attempt is made with a username that already exists, the server should return a response with a unique numeric error code. Currently, it's not clear to the client if the username is already taken.

4. HTTP Status Codes vs Numeric Error Codes: Consider the use of HTTP status codes for different types of errors instead of or alongside unique numeric error codes. This needs some discussion to determine which method is more common or suitable for our case.