Hi,
I've been testing, and so far, there is no change in the behavior. I am
still getting the same tomcat-based 403 error.
Based on what you said above...
>
> secretRequired="true" (which is the default, so it can be removed)
> secret="xxxxxxx"
...I removed secretRequired="true" and left secret. So the connector
definition now looks like this:
<Connector protocol="AJP/1.3"
address="127.0.0.1"
port="8009"
secret="mySecret"
redirectPort="8443" />
I've also carefully checked the workers.properties and server.xml to be
sure that "mySecret" is exactly the same in both places, and that the
correct worker is mapped to that directory. The only difference is that
there are no quotes around the secret password in workers.properties.
I also tried adding secretRequired="false" - wouldn't that eliminate the
secret as an issue? But I still get the 403 error.
The only really odd thing - at least I think it is odd - is that the error
shows up in what I think is the wrong log. I set up logs for both hosts -
one is called localhost_access_log.2020-02-25.txt which is used for hits to
localhost, at least as I understand it. The
other, 127_0_01_access_log.2020-02-25.txt, should be used for the AJP
connector, but is empty. Here's a sample.
10.00.00.00 - - [25/Feb/2020:10:00:52 -0500] "GET
/exposedApplication/simple.html HTTP/1.1"
403 618
10.00.00.00 - - [25/Feb/2020:10:00:52 -0500] "GET
/exposedApplication/simple.html
HTTP/1.1" 403 618
10.00.00.00 - - [25/Feb/2020:10:46:24 -0500] "GET
//exposedApplication/simple.html HTTP/1.1"
403 618
One person requested a trace, but I'm not sure how to do that.
Thank you,
Ellen
On Mon, Feb 24, 2020 at 4:04 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Chris,
>
> On 2/24/20 15:53, Chris Cheshire wrote:
> > On Mon, Feb 24, 2020 at 3:19 PM Ellen Meiselman <elle...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> I’m having a lot of trouble configuring the isapi_redirect
> >> connector between IIS and Tomcat. I am running out of ideas so
> >> it’s time to ask for help from the experts. I think the problems
> >> remaining are in the tomcat configuration area, not the IIS area
> >> anymore.
> >>
> >> What’s wrong: The ISAPI module appears to be working and
> >> correctly sending AJP requests to Tomcat on port 8009, at which
> >> point Tomcat refuses those requests with a 403 error. The
> >> isapi_redirect.log shows the complete content of the tomcat
> >> response, and no longer shows any errors - in other words, it
> >> thinks it is working.
> >>
> >> Text of the 403 error:
> >>
> >> HTTP Status 403 – Forbidden Type Status Report Description The
> >> server understood the request but refuses to authorize it. Apache
> >> Tomcat/8.5.51
> >>
> >>
> >> What does work: Requests directly to Tomcat on port 8080 to pages
> >> within the connector-exposed web application work fine. For
> >> example, both of these work:
> >> localhost:8080/exposedApplication/simple.html. (viewed on the
> >> server’s browser)
> >> my.servers.domain.com:8080/exposedApplication/simple.html (viewed
> >> anywhere else)
> >>
> >>
> >> What does not work: Requests that go through IIS and the
> >> connector to the connector-exposed application result in a 403
> >> error. For example, this does not work:
> >> https:my.servers.domain.com/exposedApplication/simple.html
> >>
> >>
> >> This Windows 2019 setup has the following versions of tomcat,
> >> windows, etc:
> >>
> >> Tomcat version 8.5.51 Isapi_redirect.dll version 1.2.46.0 IIS
> >> 10/Windows server 2019
> >>
> >> I also have two older, similar Windows Server environments that
> >> work perfectly. They both use these versions:
> >>
> >> Tomcat version 8.5.3 (64 bit) as a service Isapi_redirect.dll
> >> version 1.2.40.0 64 bit IIS 8/Windows server 2012R2
> >>
> >>
> >> The component versions between the working and non-working
> >> environments are slightly different, and I think that might be
> >> the source of the problem - there are probably new configuration
> >> requirements that I need to be aware of. I started with the
> >> settings used in the working environments and found that some
> >> things needed to be changed to get the connector to work at alll.
> >> For example I had to specify an iPv4 address for the connector
> >> where I didn’t need to before.
> >>
> >> My theories at the moment: 1. Maybe
> >> allowedRequestAttributesPattern is a problem? I saw a note about
> >> the allowedRequestAttributesPattern attribute for the AJP
> >> connector possibly causing a 403 error, but I don’t understand
> >> how to use it or if it is needed. 2. It’s possible that something
> >> in the Tomcat permissions settings are wrong, but I really don’t
> >> know where to look.
> >>
> >>
> >> Relevant configuration settings in server.xml, workers.properties
> >> and uriworkermap.properties:
> >>
> >> server.xml
> >>
> >> <Connector port="8080" protocol="HTTP/1.1”
> >> connectionTimeout=“20000" redirectPort="8443" /> <Connector
> >> protocol="AJP/1.3” address=“127.0.0.1" port="8009"
> >> requiredSecret="true" secret=“xxxxxxxx" redirectPort="8443" />
> >>
> >> <Host name="localhost" appBase=“webapps" unpackWARs="true"
> >> autoDeploy="true"> <Valve
> >> className="org.apache.catalina.valves.AccessLogValve"
> >> directory="logs" prefix="localhost_access_log" suffix=".txt"
> >> pattern="%h %l %u %t "%r" %s %b" /> </Host>
> >>
> >> <Host name="127.0.0.1" appBase=“webapps” unpackWARs="true"
> >> autoDeploy="true"> <Valve
> >> className="org.apache.catalina.valves.AccessLogValve"
> >> directory="logs" prefix="127_0_01_access_log" suffix=".txt"
> >> pattern="%h %l %u %t "%r" %s %b" /> </Host>
> >>
> >>
> >> workers.properties
> >>
> >> # Set properties for worker1 (ajp13) worker.worker1.type=ajp13
> >> worker.worker1.host=127.0.0.1 worker.worker1.port=8009
> >> worker.worker1.secret=xxxxxxxx
> >>
> >>
> >> uriworkermap.properties /exposedApplication/*=worker1
> >>
> >>
> >> Any suggestions or new directions will be welcome.
> >>
> >> Thank you,
> >>
> >> Ellen Meiselman
> >>
> >
> > Change requiredSecret="true" to secretRequired="true" in your AJP
> > connector definition.
>
> +1
>
> These configuration attributes have names which are easily confused.
>
> In the past, "requiredSecret" was the name of the configuration
> property where the secret should have been set (e.g.
> requiredSecret="tiger"). In Tomcat 8.5.51, this configuration
> attribute changed to "secret" and the boolean "secretRequired"
> attribute was added. So you need:
>
> secretRequired="true" (which is the default, so it can be removed)
> secret="xxxxxxx"
>
> If you use requiredSecret="true" then it's very possible that the XML
> parser will fire these two events (in this order):
>
> 1: attribute [ name=secret value=xxxxx ]
> 2: attribute [ name=requiredSecret value=true ]
>
> With 8.5.51, requiredSecret is renamed "secret" but "requiredSecret"
> is still an alias of the same configuration property. If #2 happens
> after #1 above, then your actual secret will be the literal string
> "true" (oops).
>
> We apologize for this confusion. We are trying to clarify things and
> make them more secure.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5UOmYACgkQHPApP6U8
> pFgzwhAAmxSYGx/JPIpmc3B3eg1srq4W60bTeVwOMRs/tZHU1DBOkx6ZeMXArJv0
> 8g3kwkSxwvB/5QnygCyPt5iTyqGHk2EZqMPhrk36RPl/0jxmpy6YOttithr40gPz
> M+a3vcoM/daG90AUeExrp9v52eqCgvS5kpFm1hFfqpibLgSSVfhdv5ZwHa8Gyqu8
> rs3mZ6gNwE7Hz9dBFUOZ+cBF7LJ9vXC2nGAjhe1J1cLg29oBuhHWt1U2b/LNRrV1
> ggKZJ0PnILItIvkcovbFSN/M8sZfqf5ftnapH+IBw13T+CfbtUj+DkAh0yvCDP3Y
> eSp7d8zpnLoYHQbwwviqDvWKQLVmyZPMhD9sr28+EvOi0qItqLK287ri9QQHv8zP
> v+BUo5j2DDpxcOupQP1GqlCgNbeV7uaS+vfkb4C6y/GNWXrRcKB633JsyHVI8fGE
> Zs/wW10I6b9IqA1mBprieaoQCv3SZy9lgMeK+cEqbQo3619/dRbOkzeIjwEL//tB
> B+cQrkD7/Lvvgn9GD+vVBnCtX5sUSpkY/6o5iBSRq+NyOcgBeL37bhbNtCZrnEe2
> WqZQ+227RXPgXkF0b8XudamFOBKZmjNdRXPTC7USXQb/S20TRwEAcMhGW/kRWZwp
> H/KBrtdAtE156g8gp0+7QWOOqzWcRW8a9sE3jNUytlIiW0Eiu8U=
> =x1T4
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
