expendable a écrit 4 commentaires

  • [^] # Re: tag

    Posté par  . En réponse au journal Diaspora devient un projet communautaire. Évalué à 0. Dernière modification le 29 août 2012 à 23:23.

    Merci pour ta réponse.

    Pour compléter mon message précédent, dans une situation purement hypothétique où comme tu le dis Firefox se rapprocherait de XMPP pour son intégration, ne pourrait-on pas aller encore plus loin dans l'exploitation de XMPP pour authentifier un utilisateur en faisant passer tous les échanges HTTP (dans le cas d'une connexion toute simple à son espace privé d'un site Web lambda) par le serveur XMPP du client, et ne plus se contenter de ne transmettre uniquement que des secrets valables pendant une certaine durée ?

    L'aspect le plus problématique serait l'augmentation de la charge du serveur XMPP qui se verrait utiliser en tant que proxy, mais question sécurité il suffirait de chiffrer les échanges grâce à HTTPS pour que le serveur XMPP ne puisse pas s'immiscer dans les échanges.
    Dans ce cas comme tu l'as dit il faudrait que le navigateur ainsi que le serveur Web hébergeant le site que nous souhaitons consulter possèdent un support de XMPP. Je crois que c'est là où je voulais en venir quand je parlais de HTTP over XMPP, je m'y perds un peu je dois dire, je ne suis pas développeur et le nombre de RFCs que j'ai dû lire dans ma vie se compte sur les doigts d'une main ! :-p

  • [^] # Re: tag

    Posté par  . En réponse au journal Diaspora devient un projet communautaire. Évalué à 0.

    Très intéressant, par contre l'utilisateur est obligé de confirmer (ou refuser) à la main la demande par le biais de son client XMPP si j'ai bien compris ?

    N'y aurait-il pas la possibilité d'automatiser ça ? Dans le cas d'une requête sur un site Web par exemple, je pense à une méthode d'authentification HTTP basée sur le JID avec un numéro de ressource aléatoire. Le serveur Web répondrait à cette adresse en transmettant un secret que l'application cliente (le navigateur Web en l’occurrence) irait lire (ou se verrait pousser par le serveur XMPP, pourquoi pas pendant qu'on y est). Ensuite celui-ci réinterroge le serveur Web en indiquant le secret dans l'en-tête HTTP.

    Bien sûr rien de cela n'existe (enfin je pense). ;)

  • [^] # Re: tag

    Posté par  . En réponse au journal Diaspora devient un projet communautaire. Évalué à 1.

    J'ai fait un tour sur ton blog et j'avoue que les fonctionnalités de SàT que tu présentes sont extrêmement intéressantes ! :)

    Ok XMPP peut se suffire à lui-même, mais je me demande si XMPP ne pourrait pas être utilisé comme module d'"identification" pour plein d'applications, et notamment le Web.
    Une alternative aux comptes utilisateurs à créer sur chaque site Web, un identifiant unique : le JID.

  • [^] # Re: tag

    Posté par  . En réponse au journal Diaspora devient un projet communautaire. Évalué à 2.

    Est-ce qu'il ne serait pas intéressant d'utiliser une de ces implémentations de réseaux sociaux au-dessus de XMPP, voire carrément faire du HTTP over XMPP ?

    Grosso modo il s'agirait d'utiliser XMPP uniquement en tant que transporteur et gestionnaire d'ACLs.

    Ça me semble intéressant dans le cas de données privées par exemple : un utilisateur souhaitant accéder à des informations de blogging dont l'accès est réservé à certains utilisateurs identifiés, le module XMPP vérifie les droits à l'aide d'ACLs et relaie les infos entre le réseau social et l'utilisateur distant autorisé à travers un transport classique XMPP type messagerie instantanée.

    Pourquoi recréer des fonctionnalités de réseaux sociaux dans XMPP alors que des solutions et protocoles existent déjà…