Closed julien2512 closed 8 years ago
C'est d'autant plus important que la signature pourra très bien ne pas être vérifiée par le client. Nous devons simplement garantir l'intégrité des informations transmises (uniquement pour alert.emergency).
Pour ces évènements, la signature ne sera valide que pour une poignée de certificats publics.
Si #15 et #14 sont implémentés, on pourra démarrer en déportant la vérification de signature coté client.
Le principe de signature ne vaut que si ce sont les extrémités qui font les vérifications. L'API publique OEDB doit à mon sens rester neutre et ne pas porter de responsabilité à ce niveau.
Je le garderait tout de même en réserve pour un second temps : si les évènements de type emergency sont réservés à des personnes identifiées, la vérification de signature peut être une solution au flooding.
Il s'agit, au moins pour les événements dont le type est le plus élevé (alert.emergency par exemple), de vérifier que la signature est bonne avant son insertion en base.
Cela permettrait d'éviter qu'une application smartphone ne filtre coté client un trop grand nombre d'événements factices (le https devant lui aussi être ajouté pour garantir l'authenticité du serveur !).