You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Actuellement, nous passons par un upload en utilisant une librairie qui s'appelle formidable.
Via cette librairie, nous récupérons un stream, qui est parsé pour vérifier qu'il ne contient pas de code malveillant.
Ensuite, celui-ci est uploadé sur notre S3 hébergé chez Azure. Nous ne sauvegardons pas en base de données le nom du fichier sauvegardé. En effet, tous les mécanismes qui nous permettent de récupérer un fichier est basé sur l'API d'azure à travers @azure/storage-blob.
Au niveau de l'API, lors de l'envoi du FormData (multipart/form-data), nous passons dans le header un token, qui doit être impérativement généré avant l'envoi. Dans le cas contraire, la requête ne sera pas validé.
Limites
Il serait préférable de stocker le fichier côté serveur au lieu de se baser uniquement sur l'API d'azure pour avoir plus de constitance au niveau de la reference des fichiers
Au niveau de l'authentification, dans le cas d'un upload qui contient un token qui a été généré à l'initialisation de la page. Il se peut que celui-ci soit périmé avant l'envoi. Il faut ainsi forcer la regénération de celui-ci. Le mécanisme n'est pas présent.
Actuellement, le stockage de fichier est le seul endroit au sein de l'application où nous ne passons pas par du graphql. Pourquoi penser à une normalisation du processus ?
Solutions envisagées
Action Hasura
La première étape consiste à générer une action côtée Hasura. Cette action a pour but de recevoir le nom d'un fichier, avec sa base64. En sachant que nous ne pouvons passer que des String en paramètre, cela nous limite.
Une fois l'action mise en place, on la redirige vers un endpoint en local (via une API nextjs). Là, nous effecturons l'upload de la base64.
D'un point de vue sécuritaire (ex: un fichier SVG qui contient du code js executable), il faudrait décoder cette base64, pour analyser le contenu, avant d'effectuer l'upload.
Enfin, il faudra upload ce fichier à azure via la librairie directement vers cet endpoint.
Plugin
Il existe un plugin : hasura-storage qui fait tout le travail d'upload et de verification via clamav des fichiers
Cela nécessiterait de rajouter un pod a l'architecture qui s'occupe de la passerelle entre hasura et notre service d'upload.
De plus, il se peut qu'on risque un peu de perdre de main mise en passant par ce processus conventionné.
Conséquences
Peu importe l'implémentation, il faudra mettre en place un linkage au niveau de la base de données entre les fichiers qu'on upload sur azure.
Cela signifie :
Faire une migration pour que les upload actuels soit présent dans notre BDD
Modifier la page upload actuelle
Next steps
On pourrait imaginer dans un premier temps mettre en place un upload-v2, qui s'occupe de charger les fichiers en base64 via la méthode d'action. Elle a pour but d'être utilisé sur les nouveaux features (eg. modèle de courrier), en attendant de migrer le reste.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
L'état de l'art
Actuellement, nous passons par un upload en utilisant une librairie qui s'appelle formidable.
Via cette librairie, nous récupérons un stream, qui est parsé pour vérifier qu'il ne contient pas de code malveillant.
Ensuite, celui-ci est uploadé sur notre S3 hébergé chez Azure. Nous ne sauvegardons pas en base de données le nom du fichier sauvegardé. En effet, tous les mécanismes qui nous permettent de récupérer un fichier est basé sur l'API d'azure à travers
@azure/storage-blob.Au niveau de l'API, lors de l'envoi du
FormData(multipart/form-data), nous passons dans le header un token, qui doit être impérativement généré avant l'envoi. Dans le cas contraire, la requête ne sera pas validé.Limites
Solutions envisagées
Action Hasura
La première étape consiste à générer une action côtée Hasura. Cette action a pour but de recevoir le nom d'un fichier, avec sa base64. En sachant que nous ne pouvons passer que des
Stringen paramètre, cela nous limite.Une fois l'action mise en place, on la redirige vers un endpoint en local (via une API nextjs). Là, nous effecturons l'upload de la base64.
D'un point de vue sécuritaire (ex: un fichier SVG qui contient du code js executable), il faudrait décoder cette base64, pour analyser le contenu, avant d'effectuer l'upload.
Enfin, il faudra upload ce fichier à azure via la librairie directement vers cet endpoint.
Plugin
Il existe un plugin : hasura-storage qui fait tout le travail d'upload et de verification via
clamavdes fichiersCela nécessiterait de rajouter un pod a l'architecture qui s'occupe de la passerelle entre hasura et notre service d'upload.
De plus, il se peut qu'on risque un peu de perdre de main mise en passant par ce processus conventionné.
Conséquences
Peu importe l'implémentation, il faudra mettre en place un linkage au niveau de la base de données entre les fichiers qu'on upload sur azure.
Cela signifie :
Next steps
On pourrait imaginer dans un premier temps mettre en place un
upload-v2, qui s'occupe de charger les fichiers en base64 via la méthode d'action. Elle a pour but d'être utilisé sur les nouveaux features (eg. modèle de courrier), en attendant de migrer le reste.Liens
Beta Was this translation helpful? Give feedback.
All reactions