On 8/24/17, 5:52 PM, Bob Hall wrote:
On Thursday, August 24, 2017 5:48 PM, Bob Hall <rfha...@yahoo.com> wrote:
Yahoo auto-munged the URL, it should be:

I just read it (after spending the better part of the day putting the preliminary version of the fix, without even a commented-out way to allow password access to the forbidden data, into over a dozen self-hosted customer installations).

But I think I may be heading down a blind alley here, involving two different usages of the word "realm" that don't appear to have anything to do with each other: on the one hand, the document defines a "realm" as a database of user-IDs and passwords, while on the other hand, a "realm-name" seems to be what gets returned to the browser in a "WWW-Authenticate" response header.
WWW-Authenticate:Basic realm="Tomcat Manager Application"

On 8/25/17, 6:14 AM, Christopher Schultz wrote:
Just for grins, make another request and use your browser's dev
tools to inspect the HTTP request headers. If there is an
"Authorization" header. If it's there, it's likely keeping you logged
in, and so a 403 is appropriate for your situation (required role:
frobozz, user's current roles: [not frobozz]).

I just tried that. The first time I visit "manager" in a browser session, it gives the aforementioned "WWW-Authenticate" response header, and then both when I entered the acceptable user-ID and password, and later when I returned to "manager," it sent an "Authorization" header with the request. But I visited the forbidden page both before and after signing on to "manager," and at no time was any "Authorization" header sent with the request.

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to