multiuser-intro.xml 3.4 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- EN-Revision: 24249 -->
  3. <!-- Reviewed: no -->
  4. <sect1 id="learning.multiuser.intro">
  5. <title>Erstellung von Multi-User Anwendungen mit Zend Framework</title>
  6. <sect2 id="learning.multiuser.intro.zf">
  7. <title>Zend Framework</title>
  8. <para>
  9. Als das Originale "Web" erstellt wurde, wurde es dazu designt eine
  10. Veröffentlichungs-Platform für hauptsächlich statiche Inhalte zu sein. Als der Wunsch
  11. nach Inhalt im Web wuchs, tat es auch die Anzahl der Benutzer des Internets für Web
  12. Inhalte, und auch der Wunsch für die Verwendung des Webs als Anwendungsplattform
  13. wuchs. Seit das Web von Natur aus gut darin ist simultane Erfahrungen an viele
  14. Konsumenten von einem einzelnen Ort aus zu liefern, ist es auch die ideale Umgebung für
  15. die Erstellung von dynamisch erzeugten, Multi-User und heutzutage üblicheren Sozialen
  16. Systeme.
  17. </para>
  18. <para>
  19. <acronym>HTTP</acronym> ist das Protokoll des Webs: es ist statuslos und ein Antwort
  20. Protokoll. Dieses Protokoll wurde so erstellt weil der originale Zweck des Webs das
  21. anbieten und veröffentlichen von statischem Inhalt war. Es ist auch dieses Design
  22. welches das Web so immens erfolgreich gemacht hat wie es ist. Es ist auch exakt dieses
  23. Design welches Entwicklern neue Bedenken bereitet wenn Sie das Web als
  24. Anwendungsplattform verwenden wollen.
  25. </para>
  26. <para>
  27. Diese Bedenken und Verantwortlichkeiten können effektiv in drei Fragen zusammengefasst
  28. werden:
  29. </para>
  30. <itemizedlist>
  31. <listitem>
  32. <para>Wie trennt den Benutzer einer Anwendung von einem anderen?</para>
  33. </listitem>
  34. <listitem><para>Wie identifiziert man einen Benutzer als authentisch?</para></listitem>
  35. <listitem><para>Wie kontrolliert man wozu ein Benutzer Zugriff hat?</para></listitem>
  36. </itemizedlist>
  37. <note>
  38. <title>Konsument vs. Benutzer</title>
  39. <para>
  40. Es ist zu beachten das wir den Ausdruck "Benutzer" statt Person verwenden. Web
  41. Anwendungen werden immer mehr von Services betrieben. Das bedeuetet das es nicht nur
  42. Personen ("Benutzer") mit echten Web Browsern gibt welche die Anwendung konsumieren
  43. und verwenden, sondern auch andere Web Anwendungen die durch eine Maschinen Service
  44. Technologie wie <acronym>REST</acronym>, <acronym>SOAP</acronym>, und
  45. <acronym>XML-RPC</acronym> darauf zugreifen. Deshalb sollten Personen, wie auch
  46. andere benutzende Anwendungen, alle auf dem selben Weg behandelt werden und den
  47. selben Bedenken die oben beschrieben wurden.
  48. </para>
  49. </note>
  50. <para>
  51. In den folgenden Kapiteln, sehen wir uns diese gemeinsamen Probleme an welche im Detail
  52. auf Authentifizierung und Autorisierung Bezug nehmen. Wir werden die 3 Hauptkomponenten
  53. kennenlernen: <classname>Zend_Session</classname>, <classname>Zend_Auth</classname>, und
  54. <classname>Zend_Acl</classname>; eine sofort verwendbare Lösung anbieten sowie
  55. Erweiterungspunkte welche auf eine bessere anpassbare Lösung abzielen.
  56. </para>
  57. </sect2>
  58. </sect1>