[GitHub] nickva opened a new issue #1153: Flexible replicator client auth + session support

[GitBox <gi...@apache.org>]

nickva opened a new issue #1153: Flexible replicator client auth + session support
URL: https://github.com/apache/couchdb/issues/1153
 
 
   Even though session / cookie based authentication has been around for years, replicator only knows how to use basic authentication. Let's teach it to use session based authentication to get better performance and flexibility. 
   
   Using basic authentication means sending username and password credentials with every request. It certainly is simple and with a fast password hashing algorithm like SHA1 it's not too bad performance-wise. However when the newer PBKDF2 password hashing is used, especially with a larger work factor, which by design slows down authentication speed, performance can start to suffer. 
   
   ### Proposal
   
   Implement a simple pluggable framework for replication clients. Make basic auth, currently OAuth 1.0 and the new session support act as plugins. This allows extending it in the future adding OAuth 2.0 or a customer-specific scheme without too much work. Also if OAuth 1.0 is not used very much when it is moved to a separate plugin it is easier to deprecated or make it disable by default, then eventually removing it.
   
   ### Specifics
   
   A list of replicator client authentication handler modules is specified in the config file. This list is ordered and defines a precedence. For example it could look like:
   
   ```
   [replicator]
   client_auth_modules = [replicator_client_auth_oauth, replicator_client_auth_session]
   ```
    An instance of a client authentication context is created for both the source and target endpoints. When a replication job starts, it uses the per-endpoint specific information (headers, url, connection timeouts), config options and possibly the presence of  specific endpoints like say _session to pick an active authentication handler.
   
   Then, before each request to an endpoint, authentication handler is allowed to update the request headers with authentication info. During update the handler might fetch and refresh a token or cookie and add then cookie to the header list.
   
   If the request fails with a 401, authentication handler is notified. Internally it might decide to update the cookie and return a "retry" to signal that the request is safe to retry or it could fail and signal that the 401 failure should propagate, and possibly crash the replication job.
   
   ### Erlang API
   
   This is the proposed interface to the `couch_replicator_auth` module:
   
   ```
   initialize(#httpdb{}) -> {ok, #httpdb{}} | {error, Error}
   
   update_headers(#httpdb{}, Headers) -> {ok, UpdatedHeaders} | {error, Error}
   
   handle_response(#httpdb{}, ResponseCode, ResponseMessage) -> ok | retry | {error, Error}
   
   cleanup(#httpdb{}) -> #httpdb{}
   ```
   
   `initialize/1` will be called after the connection worker is spawned but before the first request is made:
   https://github.com/apache/couchdb/blob/master/src/couch_replicator/src/couch_replicator_api_wrap.erl#L74
   
   `update_headers/2` and `handle_response/3` will be called in httpc module before and after the request: https://github.com/apache/couchdb/blob/master/src/couch_replicator/src/couch_replicator_httpc.erl#L89
   
   `#httpd{}` is the parsed endpoint information. It will contain credentials, headers, URLs and possibly other bits: https://github.com/apache/couchdb/blob/master/src/couch_replicator/src/couch_replicator_api_wrap.hrl 
   
   `#httpdb{}` record will be updated to have a few extra fields. It will store the opaque context retrieved from the client auth plugin initialize/1 call. OAuth will be moved to a plugin.
   
   `cleanup/1` function will be called after the session is no longer needed. It allows the active plugin to stop any processes or do other necessary cleanup. The return is an updated `#httpdb{}`  record with the client_auth_context set to nil
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services