Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 220 sur 220 PremièrePremière ... 120170210212213214215216217218219220
Affichage des résultats 6 571 à 6 588 sur 6588
  1. #6571
    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" .

  2. #6572
    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 ?
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  3. #6573
    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.


  4. #6574
    Citation Envoyé par tenshu Voir le message
    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.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  5. #6575
    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é.


  6. #6576
    Citation Envoyé par Teocali Voir le message
    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.
    C'est la faute à Arteis

  7. #6577
    Citation Envoyé par tenshu Voir le message
    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.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  8. #6578
    Citation Envoyé par Teocali Voir le message
    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).
    Attention, un Max_well peut en cacher un autre
    Equipe Highlander La Rache

  9. #6579
    Citation Envoyé par Max_well Voir le message
    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.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  10. #6580
    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 la faute à Arteis

  11. #6581
    Citation Envoyé par Orhin Voir le message
    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.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  12. #6582
    Citation Envoyé par Teocali Voir le message
    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/


  13. #6583
    Citation Envoyé par tenshu Voir le message
    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.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

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

    C bo se ke je di


  15. #6585
    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 ?
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  16. #6586
    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.


  17. #6587
    Citation Envoyé par Teocali Voir le message
    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).

  18. #6588
    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 !

Page 220 sur 220 PremièrePremière ... 120170210212213214215216217218219220

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •