You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@geode.apache.org by db...@apache.org on 2021/11/05 18:46:50 UTC

[geode] branch support/1.13 updated (f0f5e48 -> 00aad0e)

This is an automated email from the ASF dual-hosted git repository.

dbarnes pushed a change to branch support/1.13
in repository https://gitbox.apache.org/repos/asf/geode.git.


 discard f0f5e48  GEODE-9797: User guide typo repairs (#7085)
     new 00aad0e  GEODE-9797: User guide typo repairs (#7085)

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (f0f5e48)
            \
             N -- N -- N   refs/heads/support/1.13 (00aad0e)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 geode-docs/managing/security/implementing_authentication.html.md.erb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[geode] 01/01: GEODE-9797: User guide typo repairs (#7085)

Posted by db...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

dbarnes pushed a commit to branch support/1.13
in repository https://gitbox.apache.org/repos/asf/geode.git

commit 00aad0ed326466e9b85add7353b1061acf450af0
Author: Dave Barnes <db...@apache.org>
AuthorDate: Fri Nov 5 09:17:08 2021 -0700

    GEODE-9797: User guide typo repairs (#7085)
---
 .../security/authentication_examples.html.md.erb   |   2 +-
 .../implementing_authentication.html.md.erb        | 154 +++++++++++----------
 2 files changed, 83 insertions(+), 73 deletions(-)

diff --git a/geode-docs/managing/security/authentication_examples.html.md.erb b/geode-docs/managing/security/authentication_examples.html.md.erb
index ce73399..b57ce38 100644
--- a/geode-docs/managing/security/authentication_examples.html.md.erb
+++ b/geode-docs/managing/security/authentication_examples.html.md.erb
@@ -34,7 +34,7 @@ spoof the system.
 
 This example assumes that a set of user name and password pairs
 representing users that may be successfully authenticated 
-has been read into a data structure upon intialization.
+has been read into a data structure upon initialization.
 Any component that presents the correct password for a user name
 successfully authenticates,
 and its identity is verified as that user.
diff --git a/geode-docs/managing/security/implementing_authentication.html.md.erb b/geode-docs/managing/security/implementing_authentication.html.md.erb
index 64091f2..a4ceb88 100644
--- a/geode-docs/managing/security/implementing_authentication.html.md.erb
+++ b/geode-docs/managing/security/implementing_authentication.html.md.erb
@@ -42,92 +42,102 @@ compared to the credential presented or will have a way of obtaining those pairs
 In order to connect with a locator that does authentication,
 a server will need to set its credential, composed of the two properties
 `security-username` and `security-password`.
-There are two ways of accomplishing this:
+Choose one of these two ways to accomplish this:
 
-- Set the `security-username` and `security-password` in the server's
+- Set `security-username` and `security-password` in the server's
 `gfsecurity.properties` file that will be read upon server start up,
 as in the example
 
-     ``` pre
-     security-username=admin
-     security-password=xyz1234
-     ```
-The user name and password are stored in the clear, so the
-`gfsecurity.properties` file must be protected by restricting access with
-file system permissions.
-
-- Implement the `getCredentials` method of the `AuthInitialize` interface
-for the server.
-This callback's location is defined in the property `security-peer-auth-init`,
-as in the example
-
-     ``` pre
-     security-peer-auth-init=com.example.security.MyAuthInitialize
-     ```
-The implementation of `getCredentials` may then acquire values for
-the properties `security-username` and `security-password` in whatever way
-it wishes.
-It might look up values in a database or another external resource.
+    ``` pre
+    security-username=admin
+    security-password=xyz1234
+    ```
+    The user name and password are stored in cleartext, so the
+    `gfsecurity.properties` file must be protected by restricting access with
+    file system permissions.
+
+- Implement `AuthInitialize` interface for the server.
+    
+    - Set the property `security-peer-auth-init`,
+    so that an object of the class that implements the `AuthInitialize`
+    interface will be instantiated.
+    Set the property to one of these two values:
+
+        - Set property `security-peer-auth-init` to the fully-qualified
+        class name that implements the `AuthInitialize` interface
+        as in the example
+
+        ``` pre
+        security-peer-auth-init=com.example.security.ServerAuthenticate
+        ```
+        - Set property `security-peer-auth-init` to the fully-qualified
+        method name of a method that instantiates an object of the class
+        that implements the `AuthInitialize` interface
+        as in the example
+
+        ``` pre
+        security-peer-auth-init=com.example.security.ServerAuthenticate.create
+        ```
+
+    - Implement the `getCredentials` method within the `AuthInitialize`
+    interface to acquire values for
+    the `security-username` and `security-password` properties
+    in whatever way it wishes.
+    It might look up values in a database or another external resource.
 
 Gateway senders and receivers communicate as a component of their
 server member.
 Therefore, the credential of the server become those of the gateway
 sender or receiver.
 
-## How a Cache Client Sets Its Credential
+## How a Client Cache Sets Its Credential
 
-<!--  Revised for GEODE-1883
 In order to connect with a locator or a server that does authentication,
 a client will need to set its credential, composed of the two properties
 `security-username` and `security-password`.
-There are two ways of accomplishing this:
-
-- Set the `security-username` and `security-password` in the client's
-`gfsecurity.properties` file that will be read upon client start up,
-as in the example
-
-     ``` pre
-     security-username=clientapp
-     security-password=xyz1234
-     ```
-The user name and password are stored in the clear, so the
-`gfsecurity.properties` file must be protected by restricting access with
-file system permissions.
-To accomplish this:
-
-- Implement the `getCredentials` method of the `AuthInitialize` interface
-for the client.
-This callback's location is defined in the property `security-client-auth-init`,
-as in the example
-
-     ``` pre
-     security-client-auth-init=com.example.security.ClientAuthInitialize
-     ```
-The implementation of `getCredentials` may then acquire values for
-the properties `security-username` and `security-password` in whatever way
-it wishes.
-It might look up values in a database or another external resource,
-or it might prompt for values.
--->
-
-In order to connect with a locator or a server that does authentication,
-a client will need to set its credential, composed of the two properties
-`security-username` and `security-password`.
-To accomplish this:
-
-- Implement the `getCredentials` method of the `AuthInitialize` interface
-for the client.
-This callback's location is defined in the property `security-client-auth-init`,
-as in the example
-
-     ``` pre
-     security-client-auth-init=com.example.security.ClientAuthInitialize
-     ```
-The implementation of `getCredentials` may then acquire values for
-the properties `security-username` and `security-password` in whatever way
-it wishes.
-It might look up values in a database or another external resource,
-or it might prompt for values.
+Choose one of these two ways to accomplish this:
+
+- Set the `security-username` and `security-password` properties for the client
+using the API:
+
+    ``` pre
+    Properties properties = new Properties();
+    properties.setProperty("security-username", "exampleuser23");
+    properties.setProperty("security-password", "xyz1234");
+    ClientCache cache = new ClientCacheFactory(properties).create();
+    ```
+
+    Take care that credentials set in this manner are not accessible
+    to observers of the code.
+ 
+- Implement `AuthInitialize` interface for the client.
+
+    - Set the property `security-client-auth-init`,
+    so that an object of the class that implements the
+    `AuthInitialize` interface will be instantiated.
+    Set the property to one of these two values:
+
+        - Set property `security-client-auth-init` to the fully-qualified
+        class name that implements the `AuthInitialize` interface:
+
+        ``` pre
+        security-client-auth-init=com.example.security.ClientAuthInitialize
+        ```
+        - Set property `security-client-auth-init` to the fully-qualified
+        name of a static method that instantiates an object of the class
+        that implements the `AuthInitialize` interface:
+
+        ``` pre
+        security-client-auth-init=com.example.security.ClientAuthInitialize.create
+        ```
+
+    - Implement the `getCredentials` method of the `AuthInitialize` interface
+    for the client.
+    The implementation of `getCredentials` acquires values for
+    the `security-username` and `security-password` properties in whatever way
+    it wishes.
+    It might look up values in a database or another external resource,
+    or it might prompt for values.
 
 ## How Other Components Set Their Credentials