Re: context resources, replacement parameters

2017-12-11 Thread Mark Thomas
On 11/12/17 19:12, Chris Cheshire wrote:
> I thought more about this over the weekend, and realised it is more
> hassle than it is worth, and not because I don't want to do it. I
> don't think it is actually feasible now that I think about it more.
> 
> Given that a JVM has one set of System.properties and one instance of
> Tomcat can have multiple deployed contexts, I can't just inject a
> single property. It would have to be mapped to some other value unique
> to the context. Thus it is starting to look more like a "tail wagging
> the dog" exercise, when I should just accept editing the config files
> manually for now until I can get around to figuring ant out and
> building them dynamically.

Happy to park this if you want but I think it should be possible for
Tomcat to inject a property (e.g. org.apache.tomcat.contextPath) with
the correct value for the current context. i.e. you use that value
everywhere and Tomcat ensures that the replacement value is correct for
each context.

Feel free to create a Bugzilla issue for this if you think it could be
helpful.

Mark


> 
> On Sat, Dec 9, 2017 at 11:19 AM, Mark Thomas  wrote:
>> On 08/12/17 22:13, Chris Cheshire wrote:
>>> On Fri, Dec 8, 2017 at 3:36 PM, Mark Thomas  wrote:
 On 08/12/17 18:49, Chris Cheshire wrote:
> I have a directory resource set defined in my context.xml to handle 
> images :
>
> 
>    className="org.apache.catalina.webresources.DirResourceSet"
> base="${catalina.base}/cdn/p/images"
> webAppMount="/images" />
> 
>
> The /p in there actually represents the context path - a given sandbox
> might have the same webapp deployed at different context paths
> representing different development branches. Is it possible to use a
> replacement parameter similar to catalina.base to replace the context
> path the webapp is deployed at?

 Yes. You can use ant style property replacement in any XML file that is
 processed by the digester (server.xml, context.xml, web.xml)

 See the opening section of

 http://tomcat.apache.org/tomcat-9.0-doc/config/index.html

 for details.

 Mark

>>>
>>> I logged the System properties and there is nothing in there for the
>>> context path.
>>
>> Sorry, I didn't quite understand what you were asking. This isn't
>> possible out of the box.
>>
>> Injecting a special property (org.apache.tomcat.contextPath ?) should be
>> doable when working with context specific configuration files -
>> context.xml and web.xml - although there might be some edge cases with
>> context.xml since sometimes the context path is set in the file. I think
>> they can be handled with some documentation.
>>
>> Care to create an enhancement request? Better still, how do you fancy
>> taking a stab at a patch? We can give you some pointers to get started
>> if required.
>>
>> Mark
>>
>>
>>>
>>> In catalina logs I see
>>>
>>> 08-Dec-2017 22:02:05.532 INFO [ajp-nio-8019-exec-1]
>>> org.apache.catalina.core.ApplicationContext.log HTMLManager: restart:
>>> Reloading web application '/p'
>>> 08-Dec-2017 22:02:05.533 INFO [ajp-nio-8019-exec-1]
>>> org.apache.catalina.core.StandardContext.reload Reloading Context with
>>> name [/p] has started
>>> 08-Dec-2017 22:02:14.596 INFO [ajp-nio-8019-exec-1]
>>> org.apache.catalina.core.StandardContext.reload Reloading Context with
>>> name [/p] is completed
>>>
>>> It seems catalina knows the value of the context path for the webapp
>>> when context.xml is being digested. Should I post an RFE on BZ to have
>>> it added to the system properties, or am I incorrect in this
>>> assumption?
>>>
>>>
>>>

>
> I tried following the source through for DirResourceSet but couldn't
> see where even catalina.base is getting replaced.
>
> (I know ant is a solution and I eventually need it for other things
> too, but I have never used it and it's not a learning rabbit-hole I
> can go down right now)
>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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



Re: context resources, replacement parameters

2017-12-11 Thread Chris Cheshire
I thought more about this over the weekend, and realised it is more
hassle than it is worth, and not because I don't want to do it. I
don't think it is actually feasible now that I think about it more.

Given that a JVM has one set of System.properties and one instance of
Tomcat can have multiple deployed contexts, I can't just inject a
single property. It would have to be mapped to some other value unique
to the context. Thus it is starting to look more like a "tail wagging
the dog" exercise, when I should just accept editing the config files
manually for now until I can get around to figuring ant out and
building them dynamically.

On Sat, Dec 9, 2017 at 11:19 AM, Mark Thomas  wrote:
> On 08/12/17 22:13, Chris Cheshire wrote:
>> On Fri, Dec 8, 2017 at 3:36 PM, Mark Thomas  wrote:
>>> On 08/12/17 18:49, Chris Cheshire wrote:
 I have a directory resource set defined in my context.xml to handle images 
 :

 
   >>> base="${catalina.base}/cdn/p/images"
 webAppMount="/images" />
 

 The /p in there actually represents the context path - a given sandbox
 might have the same webapp deployed at different context paths
 representing different development branches. Is it possible to use a
 replacement parameter similar to catalina.base to replace the context
 path the webapp is deployed at?
>>>
>>> Yes. You can use ant style property replacement in any XML file that is
>>> processed by the digester (server.xml, context.xml, web.xml)
>>>
>>> See the opening section of
>>>
>>> http://tomcat.apache.org/tomcat-9.0-doc/config/index.html
>>>
>>> for details.
>>>
>>> Mark
>>>
>>
>> I logged the System properties and there is nothing in there for the
>> context path.
>
> Sorry, I didn't quite understand what you were asking. This isn't
> possible out of the box.
>
> Injecting a special property (org.apache.tomcat.contextPath ?) should be
> doable when working with context specific configuration files -
> context.xml and web.xml - although there might be some edge cases with
> context.xml since sometimes the context path is set in the file. I think
> they can be handled with some documentation.
>
> Care to create an enhancement request? Better still, how do you fancy
> taking a stab at a patch? We can give you some pointers to get started
> if required.
>
> Mark
>
>
>>
>> In catalina logs I see
>>
>> 08-Dec-2017 22:02:05.532 INFO [ajp-nio-8019-exec-1]
>> org.apache.catalina.core.ApplicationContext.log HTMLManager: restart:
>> Reloading web application '/p'
>> 08-Dec-2017 22:02:05.533 INFO [ajp-nio-8019-exec-1]
>> org.apache.catalina.core.StandardContext.reload Reloading Context with
>> name [/p] has started
>> 08-Dec-2017 22:02:14.596 INFO [ajp-nio-8019-exec-1]
>> org.apache.catalina.core.StandardContext.reload Reloading Context with
>> name [/p] is completed
>>
>> It seems catalina knows the value of the context path for the webapp
>> when context.xml is being digested. Should I post an RFE on BZ to have
>> it added to the system properties, or am I incorrect in this
>> assumption?
>>
>>
>>
>>>

 I tried following the source through for DirResourceSet but couldn't
 see where even catalina.base is getting replaced.

 (I know ant is a solution and I eventually need it for other things
 too, but I have never used it and it's not a learning rabbit-hole I
 can go down right now)

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

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



Re: Get IP address in Realm

2017-12-11 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 12/10/17 3:11 PM, Mark Thomas wrote:
> On 09/12/17 19:41, Christopher Schultz wrote:
> 
> 
> 
>> If there is any appetite for such a thing in Tomcat, I'd be happy
>> to propose a change to bring e.g. an AuthenticationListener
>> interface which could listen for events of this type and include
>> information such as username, IP address, and possibly other
>> useful information.
> 
> I think this is a specific case of this more general request:
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

+1

> Now is a good time to implement that, before 9.0.x becomes final
> and the API is (mostly) fixed.
> 
> There are a couple of different ways of doing this, depending on
> how backwards compatible we want to be. I'm currently leaning
> towards:
> 
> - add new methods to Realm (duplicate existing authentication
> methods and add HttpServlet)
> 
> - implement the new methods in RealmBase that simply defaulted to 
> calling the old methods minus the HttpServlet
Securityfilter basically provided an interface that included the
HttpServletRequest, and if the "Realm" implemented that interface, the
more-specific method was called instead of e.g.
authenticate(String,String).

I'm not sure which is faster: an "instanceof" check or a dispatch to a
method which re-dispatches to another method. I'd guess they are
roughly equivalent and the performance difference doesn't matter much.
It's much more of an architectural decision.

I have to say that I'm not super-happy with using HttpServletRequest
for that purpose (because it then ties Tomcat Realms to HTTP) but,
honestly, when are these realms going to be used outside the context
of Tomcat, where HTTP is the primary protocol to be serviced?

> Then custom Realms could extend RealmBase, override those methods
> and gain access to the additional info.
> 
> It isn't the only option. Is there a
> 
> It is TBD if we deprecate the old methods. Maybe deprecate in 9.0.x
> with a view to dropping in 10.0.x

I see no need to deprecate the old methods, especially if we provide a
default implementation that merely passed-through to the old
authenticate() method(s).

As for custom Realms, I'm more interested in obtaining the IP address
of the user attempting to authenticate *without* having to implement
my own custom realm. This was the whole point of the CredentialHandler
interface: to allow users to implement the smallest part of the
process in a custom way. I'd like to do the same for IP-address
handling... there's no particular reason why a user should have to
subclass + re-implement a bunch of (admittedly, mostly delegate)
methods just to record failed logins from a particular IP address.

What do you think about a Listener interface for login success/failure?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlouraQACgkQHPApP6U8
pFhAnRAAv3TtegBG0jTXE1Gfh/UDJRJE3uBRm1tBwdrjGpO8ObVrJDqb9JaDQqVL
EA2hqJ4wrkDb2SPcZBclCrHWF+5nrTJRINLsI8nsx4LSVlPzsZihACMks18tYxyx
HA3l3GYiHnD2ULboU6bnh9a8mtCCDVDNSPVYfN+yeGREkbPvYgtv2rmr2N7b32/A
s8ziGsbB2N7KnPsALXJUzlNAu6x26laFqlX1cN/irmBRhLP4/wIB+X5pPdxnDvna
aVbZH137dvb7Whlrt3oMCBqLKGw4u+kh25UIhbKfyjRO1DPQRIaSy9ozUpqtgLfG
CwEn8ac/xuULVDz+DuMjGFJr1OUOYXUsfvATJzxU+swVqSc4Yjj52+v+wunPe9ag
wj6TMAGY0Gcmju5AOet/AvRTsZf5J/ar+MYnvga3py10m6mIlDJZG7TkIZfR0xvB
u69yNcHOMdfF5kQMc4ONhGo29q4w+0apKw/4Mxhe6oF72ybr+QNQGFUEGlWKKJmV
q8b2QJFkl+hDEYb83D+Sn5yFK8dqecR6aOTUuCeoa+DYbRRw3FgHqqvDzvl3Z0ci
qnrwzyc3c7viJStEKAE+4ILqKFgowZSaaB2RQjSoEQcOAUXYL3zAjR26MwEY0n15
ZucvDwdB6Hc5kiBllEBNt/ugARb/IV1IVUa9xBf9E+mXq3OkIaw=
=Z4Ym
-END PGP SIGNATURE-

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



Re: Apache tomcat 7.0.82 RFC issue (UNCLASSIFIED)

2017-12-11 Thread Mark Thomas
On 11 December 2017 14:34:01 GMT+00:00, "Lueders, Paul T CIV USARMY NGIC (US)" 
 wrote:
>CLASSIFICATION: UNCLASSIFIED
>
>I am running Apache tomcat 7.0.82.  It is not running behind any other
>web server.  I am getting:
>Java.lang.IllegalArgumentException: Invalid Character found in the
>request target.  The valid characters are defined in RFC 7230 and RFC
>3986
>
>How can I correct this in the tomcat configuration files?

That might not be possible.

Which illegal character (s) are the broken clients  sending?

Mark

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



Re: Apache tomcat 7.0.82 RFC issue (UNCLASSIFIED)

2017-12-11 Thread Coty Sutherland
On Mon, Dec 11, 2017 at 9:34 AM, Lueders, Paul T CIV USARMY NGIC (US)
 wrote:
> CLASSIFICATION: UNCLASSIFIED
>
> I am running Apache tomcat 7.0.82.  It is not running behind any other web 
> server.  I am getting:
> Java.lang.IllegalArgumentException: Invalid Character found in the request 
> target.  The valid characters are defined in RFC 7230 and RFC 3986

The problem is that your clients are sending unencoded characters
which are not allowed by the spec. See
https://bz.apache.org/bugzilla/show_bug.cgi?id=60594 or search the
users list archives for 'RFC 7230' or 'RFC 3986' for more information.

> How can I correct this in the tomcat configuration files?

Search for 'tomcat.util.http.parser.HttpParser.requestTargetAllow' in
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html to see
what options are available. Presently you can allow {, }, and | but
other characters will still yield a 400 response.

> Thanks a lot,
>
> Paul Lueders
> CLASSIFICATION: UNCLASSIFIED
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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



Apache tomcat 7.0.82 RFC issue (UNCLASSIFIED)

2017-12-11 Thread Lueders, Paul T CIV USARMY NGIC (US)
CLASSIFICATION: UNCLASSIFIED

I am running Apache tomcat 7.0.82.  It is not running behind any other web 
server.  I am getting:
Java.lang.IllegalArgumentException: Invalid Character found in the request 
target.  The valid characters are defined in RFC 7230 and RFC 3986

How can I correct this in the tomcat configuration files?

Thanks a lot,

Paul Lueders
CLASSIFICATION: UNCLASSIFIED

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