Gestion des accès App Mobile et de leurs logs

MCD

classDiagram
    class Match {
    }

    class BilletScan {
    }

    class AccesMatch {
        +int id
        +string mobile_password
        +string operateur_password
    }

    class ExternalDevice {
        +int id
        +int category
        +string nom
        +string device_id
    }

    class ExternalDeviceLog {
        +int id
        +int billet_scans_count
        +datetime last_pre_synced_at
        +datetime last_synced_at
        +int local_scans_count
        +text local_scans_csv
        +int scans_count
    }

    Match "0..1" <--> "1" AccesMatch : match
    Match "0..*" <--> "1" ExternalDeviceLog : external_device_logs
    ExternalDevice "0..*" <--> "1" ExternalDeviceLog : external_device_logs
    ExternalDeviceLog "0..*" <--> "1" BilletScan : external_device_log

AccessMatch

Sur billetterie, on a aussi une application de scan, l'application de scan est authentifiée via la table AccesMatch.

Dans AccesMatch, on retrouve deux mots de passe:

• mobile : Ce mot de passe est utilisé lors de la mise en route de l'appareil de scan. En général, l'opérateur va configurer pour quel point de contrôle l'appareil devra être utilisé. C'est également à ce moment là ou l'appareil va faire sa première synchronisation. Mais surtout synchroniser les clefs de Crypto pour le match et les billets disponibles pour chaque point de contrôle.

• operateur : Ce mot de passe est utilisé en cas de soucis critique pour lancer un mode sans echec. Ça permet de débloquer la situation si la synchronisation rencontre un soucis majeur. Ce mot de passe est synchronisé et stocké sur l'appareil lors de la phase de 'Configuration'.

ExternalDevice

L'appareil ou l'application de scan est représenté par la table ExternalDevice.

Elle contient le champ category (type étant réservé en Rails pour le polymorphisme):

• scan : Représente l'Application de Scan
• guichet : Représente le guichet > Le guichet était prévu d'être une application Flutter Desktop mais aujourd'hui, on a une interface dédiée coté Dashboard. > Donc cette catégorie n'est pas utilisée.

Le champ nom est défini durant la phase de 'Configuration' par l'opérateur. Ça permet de mieux les repérer sur le terrain et également dans les informations coté Dashboard.

Le champ device_id est un identifiant unique d'appareil ou de l'application de scan donné par l'OS (Android / IOS). Ça permet d'avoir une identité unique d'appareil de scan entre tout les matchs.

ExternalDeviceLog

Lors de la connexion de l'application de Scan pour un Match, l'API stocke l'état dans ce modèle pour avoir une trace et faire de l'audit.

On stocke les données suivantes:

• billet_scans_count : Le nombre de BilletScan généré par l'Application de Scan connu par l'API
• local_scans_count : Le nombre de BilletScan dans la base de donnée de l'Application de Scan.
• local_scans_csv : L'application exporte les données restantes dans la base de donnée. Normalement, on est censé n'avoir aucune donnée dedans si on a des données, ça veut dire que la synchronisation se passe mal.
• scans_count : Le nombre de scan reçu par l'Application de Scan, c'est un compteur brute qui fait un +1 dès que l'Appareil Photo détecte un QrCode. Ça permet de s'assurer que l'on a pas trop de différence entre ce champ et local_scans_count sinon ça veut dire que l'on beaucoup d'erreur de Scan coté Mobile.
• last_pre_synced_at : L'application de scan fait un Post sur une route de presync pour dire qu'elle commence la synchronisation.
• last_synced_at : L'application de scan fait un Post sur la route de post-sync pour dire qu'elle a fini de synchroniser. C'est à ce moment-là qu'elle envoie le csv avec les données manquantes.

Note Lors de l'appel de la route pre-sync ou post-sync, l'application de scan renvoie local_scans_csv et scans_count. On peut avec ces dates, détecter les crashs de synchronisation si last_pre_synced_at est définie et si last_synced_at == null ou last_synced_at < last_pre_synced_at.