Re: how to prevent user access to JSP pages?

[Terence M. Bandoian]

On 8/23/2018 4:26 AM, Mark Thomas wrote:

On 22/08/18 19:48, Terence M. Bandoian wrote:




Back on topic, do JSPs have to be registered with the container using
servlet mappings in web.xml or some other mechanism in order to serve as
targets of forwards by servlets?  Further, does doing so make those JSPs
accessible via external requests?  I suspect the answer to both
questions is yes which means an additional mechanism will have to be
introduced to block that access which I believe was the original
question.  Servlet filter?

What makes JSPs accessible is the mapping of *.jsp to the JSP servlet.
Any file outside of WEB-INF with a .jsp extension will be passed to the
JSP servlet for processing:
- .jsp -> .java
- .java -> .class (servlet)
- send request to servlet from previous step

JSPs (or any other files) located under WEB-INF are never directly
accessible.

Forwards and includes can reference JSP files (actually any files)
located under WEB-INF and the file is processed the same way it would be
if it were located outside of WEB-INF. The idea of locating files under
WEB-INF is so you can use them in forwards and includes without them
being directly accessible.

Mark

P.S. It is actually WEB-INF or META_INF everywhere I write WEB-INF above
but I only used WEB-INF to try and keep it clearer.



Thanks for clearing that up.  It's surprisingly simple.  The only 
complication I found is that a "NamedDispatcher" is required to forward 
to pre-compiled JSPs in WEB-INF that don't have servlet mappings.


-Terence Bandoian


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

Re: [OT] What can prevent sessions from timeouting apart from real requests

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Leon,

On 8/24/18 05:25, Leon Rosenberg wrote:
> one of the systems we are consulting has encountered a strange
> problem. The sessions will build up indefinitely but never expire.
> Then, at one point (at 02am in the night, 19K sessions would drop
> at once). Of course the simplest explanation would be that someone
> is actively requests something every 15 minutes (session timeout)
> keeping track of the JSESSIONID. We are trying to track this
> through the access_log and such. However, my question, is it
> possible to prevent session from timeouting by doing something
> stupid code-wise? Like storing a session in a hashmap somewhere,
> and accessing some attributes from time to time? My understanding
> was that the session timeout is solely dependent on incoming 
> requests and handled by the container, but I was not 100% sure ;-)

A few ideas:

1. The background thread has died. Probably not, as the sessions
eventually expire... just way later than expected. Also, the
background thread would not be running anymore, which I think you
would have noticed.

2. Some process has blocked the background thread. For example, a very
long-running HttpSessionListener.sessionDestroyed method. I'm guessing
you would have already noticed a stuck background thread, though.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluDPOYACgkQHPApP6U8
pFjOJw/8CGIxOEEWKd1rk28PcErF6LPvDBQLVTECO+miQt8SoJPzuwpICnX/mPut
IliUdiPTSPplb7CHr1vsMfLGrVxOo1fD7xuQ22lMVFD8B23pe6WXwTreUnzJouDw
pO9rV2mhjc6x1OaE29iCyFqbCNsswANdRcLrFAkAkdDc/ZlY1tw4VrnXPKG+uaQD
sJP1lei0poek5ZOvMvG87JMC8Pe7veuUSKvO1c1q+NL3MAuI/XZWTaiJ7SRSj8JW
m2paNQX+9/neHZZ0mOAuAjXTqllLGnThQTNCyaqqtXtqk4TftHYp5Tz9hBhXSXh3
+gEzbPMp5m5tWXCpdrXIFqqEArDgUpWpNGijgmMhE9e+eTYvEuadA+rMIeOr4IVO
CI2QQCVzZ2vOqMd9Xa/ii0gyOjjZMYUf7qxLqBxZ6NxIFnXr+MJXBGVuFe5hvsdX
hcAuzkTy9rt6pgAO6O+5YUD7d6KRCjg4bHP1614bcZgsPiwNT98ECJq22FhiEDFF
l8zb7svG56qWFvsIkXAGVKSC5FT8NO9XFS9soMfIxZi0GVQS9z6qRbNDoKeO6gfI
e9S+Rd7a/kogTODSBsoGl1pK/5DLF1uPLyE0HLHnvfFTgnvPU0hJy94xDQ9tiAA9
iCA9EaIak3nxy/7qAONpgEghkXHplk94ObGzZ3qj3TW0x7h4uMk=
=3Wbc
-END PGP SIGNATURE-

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

Re: org.apache.tomcat.jdbc.pool casting to original connection class

[Alex O'Ree]

Perfect, thanks

On Fri, Aug 24, 2018, 5:05 PM Torsten Krah  wrote:

> The isWrapperFor(..) and unwrap(..) methods on the connection API should
> work for this.
>