Reprise du message précédent :

 
Là dessus entièrement d'accord.

Encore une fois, dans un cookie, tu ne stockes pas l'identifiant ou même le mot de passé hashé, tu stockes un ID généré, inscrit dans une DB de ton coté avec l'heure, le navigateur, l'IP, et d'autres choses qui peuvent identifier un ordinateur.
Même si le cookie est intercepté ou volé, si t'as bien fait les choses, le pirate ne peut pas en faire grand chose quand il voudra s'en reservir sur une autre machine.

 
Oui je sais parfaitement tout cela et comme je te l’ai dit tout à l’heure, je fais régulièrement des trainings sur tous ces aspects, surtout avec les nouvelles règles GDPR ou la sécurité des donnés devient de plus une obsession. Mais malheureusement il existe des gens très forts et différents niveaux de hack.  

Le niveau de sécurité à mettre en place dépend du contenu à protéger non ?  
Me relogguer à chaque fois sur mes sites bancaires me parait naturel, par contre si tu me demande de me logguer à chaque fois que je vais sur HFR ça va vite me saouler.

J'ai envi de dire que la question ne se pose pas. Si données réellement sensibles, pas de "remember me" car tu ne pourras jamais contrôler qui est derrière l'ordinateur de l'utilisateur même si cela incombe ce dernier. Si données peu sensibles, il faut juste s'assurer qu'un pirate ne puisse récupérer/modifier le mdp, mail et autres choses dans le genre. Donc il faut masquer le mail et redemander le mdp pour les changements importants. Bref les choses classiques.
 
Donc pour les données peu sensibles tu laisses le choix à l'utilisateur de juger par lui-même les risques qu'il souhaite prendre. Moi je suis totalement contre la déresponsabilisation des gens, et ce dans bien d'autres domaines. À ce jour où le savoir n'a jamais été aussi facile d'accès, il faut arrêter de dire aux gens qu'ils peuvent se passer du moindre effort de compréhension. Mais bon là on rejoint un autre débat.

 
Source ?

j'ai un peu de mal à comprendre, oui le sessionID est précieux, et surtout depuis qu'on le colle plus à l'adresse IP du client, mais j'ai l'impression qu'avec HTTPS et HttpOnly on en entend moins parler.
 
Et sinon on fait quoi ? session dans l'URL?

Bonjour,
 
Vous avez une idée de la difficulté a réaliser un site web de ce style pour un noob motivé?  http://www.phoenixjp.net/news/fr/index_others.php (agrégateur RSS perso)
Si vous avez un tuto, une base pour démarrer je suis preneur

Salut,

Je mets en place le nouveau Checkout.js de Paypal

Le script a grosso-modo cette gueule :

Ya que moi qui trouve ça dangereux ?
Genre je suis sur le site, je modifie le code de la fonction "onAuthorize" (via les outils développeurs), pour que peu importe le résultat du paiement, je vais enclencher l'action de valider le paiement, et par ainsi valider une commande sans payer

https://developer.paypal.com/docs/i [...] he-payment

C'est un workflow 100% UI. Tu dois vérifier côté serveur que le transaction id existe.

Pour ceusse qui n'ont pas suivi (je te regarde muchacho) et qui ont du node sur leur projet, y'a une nouvelle commande `npm ci` qui installe directement depuis le package.json. Je passe de 80 secondes à 10 sur mes serveurs, c'est quand même plutôt pas mal.
In other news, j'envisage de dégager React, j'ai 452 lignes de js (commentaires inclus) sur mon projet b2b et je me retrouve avec un bundle de 1.1Mb en version prod.
Sachant que je suis mono target je vais essayer de jouer avec les options de bundling, mais j'ai l'impression que ce truc est voué à être bloaté, je cherche un truc un peu plus lightweight. Une idée?

T'as regardé du côté de Vue ?

Nan mais pour 400 lignes de JS, n’importe quel framework sera bloated ...

 This

Angular de moins en moins, et vue donné de bons résultats.

jQuery

Babel + vanilla ES6 = rulez
 
Ca fait pas de mal de temps en temps, retour aux origines quoi

T'as toujours l'option lib, il va te manquer les abstractions de plus haut niveau (composants) mais snabbdom c'est 500 lignes de JS et t'as un vdom plus ou moins complet.

Sinon t'as preact, ça fait 3k et t'as probablement 90~95% de React (juste pas l'écosystème autour).

Ca y est, les mecs sont déjà passés au framework suivant  

Je l'ai jamais fait, et j'aurais du. Dès que j'ai moins de charge je vais m'y pencher.

Tu trouves pas ça triste? React c'est pas trop batteries included, je fais que des petits widgets qui sont alimentés par des composants html ou par des données json embedded dans la page. De fait la logique est straight forward et j'ai du mal à capter comment je me retrouve avec 1.1Mb de code minimifié.  
 

Ça c'est un problème.

J'utilise React comme il a été designé à la base, mais la partie DOM est lourde et l'écosystème est complètement moisi.
 

Autre piste moins en visibilité que Vue : Glimmer qui couvre sensiblement le même périmètre. C'est le moteur de rendu d'Ember, l'avantage pourrait être de commencer un petit projet sous Glimmer et de basculer au besoin vers l'artillerie lourde sans réécrire.
C'est ce que j'investigue pour nos petits projets, à l'heure actuelle on est full Ember.

S'toi qui choise (après c'est la même API donc il y a ptet des trucs qui marchent, idk, j'ai jamais regardé de trop près il est juste fréquemment mentionné) (semblerait qu'il y ait des packages pour les trucs genre mobx ou redux)

nan je trouve pas ça triste.  
je vais me requote, mais un bundle de 1.1Mb minifié, c'est souvent qu'il y a une couille dans ton setup:

Donc en gros tu chie sur l'écosystème, mais une alternative pas 100% compatible est un problème?

à la base, React c'est fait pour les besoins de FB, pas pour une app de 400 lignes... seulement la hype qui vend React à toutes les sauces est en train de retomber, ce qui va etre assez rigolo à suivre

Mithril ou sinon vanilla JS pour un projet aussi petit

Je suis curieux
est ce que tu peux faire passer ton package.json en mp ?
Je suis a environ 301Kb en prod  avec ces dependances (gzippé)

 
Voilà #jsfatigue  
 
Ca fait plus de 5 ans que je fais du Ember en attendant

Je dois justement interviewer un type qui fait presque que ça  

En 5ans, j'ai fait côté client :
du backbone + mustache
angular1
une maquette angular2 quand c'était en alpha (berk)
du react (plein)
du swift 3

côté serveur
du symfony 2
du silex/twig
du node
du postgresqsl /mysql /sql serveur
du mongo

et avant ça du jquery, jquery-mobile, symfony1 , php 3-4-5 sans framework, ...

et bien react + node + {postgresql || mongo } ca marche vraiment bien, c'est la meilleure stack que j'ai pu tester , c'est stable, avec peu d'effet de bord, et des perfs au top

Et je n'ai pas l'impression que la hype react retombe, plutôt qu'elle s'installe dans le grand public. Avec en plus la montée en puissance de react native, la clarification de la licence, et react 16 qui apporte des nouveautés très sympa,  je suis confiant.

Et que t'utilises pas des POJO et obliger de .get() et .set() n'importe quel attribut. Ca fait long 5 ans

Faut peser le pour et le contre, i.e: sur mon précédent projet j'ai trouvé un truc qui fait de l'upload avec un drag'n'drop et tout et j'étais bien content de pas avoir à développer ça.

C'est pas impossible, j'ai un message d'erreur en préprod qui me dit qu'apparement la deadcode elimination n'est pas fait. A part rajouter le plugin define et uglifyjs (d'ailleurs que je le rajoute ou pas en production mode ça change rien) je vois pas trop ce que je dois faire de plus. Si t'as une idée je veux bien l'entendre. C'est pas crtique puis qu'une fois gzippé ça reste contenu, mais si on peut faire mieux pourquoi pas.

Je vois pas où j'ai dit ça. Relis avec le doigt. K'ai dit que ne pas pouvoir profiter de l'écosystème en utilisant une alternative était un problème. Y'a pas mal de lib qui proposent pas d'interface pour preact, donc il faut repartir de zéro.

Sur le principe c'est pourtant intéressant, une interface commune et des implémentations différentes ce qui devait rendre les applications portables. Mais l'idée a été tournée et détournée dans tous les sens, du coup j'essaie de revenir aux bases et d'en faire une utilisation orientée widget (c'est ce pour quoi la techno a été pensée au départ). Je suis pas trop la hype mais je veux un truc qui soit un minimum connu et maintenu, raison pour laquelle mon backend est en django.

J'ai deux bundles, y'en a un qui inline des images et des svg et l'autre c'est vraiment straight forward, mais comme j'ai dis en haut, y'a certainement un truc qui va pas.

'Tain mais toutes les dependencies que vous avez
J'espère qu'après vous compilez les assets en un fichier.

 
C'est sur que c'est le plus important  

C'est le principe ouais
D'ailleurs webpack gère les dépendances de manière lazy. Tu peux occulter tout ce qui contient webpack, loader ou babel déjà.

https://bundlephobia.com/? Special pour shinuza

Je regarde ton cas en détail ce soir, ça m'intéresse mais je suis en balade

bundle-size react-portal react-router-dom react -e production : 209Ko
 
+ react-widgets  :  529Ko
+ react-widgets-moment : 613Ko
+ moment-timezone : 801Ko
+redux : 843Ko
+ redux-form : 1.08 Mo (268Ko gzippé)
 
Est ce que tu es sur d'avoir besoin de react-widget, ou est ce que des composants react normaux suffisent ?  
 
redux + redux form sont ils nécessaire pour une appli de quelques centaines de lignes ?  
 
moment est un goinfre avec la gestion des timezone

J'ai bien envie de tester Luxon la prochaine fois que je joue beaucoup avec des dates d'ailleurs: https://github.com/moment/luxon

Ça a l'air sympa et fixe pas mal des problèmes que j'ai avec Moment.
 
Par contre les durées sont uniquement relatives, donc tu peux pas exprimer "le dernier jour du mois prochain" en un seul objet, t'es obligé d'utiliser une séquence d'opérations.

Je rappelle que ce sont des chiffres non gzipped, mais minifié

Perso j'utilise un Addon de visual studio code qui me donne la taille des imports