Notifications et points d’accès publics d’OpenPlatform

En plus du lancement et de la vérification, OpenPlatform a quelques points d’accès pour les applications et pour d’autres systèmes. Ils sont dans controllers/verify.js, controllers/api.js et controllers/socket.js.

Envoyer une notification

La réponse de la vérification contient notify, une adresse de la forme <platform url>/notify/?token=<checksum of user and application>, quand l’utilisateur accepte les notifications. L’application lui envoie un POST avec l’en-tête x-token et un corps JSON :

Champ	Signification
body	le texte de la notification
path	le chemin dans l’application que la notification ouvre
icon, color	facultatifs : ils remplacent l’icône et la couleur de l’application

La valeur de x-token est le jeton de notification qu’OpenPlatform dérive pour cet utilisateur et cette application : le MD5 de l’adresse de notification salée avec le reqtoken de l’application, puis le MD5 de ce résultat salé avec son restoken (FUNC.makenotify dans definitions/func.js). Les deux secrets sont les mêmes que ceux que l’application partage pour le lancement (enregistrer une app).

OpenPlatform répond Invalid token quand la somme de contrôle ou l’en-tête ne correspondent pas, et Not allowed notifications quand l’utilisateur ou l’application ne les accepte pas. Il vérifie aussi les adresses autorisées de l’application et que l’utilisateur est confirmé, activé et actif. Quand tout est bon, il :

1. stocke la notification (table tbl_notification) et augmente le compteur de non lues de l’utilisateur ;
2. met à jour les sessions de cet utilisateur ouvertes dans le portail, de sorte que le compteur apparaisse aussitôt ;
3. publie Notifications.create par TMS quand le réglage $tms est activé ;
4. renvoie l’identifiant de la notification.

Pour les utilisateurs hors ligne qui ont des notifications non lues, une tâche de service envoie un résumé par e-mail ("Unread notifications") quand les réglages de messagerie sont configurés, au plus une fois tous les trois jours par utilisateur (definitions/init.js).

L’API des utilisateurs (un jeton)

GET /users/ renvoie les groupes et les utilisateurs de la plateforme en JSON. Elle est désactivée tant que les réglages allow_token et token ne sont pas définis. L’appelant envoie le jeton comme paramètre de requête token ou comme en-tête x-token ; les essais erronés répétés sont bloqués. Les utilisateurs arrivent sans secrets : identifiant, référence, langue, genre, photo (une adresse absolue), nom, e-mail, couleur, préférences, indicateurs (sa, isdisabled, isinactive, isonline), dates et ids de leurs groupes.

Envoyer une image

POST /upload/base64/ (jusqu’à 2 Mo) accepte un corps JSON avec le nom du fichier et file sous forme de data URI, et seulement du JPEG. Il faut un utilisateur connecté ou le jeton de requête du réglage servicetoken (voir réglages et base de données pour savoir d’où vient cette clé). L’image est stockée dans le stockage de fichiers files et la réponse est son adresse, /files/<id and checksum>.jpg ; l’adresse ne fonctionne qu’avec la somme de contrôle.

Plusieurs instances : le socket de synchronisation

SOCKET /sync/ connecte des instances d’OpenPlatform. Un client est accepté quand le réglage sync est activé et que le token de la requête est égal à sync_token ; tout autre client est fermé avec le code 4001 une demi-seconde après l’ouverture. Les messages d’un client confirmé sont relayés aux autres, et pendant qu’un client confirmé se reconnecte, les messages sont mis en file d’attente pendant dix secondes au plus.