Zend FR

Oui. J'ai étudié un peu le système SSO et c'est en partie de là que m'est venu l'idée du compte unique.
Par contre, je ne peux pas utiliser un système déjà existant parce que je veux avoir la main sur les comptes et la façon de les gérer.
J'ai déjà cette centralisation qui marche parfaitement. Cependant, cela nécessite que les applications aient accès à la base de donnée du site centrale et c'est cette partie que je voudrais interfacer.
J'avais un début de piste avec Zend_server mais la doc est très difficilement compréhensible.

De plus, la connexion centralisée n'est qu'un exemple des services que le site appli devra proposer aux applications.

Je cherche vraiment à créer une API indépendante. Je suis pas sorti du sable...

Merci sekaijin. C'est EXACTEMENT ce que je voulais entendre (heu.. lire). Je ne savais pas que ces composants du ZF permettait cette utilisation (non, je n'ai pas encore lu toute la doc ).
J'attendais également l'avis d'un utilisateur confirmé du ZF pour connaître le faisabilité de ce système.
J'aimerais également connaître une dernière chose :
Est-ce vraiment sécurisé ?
Suffit-il d'utiliser le classique clé privé/clé publique pour identifier les applications clientes ou y a-t-il des notions de sécurité plus poussées sur lesquelles je doit me renseigner ?

Dans tout les cas, tu m'as bien avancer. Si personne ne me dit "mais non, c'est impossible à faire", je pense que je pars sur cette solution.

Dernière modification par slaughter (07-01-2009 09:56:38)

Bonjour,
Le sujet m'interresse aussi, et j'aimerai savoir pourquoi ne pas justement utilisé OpenId, crée son propre serveur. OpenId est fait pour ca non ? Donc pourquoi SOAP ? Je ne connais pas du tout SOAP.
Alors y a t-il des inconveniants à openID ?

Merrci

Bonjour,

Oui c'est possible, j'ai créé de mon côté un serveur Soap qui renvoie des informations liées aux sites internet.

Par exemple, des news, des info commerciales, etc.

Ce qui permet aux développeurs d'applications windows de récupérer ces infos et d'en informer les clients dans leurs appli.

@alien7, je ne connais pas bien OpenId donc je ne peux pas te répondre. Le serveur Soap répond très bien à mes demandes en cas de besoin d'échanges multi-langages, donc je n'ai pas vraiment cherché à faire autrement.

Le "seul" inconvénient de Soap (comme le reste d'ailleurs) c'est que certains langages ne sont pas capables de récupérer correctement certains types de données xsd.

Par exemple, windev ne permet pas de récupérer ou d'envoyer des array(), on doit faire les échanges en XML.


@slaughter : Je suis très chargé, mais je vais essayer de te filer un exemple d'adapter pour Zend_Auth aujourd'hui.

A+ benjamin.

Je comprends pas très bien tous ca, Zend_Auth gère l'authentification OpenId donc pas de problème non ?
J'aimerai mettre en place un server OpenId privé.

Alors est-ce possible tous ca ?

Sinon quel est le meilleur moyen pour une authentification multi sites ?
Encore merci

non non L'idée d'OpenID n'est pas que l'application ait SON serveur OpenID pour que ses utilisateurs aient une identité numérique.

l'idée d'OpenID c'est que l'utilisateur CHOISISSE SON serveur OpenID et que l'application ne garde plus d'information d'identité sur ses utilisateur.

en gors si tu veux rendre ton application compatible OpenID l'orsque un utilisateur est enregistré c'est LUI qui te fourni une url sur SON serveur OpenID. et à chaque fois que ton application a besoin d'une information sur lui elle va la chercher sur SON serveur.

tu peux bien évidemment être toit aussi serveur OpenID pour les utilisateur qui n'ont pas déjà de serveur Mais pour être compatible tu DOITS ouvroir ton application à TOUS les serveurs OpenID.

si non OpenID ne sert à rien car tes utilisateur deraient avoir une identité dans de multiple serveur comme lorsqu'il n'y avait pas OpenID.

dans ces condition il n'est pas question de baser l'AUTHENTIFICATION sur OpenID car cela signifie faire confiance à n'importe quel serveur OpenID pour TA sécurité même celui d'un pirate.

Tu dois donc avoir TON serveur d'authentification (LDAP, Active directory, DB, SOAP, SSO etc.) pour la gestion des autorisation et si tu ne veux pas gérer les donnée (informatives) de tes utilisateur accepter le protocole OpenID

A+JYT

oui et non. Soap est un protocole d'invocation de services distants (on utilise le terme de service car on ne fait alors pas la différences entre échange de donnée et invocation de méthode.)
c'est donc un échange de donnée d'ans le sens où on envois ou l'on reçois des données d'une service. mais c'est aussi un appel distant comme RCP.

si on s'en tien à la théorie et à la norme NON SOAP ne se rapproche pas de l'API google. en effet dans la norme pour invoquer un service on DOIT envoyer au serveur une enveloppe SOAP contenant le message (l'appel) alors qu'avec Google on a une URL avec des paramètre selon le protocole HTTP la base de l'URL représente la méthode à invoquer et les paramètres étant passé dans la query string en GET ou en POST.

Avec SOAP tu as un point d'entré (Une URL HTTP mais aussi une adresse mail où tout autre protocole de transport ce peut être FTP) et tu envois dans une enveloppe (un flux XML) contenant la méthode et les paramètre. pour invoquer un service SOAP en HTTP il faut donc envoyer dans le flux TCP de la connexion le paquet XML en résumé un TCP_Connect suivit du write et d'un read (pas de POST pas de GET pas de query string)

en restant au plus proche de la norme on peut écrire un bout de Javascript à coller dans sa page qui va utiliser XMLHttpRequest pour envoyer le flux et lire la réponse.

dans les faits les service SOAP peuvent être plus souple. ainsi il est possible sur son serveur SOAP d'accepter les demandes SOAP en mode GET ou POST de HTTP il y a une limite à ça pour passer le flux XML dans le GET ou le POST il est nécessaire de le sérialiser avec un URL_Encode du coup la taille s'en trouve limité. En POST on peut aller plus loin et utiliser form/multipart mais là il faut encapsuler le flux dans un multipart html.

c'est la raison pour laquelle la plus part des services SOAP accepte aussi l'invocation par une Query String. généralement ça prend la forme de method=mafonction&parm1=val1 etc.
mais ce n'est jouable que pour les service qui reçoivent en paramètre que quelques valeur. en gros le cas RCP il est beaucoup plus difficile par ce biais d'échanger un gros flux de donnée. en gros cela consiste à accepter un appel REST pour son service et de répondre en SOAP

SOAP est fait pour faire communiquer des application en elles. pas pour que les page web soient enrichie de quelques fonctions.

pour faire ça mieux vaut utiliser REST.

personnellement je préfère ne pas mettre dans mon IHM d'appel à une autre application. si j'en ai besoin. je fais un service local à mon application qui lui invoque l'application distante. ainsi c'est mon application qui maitrise les échanges entre applications l'IHM ne faisant que dispenser la vue.

A+JYT

oui c'est bien ça SOAP n'est pas fait pour ça
SOAP est fait pour que ton application appelle un service distant mais pas pour que le client de ton appli aille chercher des infos à droite ou à gauche.

Je maintient que pour la bonne santé d'une application il est préférable que ce soit le serveur qui maitrise les élément à afficher et non le client. pour afficher un bandeau avec tout ça moi je ferais un (des) appels coté application qui interroge les diverse sources nécessaire et fournis à la vue les infos à afficher. 

le serveur est bien plus à même de traiter les défaillance des fournisseurs d'informations que le client.

le système de google est fait pour que tout un chacun puisse inclure des infos de chez dans leur page quelque soit la techno du serveur du coup ils n'ont pas le choix le seul truc commun est HTML et JS

je trouve d'ailleurs ce truc assez agaçant. en effet combien de forum commence à charger la page puis se fige pendant un bon bout de temps avant de continuer à afficher le reste. quand ce n'est pas une collection de point rouge dans firebug qui apparaissent parce que le code de google entre en conflit avec celui de la page.

c'est évidement plus complexe de faire un Zend_Http_Client que d ecoller un bout de javascript dans sa page. mais lorsqu'on fait ça on maitrise le délais d'attente, les erreur de réponse etc. et en plus on n'est pas contraint par l'outil distant quant à la présentation. car autant il est très important de mettre en avant qu'il y a des message non lu dans une application de communication, autant dans l'appli de gestion de la facturation cela doit rester en arrière plan pour ne pas déconcentrer la personne qui travaille.

cela ne signifie pas pour autant que reporter côté client l'appel distant supprime tout élément d'IHM rien n'empêche en effet de relayer ses données (graphiques) comme n'importe quelle autre.

A+JYT

un site est une application le serveur héberge ton code PHP et le client le navigateur lui interprète le code javascript

Je n'associe pas serveur et site central ni client et site client.

le client et le navigateur le serveur une de tes applis.

mon propos est de dire que le navigateur ne doit pas voir autre chose que sont serveur. I.E. les pages de ton application webmail ne soive voir que le serveur de Webmail. les pages de l'application de gestion RH que le serveur RH

à mon avis si le webmail et l'application RH ont besoin d'accéder à une application centrale c'est au serveur php de faire l'appel pas un javascript dans les pages de ceux-ci.

c'est un avis personnel je comprends que d'autre aient une autre approche.

A+JYT

Un client est celui qui pose une question, un serveur, celui qui y répond.

Rien n'émèche le serveur web interrogé (par un navigateur ou autre chose) d'être lui-même client sur un autre service (pas forcément web).

Donc, point de vue sécurité, je rejoins sekaijin, le navigateur doit avoir un seul et unique interlocuteur, le serveur de l'application demandé.

Pour manipuler des données communes à plusieurs application, j'utiliserais un service (pas forcément web, mais XML-RPC et SOAP son des solutions), qui est interrogé par l'application serveur demandeur, et non pas par un javascript placé coté utilisateur.

Dernière modification par nORKy (03-11-2008 15:46:47)

Petit Up.

Une autre question me vient à l'esprit. Pour l'instant je fonctionne toujours avec la connexion sur les deux bases directement (base de l'application centrale et base de l'application cliente).
Tout marche parfaitement mais les deux bases se trouve sur le même serveur MySQL (physique et logique).
Je n'arrive pas à avoir assez de recule pour savoir si j'aurai des problèmes le jour où j'aurais besoin de séparer les deux bases sur des serveurs physiques différents.

Je sais que ça commence à faire pas mal de question mais j'ai besoin de personne plus expérimentées pour avoir une réflexion "complète"...