Return-Path: X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AF24B10E1A for ; Fri, 19 Jul 2013 01:03:46 +0000 (UTC) Received: (qmail 36932 invoked by uid 500); 19 Jul 2013 01:03:46 -0000 Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org Received: (qmail 36902 invoked by uid 500); 19 Jul 2013 01:03:46 -0000 Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@apache.org Delivered-To: mailing list notifications@accumulo.apache.org Received: (qmail 36893 invoked by uid 99); 19 Jul 2013 01:03:46 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Jul 2013 01:03:46 +0000 Date: Fri, 19 Jul 2013 01:03:46 +0000 (UTC) From: "Christopher Tubbs (JIRA)" To: notifications@accumulo.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ACCUMULO-1578) Connector constructor doesn't need to fail-fast (maybe?) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ACCUMULO-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13713217#comment-13713217 ] Christopher Tubbs commented on ACCUMULO-1578: --------------------------------------------- I think we've had enough issues with too many getConnector methods on Instance (I'm assuming that's what you meant by "connector constructor"). I'm not a fan of that option, because the main reason I want to do this is to *simplify* some code that no longer reflects our assumptions... adding new code to maintain and support long-term is the opposite of my goal here. I think changing this behavior between "major" versions (between 1.5 and 1.6), is acceptable, but am willing to concede by leaving it unchanged (not by adding new code) if it is considered too disruptive. For the shell, we can simply call conn.securityOperations().authenticateUser() after creating a connector (actually, any RPC "get" operation would do the trick, and the shell already does some, but we can make it explicit anyway). > Connector constructor doesn't need to fail-fast (maybe?) > -------------------------------------------------------- > > Key: ACCUMULO-1578 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1578 > Project: Accumulo > Issue Type: Task > Reporter: Christopher Tubbs > Assignee: Christopher Tubbs > Fix For: 1.6.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Currently, when one instantiates a Connector from an Instance, with one's username and token, the Connector actually tries to reach out and authenticate those credentials, to provide early failure. > Because this has some overhead, we explicitly check for the condition that the user is a system user (a tserver or the monitor, etc.), so that we don't fail early in these conditions (because we don't expect the system to be poorly configured or running in a bad state, such that it doesn't authenticate... and we don't care about causing an inconvenience to unauthorized servers by failing late). > After some thought, I'm not sure that we should continue to fail fast. I'm not sure that it provides sufficient convenience for users to warrant the additional RPC calls. Besides, there's no guarantee, especially with the new pluggable authentication introduced in 1.5.0, that the credentials will still be valid later, even if the user were able to authenticate initially. > As such, I propose we drop this check, and rely on authentication failures later (when work is actually initiated). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira