experimental_taintObjectReference

experimental_taintObjectReference(message, object);

• Référence
  • taintObjectReference(message, object)
• Utilisation
  • Empêcher des données utilisateur d’atteindre le client par inadvertance

Référence

taintObjectReference(message, object)

Appelez taintObjectReference avec un objet pour indiquer à React qu’il ne doit pas permettre le passage de cet objet tel quel vers le côté client :

import { experimental_taintObjectReference } from 'react';

experimental_taintObjectReference(
  'Ne passez pas TOUTES les variables d’environnement au client.',
  process.env
);

Voir plus d’exemples ci-dessous.

Paramètres

• message : le message que vous souhaitez afficher si l’objet est passé à un Composant Client. Ce message fera partie de l’erreur qui sera levée si l’objet est passé à un Composant Client.

• object : l’objet a « ternir ». Les fonctions et instances de classes peuvent être passées en tant qu’object à taintObjectReference. React empêche d’entrée de jeu leur passage aux Composants Clients, mais ça remplacera le message d’erreur par défaut avec ce que vous aurez passé comme message. Notez que lorsqu’une instance précise d’un tableau typé (Typed Array, NdT) est passée comme object à taintObjectReference, les copies de ce tableau typé ne seront quant à elles pas ternies.

Valeur renvoyée

experimental_taintObjectReference renvoie undefined.

Limitations

• Recréer ou cloner un objet terni produit un nouvel objet intact, susceptible de contenir des données sensibles. Si par exemple vous avez un objet user terni, const userInfo = {name: user.name, ssn: user.ssn} ou {...user} produiront de nouveaux objets qui ne seront, eux, pas ternis. taintObjectReference ne protège que contre les bévues simples lorsque l’objet est passé tel quel à un Composant Client.

Utilisation

Empêcher des données utilisateur d’atteindre le client par inadvertance

Un Composant Client ne devrait jamais accepter des objets comportant des données sensibles. Dans l’idéal, les fonctions de chargement de données ne devraient pas exposer des données auxquelles l’utilisateur actif n’a pas accès. Mais des erreurs peuvent survenir lors d’une refonte du code. Pour se protéger contre des erreurs en aval nous pouvons « ternir » l’objet utilisateur dans notre API de données.

import { experimental_taintObjectReference } from 'react';

export async function getUser(id) {
  const user = await db`SELECT * FROM users WHERE id = ${id}`;
  experimental_taintObjectReference(
    'Ne passez pas l’objet utilisateur entier au client. ' +
      'Récupérez plutôt les propriétés spécifiques à votre scénario.',
    user,
  );
  return user;
}

Désormais, si un code serveur quelconque essaie de passer cet objet à un Composant Client, une erreur sera levée avec le message d’erreur fourni.

// api.js
export async function getUser(id) {
  const user = await db`SELECT * FROM users WHERE id = ${id}`;
  return user;
}

import { getUser } from 'api.js';
import { InfoCard } from 'components.js';

export async function Profile(props) {
  const user = await getUser(props.userId);
  // NE FAITES PAS ÇA
  return <InfoCard user={user} />;
}

// components.js
"use client";

export async function InfoCard({ user }) {
  return <div>{user.name}</div>;
}

// api.js
import { experimental_taintObjectReference } from 'react';

export async function getUser(id) {
  const user = await db`SELECT * FROM users WHERE id = ${id}`;
  experimental_taintObjectReference(
    'Ne passez pas l’objet utilisateur entier au client. ' +
      'Récupérez plutôt les propriétés spécifiques à votre scénario.',
    user,
  );
  return user;
}