nickva commented on a change in pull request #1176: Implement pluggable authentication and session support for replicator URL: https://github.com/apache/couchdb/pull/1176#discussion_r170107966
########## File path: src/couch_replicator/src/couch_replicator_auth_session.erl ########## @@ -0,0 +1,545 @@ +% Licensed under the Apache License, Version 2.0 (the "License"); you may not +% use this file except in compliance with the License. You may obtain a copy of +% the License at +% +% http://www.apache.org/licenses/LICENSE-2.0 +% +% Unless required by applicable law or agreed to in writing, software +% distributed under the License is distributed on an "AS IS" BASIS, WITHOUT +% WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the +% License for the specific language governing permissions and limitations under +% the License. + + +% This is the replicator session auth plugin. It implements session based +% authentication for the replicator. The only public API are the functions from +% the couch_replicator_auth behaviour. Most of the logic and state is in the +% gen_server. An instance of a gen_server could be spawned for the source and +% target endpoints of each replication jobs. +% +% The workflow is roughly this: +% +% * On initialization, try to get a cookie in `refresh/1` If an error occurs, +% the crash. If `_session` endpoint fails with a 404 (not found), return +% `ignore` assuming session authentication is not support or we simply hit a +% non-CouchDb server. +% +% * Before each request, auth framework calls `update_headers` API function. +% Before updating the headers and returning, check if need to refresh again. +% The check looks `next_refresh` time. If that time is set (not `infinity`) +% and just expired, then obtain a new cookie, then update headers and +% return. +% +% * After each request, auth framework calls `handle_response` function. If +% request was successful check if a new cookie was sent by the server in the +% `Set-Cookie` header. If it was then then that becomes the current cookie. +% +% * If last request has an auth failure, check if request used a stale cookie +% In this case nothing is done, and the client is told to retry. Next time +% it updates its headers befor the request it should pick up the latest +% cookie. +% +% * If last request failed and cookie was the latest known cookie, schedule a +% refresh and tell client to retry. However, if the cookie was just updated, +% tell the client to continue such that it will handle the auth failure on +% its own via a set of retries with exponential backoffs. This is it to +% ensure if something goes wrong and one of the endpoints issues invalid +% cookies, replicator won't be stuck in a busy loop refreshing them. + + +-module(couch_replicator_auth_session). + + +-behaviour(couch_replicator_auth). +-behaviour(gen_server). + + +-export([ + initialize/1, + update_headers/2, + handle_response/4, + cleanup/1 +]). + +-export([ + init/1, + terminate/2, + handle_call/3, + handle_cast/2, + handle_info/2, + code_change/3, + format_status/2 +]). + + +-include_lib("ibrowse/include/ibrowse.hrl"). +-include_lib("couch_replicator/include/couch_replicator_api_wrap.hrl"). + + +-type headers() :: [{string(), string()}]. +-type code() :: non_neg_integer(). +-type creds() :: {string() | undefined, string() | undefined}. + + +% Behavior API callbacks + + +-spec initialize(#httpdb{}) -> {ok, #httpdb{}, term()} | ignore. +initialize(#httpdb{} = HttpDb) -> + case remove_creds(HttpDb) of + {ok, User, Pass, HttpDb1} -> + case gen_server:start_link(?MODULE, [User, Pass, HttpDb1], []) of + {ok, Pid} -> + {ok, HttpDb1, {Pid, 0}}; + ignore -> + ignore; + {error, Error} -> + {error, Error} + end; + {error, missing_credentials} -> + ignore; + {error, Error} -> + {error, Error} + end. + + +-spec update_headers(term(), headers()) -> {headers(), term()}. +update_headers({Pid, Epoch}, Headers) -> + Args = {update_headers, Headers, Epoch}, + {Headers1, Epoch1} = gen_server:call(Pid, Args, infinity), Review comment: Because part of updating headers could be refreshing the cookie, which is an IO operation. Even if it calls during `process_response` gen_server could be talking to a session endpoint refreshing a cookie. HTTP requests inherit the timeout value used in the replication doc / config settings so those will be bounded by that. ---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services
