Zend_Gdata_AuthSub.xml 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- Reviewed: no -->
  3. <sect1 id="zend.gdata.authsub">
  4. <title>Authenticating with AuthSub</title>
  5. <para>
  6. The AuthSub mechanism enables you to write web applications
  7. that acquire authenticated access Google Data services,
  8. without having to write code that handles user credentials.
  9. </para>
  10. <para>
  11. See <ulink
  12. url="http://code.google.com/apis/accounts/AuthForWebApps.html">http://code.google.com/apis/accounts/AuthForWebApps.html</ulink>
  13. for more information about Google Data AuthSub authentication.
  14. </para>
  15. <para>
  16. The Google documentation says the ClientLogin mechanism is appropriate
  17. for "installed applications" whereas the AuthSub mechanism is
  18. for "web applications." The difference is that AuthSub requires
  19. interaction from the user, and a browser interface that can react
  20. to redirection requests. The ClientLogin solution uses <acronym>PHP</acronym> code to
  21. supply the account credentials; the user is not required to enter her
  22. credentials interactively.
  23. </para>
  24. <para>
  25. The account credentials supplied via the AuthSub mechanism are
  26. entered by the user of the web application. Therefore they must be
  27. account credentials that are known to that user.
  28. </para>
  29. <note>
  30. <title>Registered applications</title>
  31. <para>
  32. <classname>Zend_Gdata</classname> currently does not support use of secure tokens,
  33. because the AuthSub authentication does not support passing a digital certificate
  34. to acquire a secure token.
  35. </para>
  36. </note>
  37. <sect2 id="zend.gdata.authsub.login">
  38. <title>Creating an AuthSub authenticated Http Client</title>
  39. <para>
  40. Your <acronym>PHP</acronym> application should provide a hyperlink to the
  41. Google <acronym>URL</acronym> that performs authentication. The static function
  42. <methodname>Zend_Gdata_AuthSub::getAuthSubTokenUri()</methodname>
  43. provides the correct <acronym>URL</acronym>. The arguments to this function include
  44. the <acronym>URL</acronym> to your <acronym>PHP</acronym> application so that Google can
  45. redirect the user's browser back to your application after the user's
  46. credentials have been verified.
  47. </para>
  48. <para>
  49. After Google's authentication server redirects the user's browser
  50. back to the current application, a <constant>GET</constant> request parameter is set,
  51. called <emphasis>token</emphasis>. The value of this parameter is a single-use token
  52. that can be used for authenticated access. This token can be converted into a multi-use
  53. token and stored in your session.
  54. </para>
  55. <para>
  56. Then use the token value in a call to
  57. <methodname>Zend_Gdata_AuthSub::getHttpClient()</methodname>.
  58. This function returns an instance of <classname>Zend_Http_Client</classname>,
  59. with appropriate headers set so that subsequent requests your
  60. application submits using that <acronym>HTTP</acronym> Client are also authenticated.
  61. </para>
  62. <para>
  63. Below is an example of <acronym>PHP</acronym> code for a web application
  64. to acquire authentication to use the Google Calendar service
  65. and create a <classname>Zend_Gdata</classname> client object using that authenticated
  66. <acronym>HTTP</acronym> Client.
  67. </para>
  68. <programlisting language="php"><![CDATA[
  69. $my_calendar = 'http://www.google.com/calendar/feeds/default/private/full';
  70. if (!isset($_SESSION['cal_token'])) {
  71. if (isset($_GET['token'])) {
  72. // You can convert the single-use token to a session token.
  73. $session_token =
  74. Zend_Gdata_AuthSub::getAuthSubSessionToken($_GET['token']);
  75. // Store the session token in our session.
  76. $_SESSION['cal_token'] = $session_token;
  77. } else {
  78. // Display link to generate single-use token
  79. $googleUri = Zend_Gdata_AuthSub::getAuthSubTokenUri(
  80. 'http://'. $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'],
  81. $my_calendar, 0, 1);
  82. echo "Click <a href='$googleUri'>here</a> " .
  83. "to authorize this application.";
  84. exit();
  85. }
  86. }
  87. // Create an authenticated HTTP Client to talk to Google.
  88. $client = Zend_Gdata_AuthSub::getHttpClient($_SESSION['cal_token']);
  89. // Create a Gdata object using the authenticated Http Client
  90. $cal = new Zend_Gdata_Calendar($client);
  91. ]]></programlisting>
  92. </sect2>
  93. <sect2 id="zend.gdata.authsub.logout">
  94. <title>Revoking AuthSub authentication</title>
  95. <para>
  96. To terminate the authenticated status of a given token, use the
  97. <methodname>Zend_Gdata_AuthSub::AuthSubRevokeToken()</methodname>
  98. static function. Otherwise, the token is still valid for
  99. some time.
  100. </para>
  101. <programlisting language="php"><![CDATA[
  102. // Carefully construct this value to avoid application security problems.
  103. $php_self = htmlentities(substr($_SERVER['PHP_SELF'],
  104. 0,
  105. strcspn($_SERVER['PHP_SELF'], "\n\r")),
  106. ENT_QUOTES);
  107. if (isset($_GET['logout'])) {
  108. Zend_Gdata_AuthSub::AuthSubRevokeToken($_SESSION['cal_token']);
  109. unset($_SESSION['cal_token']);
  110. header('Location: ' . $php_self);
  111. exit();
  112. }
  113. ]]></programlisting>
  114. <note>
  115. <title>Security notes</title>
  116. <para>
  117. The treatment of the <varname>$php_self</varname> variable in the
  118. example above is a general security guideline, it is not
  119. specific to <classname>Zend_Gdata</classname>. You should always filter content you
  120. output to <acronym>HTTP</acronym> headers.
  121. </para>
  122. <para>
  123. Regarding revoking authentication tokens, it is recommended to
  124. do this when the user is finished with her Google Data session.
  125. The possibility that someone can intercept the token and use
  126. it for malicious purposes is very small, but nevertheless it is
  127. a good practice to terminate authenticated access to any service.
  128. </para>
  129. </note>
  130. </sect2>
  131. </sect1>