On Tue, Dec 15, 2015 at 09:37:45AM +0200, Violeta Georgieva wrote:
>Hello,
>
>2015-12-15 4:35 GMT+02:00 Baron Fujimoto <ba...@hawaii.edu>:
>>
>> On Mon, Dec 14, 2015 at 09:12:20PM +0000, Mark Thomas wrote:
>> >On 14/12/2015 20:49, Baron Fujimoto wrote:
>> >> On Fri, Dec 11, 2015 at 05:02:43PM -1000, Baron Fujimoto wrote:
>> >>> On Sat, Dec 12, 2015 at 12:16:01AM +0000, Mark Thomas wrote:
>> >
>> ><snip/>
>> >
>> >>> I've confirmed that the problem begins with 8.0.29.
>> >
>> >Looking through the changelog it is hard to see how any of the changes
>> >not in the Catalina section could trigger this. So, focussing on that
>> >section...
>> >
>> >>>> If you can find out how the CSRF protection is adding the token then
>> >>>> that will also help since it gives an idea of what to look for in the
>> >>>> changelog.
>> >>>
>> >>> I believe it's done using the OWASP CSRFGuard Project, and I have the
>> >>> property files generated by the Grouper devs that define its
>> >>> configuration. I'll query the Grouper folks to confirm and see if they
>> >>> can provide a relevant and succinct explanation about this in
>particular.
>> >>
>> >> The Grouper devs explain, "Javascript sets an HTTP header called
>> >> OWASP_CSRFTOKEN: on requests (some excluded per properties file)".
>> >
>> >That doesn't explain how/where the token is generated or what component
>> >validates it server side. I'm guessing a Filter does the validation.
>> >
>> >> Per the properties file, I believe the following are excluded:
>> >>
>> >> org.owasp.csrfguard.unprotected.Default=%servletContext%/
>> >
>> >Hmm. This first one combined with the last entry in the Catalina section
>> >of the 8.0.29 changelog look like a possibility.
>> >
>> >Try each of the following (one at a time, not together) to see if they
>> >fix it:
>>
>> Neither of these, tried independently, appeared to have any effect.
>>
>> >a) Add the following (note the lack of trailing slash) to the properties
>> >file:
>> >
>> >org.owasp.csrfguard.unprotected.Upload=%servletContext%
>>
>> I tried this as described, but since I wasn't sure if you really meant the
>> .Default property I also tried that, just in case (separate tests,
>> performed independently). I tried both by adding the suggested definitions
>> after their original definitions (in case they superceded them) and by
>> replacing the original definitions.
>>
>>
>> >b) Set mapperContextRootRedirectEnabled="true" and
>> >mapperDirectoryRedirectEnabled="true" on the Context in
>> >$CATALINA_BASE/conf/context.xml
>>
>> The resulting $CATALINA_BASE/conf/context.xml was:
>>
>> <Context>
>> <WatchedResource>WEB-INF/web.xml</WatchedResource>
>> <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
>>
>> mapperContextRootRedirectEnabled="true"
>> mapperDirectoryRedirectEnabled="true"
>> </Context>
>
>mapperContextRootRedirectEnabled and
>mapperDirectoryRedirectEnabled
>
>are attributes of the Context so your context.xml should look like the one
>below:
>
><Context mapperContextRootRedirectEnabled="true"
>mapperDirectoryRedirectEnabled="true">
> <WatchedResource>WEB-INF/web.xml</WatchedResource>
> <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
></Context>
>
>Regards,
>Violeta
That works! Mahalo for correcting the context.xml syntax. This workaround
will allow us to stay current with the latest Tomcat release. Is this
expected to be the default behavior going forward?
Aloha,
-baron
>> >>
>> >> [...]
--
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
