Please, consider the following interdiff:

diff --git a/doc/design-rapi-pam.rst b/doc/design-rapi-pam.rst
index b5bc5ed..5d2679e 100644
--- a/doc/design-rapi-pam.rst
+++ b/doc/design-rapi-pam.rst
@@ -5,14 +5,14 @@ RAPI authentication and authorization using PAM
 .. contents:: :depth: 4

 This design document describes a way of :doc:`rapi` authentication
-and authorization refactoring by using pluggable authentication modules
-(PAM).
+and authorization refactoring by using the pluggable authentication
+modules (PAM).

 Current State
 =============

-Currently :doc:`rapi` supports authentication using *basic* https
-protocol. The users are stored in a file (usually
+Currently :doc:`rapi` supports authentication using *basic auth* over
+https protocol. The users are stored in a file (usually
 ``/var/lib/ganeti/rapi/users``) and have either read or write rights.
 Please read :ref:`rapi-users` for more details.

@@ -21,7 +21,7 @@ Please read :ref:`rapi-users` for more details.
 Motivation
 ==========

-During the GanetiCon 2015 the following features were requested by the
+During GanetiCon 2015 the following features were requested by the
 community:

 - Support for different authentication methods;
@@ -48,7 +48,7 @@ at http://www.linux-pam.org/pre/doc/current-draft.txt.
 Authentication Specific Details
 -------------------------------

-In case of *basic* http authentication, the username and password will
+In case of *basic auth* over http, the username and password will
 be extracted as they are presented in the
 :ref:`standard form <basic-protocol>`. Note, that independent from
 authentication method, all interactions will be performed via https
@@ -57,7 +57,7 @@ protocol.
 In case of another authentication method, additional user's credintials
 (e.g. request signature) should be provided in
 ``Ganeti-RAPI-Credential`` field. The field should be encoded using
-base64 algorithm as for the *basic* authentication.
+base64 algorithm as for the *basic auth* over http.

 Ganeti will copy the username to ``PAM_USER`` field of a ``pam_handler``
 and the contents of ``Ganeti-RAPI-Credential`` http header fielf to
@@ -77,7 +77,12 @@ variables (using ``pam_setenv``)
 GANETI_RAPI_URI
   The requested URI.
 GANETI_REQUEST_BODY
-  The body of a request.
+  The body of a request if any or an empty string otherwise.
+GANETI_REQUEST_METHOD
+  The method of an http request (GET, PUT, POST or DELETE).
+GANETI_RESOURCE_ACCESS
+  The comma-separated access handlers of a resource if provided in
+  rlib2 or empty string otherwise.

 One More Time About the Goals
 =============================
@@ -88,7 +93,7 @@ Support for Different Authentication Methods
 The proposed solution allows to use signatures of any kind instead of
 user password or in addition to it. It allows an administrator to
 support more complex and secure authentication schemes than just a basic
-authentication.
+authentication over http.

 Granular Access to Different Command Subsets
 --------------------------------------------
@@ -110,7 +115,8 @@ Switching Between the Old and the New Implementations
 -----------------------------------------------------

 As the changes introduced should be backwards compatible, a new
-configure flag ``--enable_pam_rapi`` will be introduced.
+ganeti-rapi daemon run-time option ``--enable_pam_rapi`` will be
+introduced.

 Other Changes
 =============
@@ -126,7 +132,7 @@ allow to configure a filter that will reject job subsets initiated
 by some specific user i.e. add a user to a blacklist. See
 :doc:`design-optables` for more information about job filters.

-Another proposal is to introduce a new
+Additionally, we propose to introduce a new
 :ref:`filter predicate <filter-predicates>`, ``username`` that will
 contain the authenticated user's login and thus will make it possible to
 define an allowed user set for each operation.

Reply via email to