Journal Our Shopping List : sortie de la v2 !

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
18
25
avr.
2022

Nal,

L'année dernière je me suis lancé sur un projet un peu fou : développer une PWA en Node avec frontend en Vue, moi qui ne fais normalement que du PHP backend et qui crache volontier (mais gentiment) sur le Javascript.

Pour ceux qui l'avaient raté, j'avais fait un journal de la v1 : Our Shopping List : liste de courses partagée et libre

Faut croire que je me suis pris au jeu puisque je continue depuis à travailler lentement mais régulièrement sur cette appli et que je me suis même lancé il y a quelques semaines sur un refactoring en profondeur afin de permettre - enfin - de partager une même instance de serveur avec plusieurs groupes de personnes ne se connaissent pas nécessairement, et cela surtout, sans se gêner.

À la notion de liste s'est donc ajoutée celle de tableau. Une liste appartenant désormais à un tableau, et un tableau ayant une ou plusieurs listes. La clé du partage est l'identifiant du tableau, que j'ai souhaité le plus simple possible : c'est donc le slug de celui-ci (dérivé de son nom) qui est utilisable.

Exemple : pour un tableau nommé "Louise et Michel", le slug sera louise-et-michel, et son URL https://osl.example/#/board/louise-et-michel

Un bouton "Partager" est présent dans le menu principal sur mobile pour simplifier l'envoi de l'URL par toute application enregistrée pour cet usage (SMS, email, messagerie, chat, etc.).

Exemple d'usage

Petite démo issue du README (merci Peek) :

Ce qui change et ce qui ne change pas

En vrac et pour faire court, les différences avec la v1 :

  • L'ajout des tableaux donc, mais débrayables via une variable d'environnement, de manière à pouvoir retrouver le fonctionnement de la v1 (= toutes les listes sont accessibles directement, la notion de tableau est masquée)
  • Le support de la traduction (i18n), avec l'inclusion de la traduction FR de base
  • Une correction du tri des items pour ignorer les diacritiques
  • le mode "voir tous les articles" a été remplacé par "voir les articles cochés par date de cochage décroissant" afin de faciliter l'annulation d'un cochage involontaire
  • Une architecture mieux découpée et plus maintenable
  • Une empreinte réseau plus faible

Et tout ça, en essayant de ne pas sacrifier les perfs que j'essaye de conserver les meilleures possibles sur un appareil "ancien" (type Galaxy J5/S5), ce qui n'est pas chose aisée.

Côté comportement et interactions, on reste sur ce qui existe et qui a été éprouvé :

  • swiper vers la droite pour cocher, vers la gauche pour décocher
  • la recherche filtre la liste en temps-réel
  • quand la recherche est active, un simple clic/touch sur un article le coche ou le décoche
  • un appui prolongé sur un article ouvre le formulaire d'édition (mobile)

Je reste à l'écoute de tous les retours et suggestions, voire PR pour les plus intéressés/volontaires.


⚠ Avertissement nécessaire

Si vous avez bien lu et compris le fonctionnement, vous aurez vite déduit que rien ne garantit la confidentialité des données sur un serveur OSL partagé, et vous aurez raison. Si vous connaissez le nom ou le slug d'un tableau, vous pouvez l'ouvrir et modifier ou supprimer les informations sans y avoir été autorisé.

C'est néanmoins un fonctionnement qu'on retrouve déjà sur 2 célèbres webapps collaboratives : Etherpad et Ethercalc.

Une évolution future permetta peut-être de pouvoir - par configuration - sacrifier à la simplicité des slugs user-friendly, un fonctionnement plutôt basé sur des identifiants aléatoires et difficilement devinables (sécurité par l'obscurité mais bon).


Liens

  • # Obscurité

    Posté par  . Évalué à 9. Dernière modification le 26 avril 2022 à 23:11.

    Une évolution future permetta peut-être de pouvoir - par configuration - sacrifier à la simplicité des slugs user-friendly, un fonctionnement plutôt basé sur des identifiants aléatoires et difficilement devinables (sécurité par l'obscurité mais bon).

    Comme le son les mot de passe, les passphrases, les codes pin, les clefs privées, la paire de nombre premiers des algo comme rsa,… En fait non, on parle de sécurité par l'obscurité quand on cache l'implémentation, l'algorithme ou le fonctionnement pour en cacher la fragilité. Donc non des identifiants aléatoires ne sont pas de la sécurité par l'obscurité et c'est même pas mal utilisé (bon il faut un aléa un peu sérieux ne pas utiliser une seed fixe, etc).

    En tout cas c'est cool que ton projet perdure.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Obscurité

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Tu as raison, erreur de ma part. J'ai confondu le principe.

      Dans mon cas il faudrait a minima se protéger contre les attaques brute-force les plus évidentes seulement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.