multiuser-intro.xml 3.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- EN-Revision: 24249 -->
  3. <!-- Reviewed: no -->
  4. <sect1 id="learning.multiuser.intro">
  5. <title>Fabrique une application Multi-Utilisateurs avec Zend Framework</title>
  6. <sect2 id="learning.multiuser.intro.zf">
  7. <title>Zend Framework</title>
  8. <para>
  9. Lorsque le web a été crée, il s'agissait d'un média permettant de consulter des
  10. documents statiques. La demande de contenu a cru, le nombre d'internautes aussi
  11. et les sites webs sont devenus des applications tournant sur de grosses plateformes.
  12. </para>
  13. <para>
  14. <acronym>HTTP</acronym> est le protocole du web: sans état, des requêtes/réponses
  15. à courte durée de vie. Ce protocole a été crée comme cela pour assurer le web
  16. tel qu'on l'entendait avant : servir du contenu statique et c'est ce design qui
  17. a fait du web un immense succès. C'est aussi ce design qui mène à des notions que
  18. les développeurs veulent utiliser dans leurs applications.
  19. </para>
  20. <para>
  21. Ces informations nous mènent à trois questions:
  22. </para>
  23. <itemizedlist>
  24. <listitem>
  25. <para>
  26. Comment distinguer les clients d'une application?
  27. </para>
  28. </listitem>
  29. <listitem>
  30. <para>
  31. Comment identifier ces clients?
  32. </para>
  33. </listitem>
  34. <listitem>
  35. <para>
  36. Comment contrôler les droits d'un client identifié?
  37. </para>
  38. </listitem>
  39. </itemizedlist>
  40. <note>
  41. <title>Client contre Utilisateur</title>
  42. <para>
  43. Nous utilisons le terme "client" et pas utilisateur. Les applications web deviennent
  44. des fournisseurs de services. Ceci signifie que les "gens", les utilisateurs humains
  45. avec des navigateurs web ne sont pas les seuls à consommer l'application et ses services.
  46. Beaucoup d'autres applications web consomment elles-mêmes des ressources sur une
  47. application via des technologies comme <acronym>REST</acronym>, <acronym>SOAP</acronym>,
  48. ou <acronym>XML-RPC</acronym>. On voit bien qu'on ne peut parler d'utilisateur, nous
  49. traitons donc les utilisateurs humains des utilisateurs machines sous le même nom :
  50. des "clients" web.
  51. </para>
  52. </note>
  53. <para>
  54. Dans les chapitres qui suivent, nous nous attaquerons à ces problèmes que sont
  55. l'authentification, l'identification et les détails. Nous allons découvrir trois
  56. composants: <classname>Zend_Session</classname>, <classname>Zend_Auth</classname>, et
  57. <classname>Zend_Acl</classname>; nous montrerons des exemples concrets et des possibilités
  58. d'extension.
  59. </para>
  60. </sect2>
  61. </sect1>