Mailing-List: contact issues-help@aurora.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.apache.org
Date: Mon, 8 Aug 2016 16:16:20 +0000 (UTC)
From: "Benjamin Staffin (JIRA)" <jira@apache.org>
To: issues@aurora.apache.org
Message-ID: <JIRA.12995694.1470672943000.250151.1470672980563@Atlassian.JIRA>
In-Reply-To: <JIRA.12995694.1470672943000@Atlassian.JIRA>
References: <JIRA.12995694.1470672943000@Atlassian.JIRA> <JIRA.12995694.1470672943435@arcas>
Subject: [jira] [Created] (AURORA-1746) Shiro authorization errors could be
 friendlier
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 08 Aug 2016 16:16:22 -0000

Benjamin Staffin created AURORA-1746:
----------------------------------------

             Summary: Shiro authorization errors could be friendlier
                 Key: AURORA-1746
                 URL: https://issues.apache.org/jira/browse/AURORA-1746
             Project: Aurora
          Issue Type: Story
          Components: Scheduler
            Reporter: Benjamin Staffin
            Priority: Minor


When the scheduler is configured to use Kerberos auth with shiro, the error messages it returns to clients are not as informative as they could be.  For example:

{code}
Subject org.apache.shiro.web.subject.support.WebDelegatingSubject@585fe96c is not permitted to JobScopedRpcPermission{rpc=startJobUpdate, permittedJob=IJobKey{role=foo, environment=devel, name=fancyjob}}
{code}

It would be very nice if the message masked the {{org.apache.shiro.web.subject[...]}} class name and either (a) listed the actual subject/principal name of the client ({{username@SOME.REALM}}), or (b) generically referred to "the client".

I would also suggest using the term "authorized" rather than "permitted".  This is probably debatable, and the semantic difference is minimal, but to me the former more directly hints at a thing that can be configured, whereas the current message might be misinterpreted to mean something that cannot be done at all.

For bonus points, also rewrite the {{JobScopedRpcPermission}} part of the message to be friendlier.  That part at least includes enough details that an informed user could figure out what it means after staring at it a bit.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)