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

> Envoyez une notification à un utilisateur depuis votre application et utilisez l’API à jeton pour la liste des utilisateurs, l’envoi d’image et le socket de synchronisation de plusieurs instances.

Framework: openplatform
Product: OpenPlatform (openplatform@5)
Language: fr
Content-SHA256: 7bc9939e18b304c721e01350a1ad3391ad1f932559a20e659793812f57988e1e
Snapshot: c0700e321579725c5cf4f5ace1ad7d2866d1b4f93c24a63c0b41b6b7998e976c
Sources: 
Review: not-recorded

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](/en/openplatform/register-an-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](/en/openplatform/settings-and-database/) 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.