From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 10AC7452566 for ; Mon, 4 Nov 2019 18:40:12 +0300 (MSK) Received: by mail-pg1-f181.google.com with SMTP id s23so8140467pgo.9 for ; Mon, 04 Nov 2019 07:40:12 -0800 (PST) Date: Mon, 4 Nov 2019 18:40:07 +0300 From: Konstantin Osipov Message-ID: <20191104154007.GA29244@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH 1/1] replication: use empty password by default List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org * Vladislav Shpilevoy [19/11/04 18:21]: > Replication's applier encoded an auth request with exactly the > same parameters as extracted by the URI parser. I.e. when no > password was specified, the parser returned it as NULL, and it was > not encoded. The relay, received such an auth request, complained > that IPROTO_TUPLE field is not specified (this is password). > > Such an error confuses - a user didn't do anything illegal, he > just used URI like 'login@host:port', without a password after the > login. > > The patch makes the applier use an empty string as a default > password. > > An alternative was to force a user always set a password even if > it is an empty string, like that: 'login:@host:port'. And if a > password was not found in an auth request, then reject it with a > password mismatch error. But in that case a URI of kind > 'login@host:port' becomes useless - it can never pass. In > addition, netbox already uses an empty string as a default > password. So the only way to make it consistent, and don't break > anything - repeat netbox logic for replication URIs. LGTM. Obviously this is a crutch, but let's see if it is a useful one. -- Konstantin Osipov, Moscow, Russia