With authentication and some sort of dealing with passwords is related a problem
with forgotten credentials, especilly passwords. People easily forget them and
with forgotten credentials, especially passwords. People easily forget them and
there has to be some kind of mechanism to retrieve a new password or change the
old one. Problem is that it cannot be done in totally secure way, but we can at
least come quite close to it. First, there are absolutely not secure and
recommendable ways to handle that, for example sending the old password through
email. A better, but still not secure solution is to generate a new one and
again send it through email. This solution was provided in CodEx, users had to
write an email to administrator, who generated a new password and sent it back
to the sender. This simple solution could be also automated, but administrator
had quite a big control over whole process. This might come in handy if there
could be some additional checkups for example, but on the other hand it can be
quite time consuming.
recommendable ways how to handle that, for example sending the old password
through email. A better, but still not secure solution is to generate a new one
and again send it through email. This solution was provided in CodEx, users had
to write an email to administrator, who generated a new password and sent it
back to the sender. This simple solution could be also automated, but
administrator had quite a big control over whole process. This might come in
handy if there could be some additional checkups for example, but on the other
hand it can be quite time consuming.
Probably the best solution which is often used and is fairly secure is
following. Let us consider only case in which all users have to fill their
@ -551,13 +551,13 @@ email addresses into the system and these addresses are safely in the hands of
the right users. When user finds out that he/she does not remember a password,
he/she requests a password reset and fill in his/her unique identifier; it might
be email or unique nickname. Based on matched user account the system generates
unique access token and sends it user via email address. This token should be
unique access token and sends it to user via email address. This token should be
time limited and usable only once, so it cannot be misused. User then takes the
token or URL address which is provided in the email and go to the system's
appropriate section, where new password can be set. After that user can sign in
with his/her new password. As previously stated, this solution is quite safe and
user can handle it on its own, so administrator does not have to worry about it.
That is the main reason why this approach was chosen to be used in ReCodEx.
That is the main reason why this approach was chosen to be used.
### Evaluation unit executed by ReCodEx
@ -1485,8 +1485,6 @@ thanks to the simple authentication flow. Replacing these services in a Nette
application is also straightforward, thanks to its dependency injection
container implementation.
@todo: rest api is used for report of backend state and errors, describe why and other possibilities (separate component)
@todo: mail reports - to users, admins
@todo: what files are stored in api, why there are duplicates among api and fileserver
@ -1497,9 +1495,16 @@ within instance and how it is implemented and how it could be implemented
@todo permission handling, roles, etc.
@todo: on demand loading of students submission, in-time loading of every other submission, why
#### Backend management
Considering the fact that we have backend as a separate component which has no clue about administrators and uses only logging as some kind of failure reporting. It can be handy to provide this functionality to backend from frontend which manages users. The simplest solution would be again to have separate component with some sort of public interface. It can be for example REST or some other communication which backend can handle. Functionality of this kind of component is then quite easy. When request for report arrives from backend then type is inferred and if it is error which deserves attention of administrator then email is sent to him/her. There can also be errors which are not that important, was somehow solved by backend itself or are only informative, these do not have to be reported by email but only stored in persistent database for further consideration. On top of that separate component can be internal and not exposed to outside network. Disadvantage is that database layer which is used in some particular API instance cannot be used here because multiple instances of API can use one backend.
@todo: rest api is used for report of backend state and errors, describe why
@todo: where is stored which workers can be used by supervisors and which runtimes are available, describe possibilities and why is not implemented automatic solution
@todo: on demand loading of students submission, in-time loading of every other submission, why
Martin Polanka
8 years ago