Hmm. Since the last time I tried this, the Tomcat server on which I'm
testing my security constraint, login-config, and security-role has been
shut down and restarted (Friday evening at 10:30 PM.
And now, it IS presenting a sign-on request. Of course, since there was
no user with a "frobozz" r
On 8/24/17, 5:52 PM, Bob Hall wrote:
On Thursday, August 24, 2017 5:48 PM, Bob Hall wrote:
Yahoo auto-munged the URL, it should be:
https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html
I just read it (after spending the better part of the day putting the
preliminary version of the fix, w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 8/24/17 8:28 PM, James H. H. Lampert wrote:
> On 8/24/17, 5:18 PM, Bob Hall wrote:
>> If you successfully logged in previously, I suggest you check
>> your browser for any cookies that were created at that time. You
>> will probably need
On Thursday, August 24, 2017 5:48 PM, Bob Hall wrote:
Yahoo auto-munged the URL, it should be:
https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html
- Bob
On Thursday, August 24, 2017 5:29 PM, James H. H. Lampert
wrote:
> Cache and cookies both cleared, all the way back, and the context
> that theoretically should be presenting a sign-on dialog for the
> forbidden pages still serves an immediate 403 page instead.
I don't use Tomcat's Rea
On 8/24/17, 5:18 PM, Bob Hall wrote:
If you successfully logged in previously, I suggest you check your browser for
any cookies that were created at that time. You will probably need to remove
them before the login challenge will be presented.
- Bob
Well, I can try explicitly clearing cookie
James,
On Thursday, August 24, 2017 4:58 PM, James H. H. Lampert
wrote:
>> This is interesting:
>>
>> I added this (contents of web-resource-collection omitted) to the top of
>> the context's web.inf, right below the "web-app" and "display-name" tags:
>>
>>>
>> . . .
>>>
>>>
On 8/24/17, 4:29 PM, I wrote:
This is interesting:
I added this (contents of web-resource-collection omitted) to the top of
the context's web.inf, right below the "web-app" and "display-name" tags:
. . .
. . .
Of course, I meant to say, ". . . the context's WEB-INF/web.x
This is interesting:
I added this (contents of web-resource-collection omitted) to the top of
the context's web.inf, right below the "web-app" and "display-name" tags:
. . .
and restarted the context, and as advertised, all requests for anything
that matched the url-pa
On 24/08/17 22:26, James H. H. Lampert wrote:
> On 8/24/17, 12:52 PM, Mark Thomas wrote:
>> I can't recommend reading chapter 13 of the servlet spec, particularly
>> section 13.8, enough.
>
> Thanks again.
>
> Could you be a bit more specific on what edition of the servlet spec,
> and where I can
James,
On Thursday, August 24, 2017 2:26 PM, James H. H. Lampert
wrote:
> Could you be a bit more specific on what edition of the servlet spec,
and where I can find it?
> The first one I grabbed ("Java Servlet Specification Version 2.4") is
over a decade old, and doesn't *have* a secti
On 8/24/17, 12:52 PM, Mark Thomas wrote:
I can't recommend reading chapter 13 of the servlet spec, particularly
section 13.8, enough.
Thanks again.
Could you be a bit more specific on what edition of the servlet spec,
and where I can find it?
The first one I grabbed ("Java Servlet Specifica
On 24.08.2017 21:43, James H. H. Lampert wrote:
On 8/24/17, 11:35 AM, Mark Thomas wrote:
Tomcat will prevent access to anything in WEB-INF or META_INF.
Everything else is up to the app to control.
Note: You can place content in WEB-INF and include it from JSPs and
Servlets (and it will work) b
On 24/08/17 20:43, James H. H. Lampert wrote:
> On 8/24/17, 11:35 AM, Mark Thomas wrote:
>
>> Tomcat will prevent access to anything in WEB-INF or META_INF.
>> Everything else is up to the app to control.
>>
>> Note: You can place content in WEB-INF and include it from JSPs and
>> Servlets (and it
On 8/24/17, 11:35 AM, Mark Thomas wrote:
Tomcat will prevent access to anything in WEB-INF or META_INF.
Everything else is up to the app to control.
Note: You can place content in WEB-INF and include it from JSPs and
Servlets (and it will work) but direct access will not.
You might want to tak
On 24/08/17 19:29, James H. H. Lampert wrote:
> I've just discovered that a number of files within our webapp context
> are reachable from outside. Not all of them, but a number that really
> shouldn't be.
>
> By its nature, the webapp itself has its own access control, based on
> the outside reso
I've just discovered that a number of files within our webapp context
are reachable from outside. Not all of them, but a number that really
shouldn't be.
By its nature, the webapp itself has its own access control, based on
the outside resource it accesses, rather than on, say, tomcat-users.xm
17 matches
Mail list logo