The backend server of MlmAccess
 
 
 
Go to file
Dorian Zedler 9a7f6b4cc8
Chore: commit unstaged changed
2023-09-10 12:17:31 +02:00
backend - Delete obsolete users 2021-08-23 13:59:38 +02:00
mock-clients - Delete obsolete users 2021-08-23 13:59:38 +02:00
.gitignore - Some better logging 2021-08-19 10:29:23 +02:00
README.md - Delete obsolete users 2021-08-23 13:59:38 +02:00
docker-compose.yml Chore: commit unstaged changed 2023-09-10 12:17:31 +02:00
runBackend.sh - Delete obsolete users 2021-08-23 13:59:38 +02:00

README.md

server

The backend server of MlmAccess

Workflows

Pairing

Actor

A new actor can pair like this:

  1. Connect to the broker using pair as username and the pair secret as password
  2. Subscribe to mlmAccess/pair/response/actor
  3. Publish its desired ID to mlmAccess/pair/request/actor
  4. The backend will publish the password for the actor to mlmAccess/pair/response/actor in case of success
  5. In case of an error, the backend will publish an empty string to mlmAccess/pair/response/actor
  6. The actor may now connect using actor-{id} as username and the password it got in 4
Panel

A new panel can pair in the same way as a new actor. Every occurence of actor as to be replaced by panel, though.

Actor

The actor should subscribe to:

  • mlmAccess/actor/{id}/action The actor can publish to:
  • mlmAccess/actor/{id}/status

Action execution

If the backend requests an action to be executed, the actor follows this workflow:

  1. The backend will publish a requested action to mlmAccess/actor/{id}/action
  2. The actor will publish its state to mlmAccess/actor/{id}/status to let the backend know that the action was executed successfully. This will also happen when the state of the actor is unchanged.

Status change

If the status of the actor changes it follows this workflow:

  1. The actor publishes its status to mlmAccess/actor/{id}/status

Panel

Authentication workflow

The authentication workflow looks like this:

  1. The user presents their RFID Chip to the reader
  2. The panel publishes the id to mlmAccess/panel/{id}/authentication/request
  3. The backend pulishes a JSON object to mlmAccess/panel/{id}/authentication/response which looks like this: {"status": 200, "data": {"fullName": "Max Mustermann", ...}} the status is an int which can be either 200(success) or 404(id not found)
  4. If the status is 200, the panel continues with the normal operation workflow
  5. If the status is 404, the panel continues with the initial user registration workflow

Initial user registration

The initial user registration could work like this:

  1. The user inputs its member ID
  2. The user inputs its birthdate
  3. The panel publishes a JSON object to mlmAccess/panel/{id}/registration/request which looks like this: {"memberId": "1234", "rfidId": "abcde"}
  4. The backend pulishes a JSON object to mlmAccess/panel/{id}/registration/response which looks like this: {"status": 200, "data": {"fullName": "Max Mustermann", ...}} the status is an int which can be either 200(success), 404(memberId not found) or 401(authentication failed / rfidId not found)
  5. If the status is 200, the panel continues with the normal operation workflow
  6. Otherwise, the panel shows an error and goes back to idle.

Normal operation

The normal operation after authentication looks like this:

  1. The user enters the id of the actor they want to unlock
  2. The panel publishes a JSON object to mlmAccess/panel/{id}/actor/request which looks like this: {"rfidId": "abcde", "actorId": "101"}
  3. The backend pulishes a JSON object to mlmAccess/panel/{id}/registration/response which looks like this: {"status": 200} the status is an int which can be either 200(success), 404(actor id not found) or 401(authentication failed / rfidID not found), 403(forbidden)
  4. The panel gives Feedback to the user and goes back to idle