Hmm. Now it IS presenting a sign-on request, Re: Protecting files within a context

2017-08-28 Thread James H. H. Lampert
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

Re: Protecting files within a context

2017-08-25 Thread James H. H. Lampert
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

Re: Typo in my previous post, Re: Protecting files within a context

2017-08-25 Thread Christopher Schultz
-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

Re: Typo in my previous post, Re: Protecting files within a context

2017-08-24 Thread Bob Hall
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  

Re: Typo in my previous post, Re: Protecting files within a context

2017-08-24 Thread Bob Hall
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

Re: Typo in my previous post, Re: Protecting files within a context

2017-08-24 Thread James H. H. Lampert
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

Re: Typo in my previous post, Re: Protecting files within a context

2017-08-24 Thread Bob Hall
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: >> >>>      >> . . . >>>      >>>   

Typo in my previous post, Re: Protecting files within a context

2017-08-24 Thread James H. H. Lampert
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

Re: Protecting files within a context

2017-08-24 Thread James H. H. Lampert
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

Re: Protecting files within a context

2017-08-24 Thread Mark Thomas
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

Re: Protecting files within a context

2017-08-24 Thread Bob Hall
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

Re: Protecting files within a context

2017-08-24 Thread James H. H. Lampert
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

Re: Protecting files within a context

2017-08-24 Thread tomcat
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

Re: Protecting files within a context

2017-08-24 Thread Mark Thomas
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

Re: Protecting files within a context

2017-08-24 Thread James H. H. Lampert
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

Re: Protecting files within a context

2017-08-24 Thread Mark Thomas
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

Protecting files within a context

2017-08-24 Thread James H. H. Lampert
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