Design & Développement web - Le topic des canards qui mangent des cookies

[Awake]

https://www.comet.co/ est pas mal aussi.

Et +1 pour les tarifs, il y a un proverbe dans le milieu "Si vous pensez qu'un développeur senior est trop cher, attendez de voir ce que vous coûte un développeur débutant" .

[Teocali]

Dites, rapide question : est-ce qu'il y'a un moyen pour un site de partager une information stockée en local sur le poste du visiteur avec un autre site, soit via les cookies, soit via une autre API javascript ?

[tenshu]

Les cookies sont cloisonnés par domaine (voire sous domaine), un site tiers ne peut donc pas accéder aux cookies d'un autre.
Et comme très souvent on utilise les cookies pour maintenir une authentification, c'est tant mieux.

[Teocali]

Les cookies sont cloisonnés par domaine (voire sous domaine), un site tiers ne peut donc pas accéder aux cookies d'un autre.
Et comme très souvent on utilise les cookies pour maintenir une authentification, c'est tant mieux.

Yep, je savais que si le domaine X créé un cookie, le domaine Y peut pas y accéder par défaut, mais je me demandais si y'avait moyen pour le domaine X de créer une info persistante (cookie, localStorage, ou autre) en précisant que le domaine Y peut aussi y accéder. ça n'a pas l'air d'être le cas.

[tenshu]

Y'a des bricoles qui existent mais à ce niveau, si tu contrôles les 2 domaines tu peux faire un call de l'un à l'autre pour partager les informations.

C'est d'ailleurs comme ça que j'ai fait le SSO le plus ghetto de l'histoire
On nous demande de partager la connexion entre domaines, évidemment les sales et le chef de projet ne savent pas que c'est pas orthodoxe.
Évidemment c'est dans un agence donc à faire pour hier, grouille toi.

Donc j'ai fait une iframe qui appelle le domaine principal, si l'utilisateur est loggué il enregistre un token qui est renvoyé au site ... via le title de l'iframe
Reste plus qu'à valider le token et connecter l'user sur le domaine tiers.
Le pire c'est que ça marchait extrêmement bien haha :')

Evidemment aujourd'hui on a mieux genre JSONP ou JWT pour l'authentification.

- - - Mise à jour - - -

Evidemment je n'ai pas parlé des CORS par ce que c'est encore plus technique et comme ça commence à toucher au devops, je suis moins calé.

[Orhin]

Dites, rapide question : est-ce qu'il y'a un moyen pour un site de partager une information stockée en local sur le poste du visiteur avec un autre site, soit via les cookies, soit via une autre API javascript ?

Ça sent le truc sale à faire cette histoire.
Et comme l'a dit tenshu, sans bidouille non tu ne peux pas le faire.

[Teocali]

Y'a des bricoles qui existent mais à ce niveau, si tu contrôles les 2 domaines tu peux faire un call de l'un à l'autre pour partager les informations.

C'est d'ailleurs comme ça que j'ai fait le SSO le plus ghetto de l'histoire
On nous demande de partager la connexion entre domaines, évidemment les sales et le chef de projet ne savent pas que c'est pas orthodoxe.
Évidemment c'est dans un agence donc à faire pour hier, grouille toi.

Donc j'ai fait une iframe qui appelle le domaine principal, si l'utilisateur est loggué il enregistre un token qui est renvoyé au site ... via le title de l'iframe
Reste plus qu'à valider le token et connecter l'user sur le domaine tiers.
Le pire c'est que ça marchait extrêmement bien haha :')

Evidemment aujourd'hui on a mieux genre JSONP ou JWT pour l'authentification.

Honnetement, je vais partir sur un truc du genre, je pense. Sauf que le token sera transmis en paramètre de requète HTTPS. L'idée, là, c'est que le site X appelle mon backend avec ses identifiants (unique au site), plus l'identifiant d'un utilisateur U (celui qui est connecté chez eux). Mon backend vérifie que le site a des droits d'impersonification sur l'utilisateur U, renvoie un token, le site X ensuite redirige vers le site Y en lui transmettant le token. Le site Y peut donc communiquer avec mon backend en tant qu'utilisateur U, sans avoir a lui demander son authentification. D'ou ma question sur la transmission de données du site X au site Y.
Ouais, c'est clairement pas le plus orthodoxe, mais c'est celui qui nous permttait de developper le plus rapidement possible au vu des conditions. idéalement, le site X aurait du mettre en place un provider SSO, et le site Y et mon backend aurait du communiquer avec ce provider, mais y z'étaient pas trop chaud

Evidemmenta je n'ai pas parlé des CORS par ce que c'est encore plus technique et comme ça commence à toucher au devops, je suis moins calé.

Ah putain, les CORS. ça aussi, ça m'a bien pété les couilles. Faudra que je nettoie la configuration de mon backend, un de ces jours.

[Max_well]

Honnetement, je vais partir sur un truc du genre, je pense. Sauf que le token sera transmis en paramètre de requète HTTPS. L'idée, là, c'est que le site X appelle mon backend avec ses identifiants (unique au site), plus l'identifiant d'un utilisateur U (celui qui est connecté chez eux). Mon backend vérifie que le site a des droits d'impersonification sur l'utilisateur U, renvoie un token, le site X ensuite redirige vers le site Y en lui transmettant le token. Le site Y peut donc communiquer avec mon backend en tant qu'utilisateur U, sans avoir a lui demander son authentification. D'ou ma question sur la transmission de données du site X au site Y.

Alors pour moi tu viens de décrire exactement un SSO en fait, avec ton backend comme serveur.
Après la seule différence c'est si tu fais la gestion de token à la main, mais t'es même pas obligé, tu dois avoir des trucs qui existe (genre CAS en Java).

[Teocali]

Alors pour moi tu viens de décrire exactement un SSO en fait, avec ton backend comme serveur.
Après la seule différence c'est si tu fais la gestion de token à la main, mais t'es même pas obligé, tu dois avoir des trucs qui existe (genre CAS en Java).

Pas vraiment. l'utilisateur ne s'authentifie pas chez nous. En gros, le flow :
L'utilisateur U s'authentifie chez l'application X.
L'application X nous appelle, et transmets a notre backend ses credentials a elle (pas ceux de l'utilisateur U) ainsi que l'id de l'utilisateur U
On verifie que l'application X a les droits suffisants sur l'utilisateur U et si oui, on retoure un token d'authentification TA
L'application X transmets le token a l'application Y (notre front end)
L'application Y effectue des appels a notre backend avec le token TA, appel qui sont traités comme si c'était l'utilisateur U qui s'était authentifié sur notre application.

Les deux applications X et Y sont des applications Web, le backend est une API rest.

L'interrogation se posait sur la meilleure manière de faire basculer l'utilisateur de l'application X à Y en transmettant le token.

[Orhin]

Si l'utilisateur va sur l'application Y via l'application X en utilisant un lien externe, alors l'application X n'a qu'à fournir le token dans l'URL de redirection vers Y.
Charge à Y de récupérer le token dans les query params de son URL et de l'utiliser pour les appels aux back.

[Teocali]

Si l'utilisateur va sur l'application Y via l'application X en utilisant un lien externe, alors l'application X n'a qu'à fournir le token dans l'URL de redirection vers Y.
Charge à Y de récupérer le token dans les query params de son URL et de l'utiliser pour les appels aux back.

C'est ce qu'on va faire. Je me demandais juste s'il y'avait une meilleur manière de faire.

[tenshu]

Pas vraiment. l'utilisateur ne s'authentifie pas chez nous. En gros, le flow :
L'utilisateur U s'authentifie chez l'application X.
L'application X nous appelle, et transmets a notre backend ses credentials a elle (pas ceux de l'utilisateur U) ainsi que l'id de l'utilisateur U
On verifie que l'application X a les droits suffisants sur l'utilisateur U et si oui, on retoure un token d'authentification TA
L'application X transmets le token a l'application Y (notre front end)
L'application Y effectue des appels a notre backend avec le token TA, appel qui sont traités comme si c'était l'utilisateur U qui s'était authentifié sur notre application.

Les deux applications X et Y sont des applications Web, le backend est une API rest.

L'interrogation se posait sur la meilleure manière de faire basculer l'utilisateur de l'application X à Y en transmettant le token.

https://jwt.io/

[Teocali]

https://jwt.io/

J'y ai pensé, mais les mecs qui gèrent l'app X veulent se prendre la tête le moins possible. Donc pas envie de gérer le JWT de leur coté. Dommage.

[tenshu]

Sinon jsonp, mais bon à un moment pour communiquer il faut être 2 sinon c'est un monologue.

C bo se ke je di

[Teocali]

Tiens, dans la catégorie marrante, cet article vient de me donner une idée :

imaginons que l'application X (domaine X.com) récupère mon token, le stocke dans un cookie et redirige l'utilisateur sur l'URL y.x.com. cette url est en fait une redirection DNS vers y.com qui héberge l'application Y. A ce moment, l'application Y pourrait donc récupérer le token initial, vu que le navigateur croirait encore être sur le domaine y.x.com.

Bon, ça necessite un minimum de coordination entre les dev des deux apps, pour éviter que X n'écrase une info de Y, mais vous en pensez quoi ?

[tenshu]

Que tous les trackers se sont mis en tête de faire ça pour contourner le rgpd et que j'ai hâte que ça soit patché par les browser.

[Fastela]

Tiens, dans la catégorie marrante, cet article vient de me donner une idée :

imaginons que l'application X (domaine X.com) récupère mon token, le stocke dans un cookie et redirige l'utilisateur sur l'URL y.x.com. cette url est en fait une redirection DNS vers y.com qui héberge l'application Y. A ce moment, l'application Y pourrait donc récupérer le token initial, vu que le navigateur croirait encore être sur le domaine y.x.com.

Bon, ça necessite un minimum de coordination entre les dev des deux apps, pour éviter que X n'écrase une info de Y, mais vous en pensez quoi ?

C'est la raison pour laquelle beaucoup de gens se battent pour que "samesite=strict" soit activé par défaut dans la gestion des cookies. Ainsi, les cookies ne sont pas envoyés de site en site (même pour les sous-domaines si je me trompe pas).

[LaitLucratif]

Hello,
J'ai un petit soucis de git/sauvegarde en retour de week-end, je vais essayer d'expliquer le truc :

C'est un projet VueJS initié en vue-cli, j'utilise Visual Studio Code, y'a bien git activé sur le dossier du projet, j'ai un repository sur github.
C'est ma première utilisation/prise en main de git donc j'ai pas encore DU TOUT les réflexes, en gros mon dernier commit/push date de mardi dernier.
Après ça j'ai bossé sur le projet jusqu'à vendredi matin en local, simplement en faisant du pomme S. Ca posait aucun problème, je relançais le projet chaque matin avec les bonnes versions. J'ai même fais une version build jeudi soir pour le balancer sur FTP.
Je suis parti en week-end vendredi jusqu'à hier soir, je relance le projet ce matin, et là surprise : le projet est revenu à la dernière version commit de mardi dernier. J'ai rien touché, toujours la même branche (master). Le dossier build correspond par contre bien au dossier que j'ai envoyé jeudi soir...

Il y a moyen de récupérer mes travaux ? J'ai un peu regardé mais je trouve pas. J'ai vraiment pas la force de tout refaire.

Merci !

EDIT : résolu en fouillant côté local stashes, ouf. Petite frayeur du retour de week-end, nickel pour débuter la semaine.

[Orhin]

mon dernier commit/push date de mardi dernier.

Ne jamais laisser du code en local non pushé pendant plus d'une journée.

[LaitLucratif]

La leçon est apprise.
C'est ma première utilisation de git, j'ai pas encore les réflexes.

[Hideo]

J'allais te dire de checker ton stash

Meme si c'est toujours une tres bonne chose de connaitre ses lignes de commande, je te conseille d'utiliser une GUI pour git, ca permet d'avoir une visualisation de ton tree, gerer les conflits plus facilement...
Perso j'utilise GitKraken , simple et relativement propre meme si un peu lourd et qui utilise sa propre instance de git.
Y'a pas mal de shotcut tres pratiques (undo/redo par exemple) qui ne sont pas forcement super evident en ligne de commande.

[Teocali]

Ne jamais laisser du code en local non pushé, non backupé, pendant plus d'une journée.

Fixed... parce qu'a la base git, c'est pas une solution de backup, hein

[Orhin]

Fixed... parce qu'a la base git, c'est pas une solution de backup, hein

Oui bien évidemment, mais là on parle de quelqu'un qui découvre l'outil pour un usage perso (ou en tout cas pas dans une structure avec sa propre infra).
Le reste viendra après.

[William Vaurien]

Il n'y a pas de "local history" dans Visual Studio Code ? Ou un plugin ?
J'adore ce truc, ça permet de récupérer du code quand on a foiré un merge ou tout autre opération hasardeuse avec git.

[Whiskey]

Ola,

J'ai une petite question : Actuellement je fait du web avec une orientation PHP via symfony. J'utilise PHPStorm actuellement, qui marche plutôt bien et a part sa lourdeur (comme tout gros IDE) j'ai pas trop à me plaindre, cela marche plutôt bien.

J'arrive a mon problème (qui en fait n'en est pas vraiment un, mais plus un besoin d'avis), un collègue a moi ne jure que par l'IDE Komodo IDE (toujours pour du web). Prenant un peu de temps, je decide de l'installer dans sa version trial (la version 11) et je fait quelques tests, mon verdicte :

- Interface plutot agréable
- Semble plus léger
- Fonctionnalités plutôt léger, l'auto-complétion assez limiter (vscode avec plugin fait bien mieux)
- Une bonne partie des plugins non compatible avec la v11, ca fait un peu tache pour un IDE payant.
- Pas de terminal dos (du moins pas trouver), si un plugin dédié mais incompatible avec la v11
- Le compilateur via plugin SASS non compatible mais qui fonctionne quand meme, meme si c'est pas le must. Ceci dit, la sortie est juste dégueulasse....
- Ne prend pas en charge la liguature dans les polices adapté (par exemple Fira Code)

Je pourrais faire une liste complète de pour et contre, mais pour le moment je suis plutôt mitigé de cette IDE...

Quelqu'un utilise Komodo IDE dans sa derniere version, pour m'expliquer pourquoi je devrais passer a ce dernier au lieu de rester sur PHPStorm ?

Merci.

[Fastela]

Je pense que tu réponds à ta propre question. Si tu ne vois pas pourquoi tu devrais abandonner PHPStorm, ne l'abandonne pas. Un IDE reste un outil. Si tu es à l'aise avec ton outil, tu n'as pas à en changer. Ou alors demande à ton collègue quelle est pour lui la killer feature de Komodo (première fois de ma vie que j'en entends parler en passant).

Perso j'utilise VS Code pour du Symfony et du VueJS, et j'en suis très content. Mais je n'irai pas à chercher à convertir les gens à ma solution, car c'est la mienne. (Bon à part un pote qui continue d'utiliser Notepad++, quand même).

[Whiskey]

Je vois, je verrais avec lui directement, mais j'aurais aimer avoir d'autre avis sur cette IDE en particulier. L'IDE est peut etre bon, peut etre que c'est moi qui me debrouille mal. En tout cas merci

[gros_bidule]

Peut être que ton collègue préfère Komodo parce qu'il a des pratiques de programmation différentes des tiennes. Bien sûr, vos deux pratiques peuvent êtres autant valable l'une que l'autre, à chacun sa façon d'être efficace et de prendre du plaisir à travailler.
Peut être aussi est-il resté sur une mauvaise impression de PhpStorm parce qu'il avait essayé une vieille version, ou qu'il avait commencé avec de mauvais préjugés, comme beaucoup de devs Java se tapent dessus en affirmant que Eclipse c'est mieux ou moins bien qu'IntelliJ.


Mais déjà, tu as fait l'effort d'essayer Komodo, je trouve ça tout à fait respectable.
Tu as déjà relevé des points + et -, donc tu devrais pouvoir commencer à décider quel IDE tu vas préférer. Ton collègue aura sûrement des arguments à t'exposer, tu verras bien, ça ne fera qu'enrichir le comparatif de ces deux IDE.
En tous cas, restes sur l'IDE que tu choisis. Un des arguments des gens qui imposent leur IDE, c'est les problèmes de formatage quand on bosse en équipe, donc blablabla l'équipe doit s'aligner sur un seul IDE -> foutaises, aujourd'hui avec une base de EditorConfig et un tout petit peu de paramétrage de ton IDE, tu peux être 100% compatible avec les copains. Des IDE comme IntelliJ (et toute la famille des IDE JetBrains, donc PhpStorm) l'ont bien compris et proposent même des schémas (formatages ainsi que raccourcis claviers) type Eclipse, etc.
Sur les projets où je bosse en ce moment, on a des gens sous VisualStudio Code, Eclipse, IntelliJ, et à part qqun qui ne veut pas paramétrer son IDE pour le formatage des imports, tout se passe super bien.

[Orhin]

foutaises, aujourd'hui avec une base de EditorConfig

https://prettier.io/ > all

[tenshu]

En PHP avec symfony c'est facile, les dev du framework utilisent PHP cs fixer. Il y'a une règle 'symfony' et hop le coding standard est le même.