Qu'est-ce que Web NFC sait écrire, et que ne sait-il pas ?
Tout message NDEF, un tag vierge étant formaté au passage, et depuis Chrome 100 un verrouillage définitif. Ce qu'il ignore est tout ce qui dépasse le message : mot de passe, page de configuration, commande brute, émulation de carte. Et un échec d'écriture ne dit pas jusqu'où il est allé.
Ce que fait write()
write() prépare un message et attend un tag. Dans l'article de Chrome sur Web NFC, sa promesse est tenue une fois que l'utilisateur a présenté un tag et que le message est écrit, aux mêmes conditions qu'un scan : un geste de l'utilisateur, la permission, et le NFC présent et allumé.
Une simple chaîne devient un enregistrement de texte, en UTF-8 et dans la langue du document sauf indication contraire de l'enregistrement. Tout le reste est un message d'enregistrements : une URL, une URL absolue, des données MIME, une affiche intelligente, un type externe comme example.com:foo, ou un enregistrement vide.
Cela couvre ce que porte la plupart des tags. Cela couvre aussi un Android Application Record, que l'article écrit comme le type externe android.com:pkg, avec les limites décrites sur la page de l'enregistrement d'application.
Les tags qui portent déjà un message
Par défaut, l'écriture remplace ce que porte le tag. La spécification met overwrite à vrai sauf indication contraire ; à faux, l'écriture lit d'abord le tag et rejette par NotAllowedError si elle y trouve des enregistrements NDEF.
Un tag vierge est pris en charge pour vous. Quand le tag à portée n'est pas formaté et peut l'être pour NDEF, la spécification le formate, puis écrit. L'article ajoute qu'un tel tag se lit comme un unique enregistrement vide, ce qui permet à une page de le reconnaître avant d'écrire.
La spécification recommande d'appeler write() depuis un événement reading, pour que la page vérifie le contenu existant ou le numéro de série et n'écrive que sur le tag qu'elle visait.
Verrouiller depuis une page
makeReadOnly() est arrivé dans Chrome 100 sur Android, et l'article le décrit comme un processus à sens unique qui ne peut pas être annulé. Testez sa présence par 'makeReadOnly' in NDEFReader.prototype avant de le proposer.
Attachez-le à une action distincte de l'écriture, prise après vérification du contenu sur un second téléphone. La question de savoir s'il faut verrouiller se tranche sur la page du verrouillage.
Ce qu'une page ne peut pas faire
Web NFC s'arrête au NDEF, volontairement. L'article énumère ce qui est hors de son périmètre : les opérations de bas niveau comme ISO-DEP, NFC-A, NFC-B et NFC-F, le pair à pair, et l'émulation de carte par l'hôte.
Cela exclut tout ce qu'une puce fait au delà de stocker un message. Une page ne peut ni poser ni employer un mot de passe, écrire une page de configuration, activer un compteur ou lire une signature, qui passent tous par des commandes brutes.
Une écriture échouée dit également peu de chose. La spécification rejette par NetworkError quand le transfert échoue, sans dire jusqu'où il est allé : relisez donc le tag avant de réessayer. L'exemple de relecture après écriture de l'article, un write() suivi d'un court scan(), fait exactement cela.
Questions fréquentes
Web NFC peut-il poser un mot de passe sur un tag ?
Non. Les mots de passe se posent par des commandes de puce, et Web NFC s'arrête au NDEF : les opérations de bas niveau sont hors de son périmètre.
Que se passe-t-il si le tag porte déjà un message ?
Par défaut il est écrasé. Avec overwrite à faux, l'écriture lit d'abord le tag et rejette si elle y trouve des enregistrements NDEF.
Une page peut-elle passer un tag en lecture seule ?
Depuis Chrome 100 sur Android, avec makeReadOnly. Le verrouillage est définitif : il vient donc après la vérification du contenu.
Pourquoi mon écriture a-t-elle échoué par NetworkError ?
La spécification rejette ainsi quand le transfert échoue, sans dire jusqu'où il est allé. Relisez le tag avant de réessayer.