-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 2/4/16 6:27 AM, André Warnier (tomcat) wrote: > On 03.02.2016 22:17, Christopher Schultz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> André, >> >> On 2/3/16 1:50 PM, André Warnier (tomcat) wrote: >>> On 03.02.2016 19:07, David kerber wrote: >>>> On 2/3/2016 12:50 PM, prashant sharma wrote: >>>>> On 3 Feb 2016 17:42, "David kerber" <dcker...@verizon.net> >>>>> wrote: >>>>>> >>>>>> On 2/3/2016 12:23 PM, prashant sharma wrote: >>>>>>> >>>>>>> On 3 Feb 2016 16:38, "Mark Eggers" >>>>>>> <its_toas...@yahoo.com.invalid> wrote: >>>>>>>> >>>>>>>> >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>>> >>>>>>>> Quick note - please post at the bottom or inline. >>>>>>>> >>>>>>>> See item 6 of the Tomcat users mailing list here: >>>>>>>> http://tomcat.apache.org/lists.html >>>>>>>> >>>>>>>> On 2/3/2016 8:20 AM, prashant sharma wrote: >>>>>>>>> >>>>>>>>> That's true. But we are not doing any authn/authz >>>>>>>>> in our application. Its just a simple webapp that >>>>>>>>> exposes 1 endpoint (put method). Any body should be >>>>>>>>> able to hit that end point. >>>>>>>>> >>>>>>>>> It works fine if I place my war outside tomcat >>>>>>>>> installation directory and create a context from >>>>>>>>> Catalina/localhost. But if I place my war inside >>>>>>>>> webapps then it gives http 403 when I hit my >>>>>>>>> endpoint. >>>>>>>>> >>>>>>>>> Regards, Prashant >>>>>>>>> >>>>>>>>> 07440456543 On 3 Feb 2016 16:11, "David kerber" >>>>>>>>> <dcker...@verizon.net> wrote: >>>>>>>>> >>>>>>>>>> 403 is an authentication/authorization error, >>>>>>>>>> which means the logged-in user doesn't have >>>>>>>>>> permissions to the requested resource. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/3/2016 11:05 AM, prashant sharma wrote: >>>>>>>>>> >>>>>>>>>>> Hi, Can someone pls provide any inputs on >>>>>>>>>>> below. Thanks >>>>>>>>>>> >>>>>>>>>>> Regards, Prashant >>>>>>>>>>> >>>>>>>>>>> 07440456543 On 2 Feb 2016 18:02, "prashant >>>>>>>>>>> sharma" <pacificmist.0...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I am using apache tomcat 7.0.57 and jdk 7 on >>>>>>>>>>>> windows 7. I have deployed a simple web >>>>>>>>>>>> application inside tomcat webapps folder by >>>>>>>>>>>> placing the war file directly in webapps. >>>>>>>>>>>> This is a basic application which exposes an >>>>>>>>>>>> endpoint with put request method. >>>>>>>>>>>> >>>>>>>>>>>> When I try to access this endpoint I get 403 >>>>>>>>>>>> access forbidden error. >>>>>>>>>>>> >>>>>>>>>>>> However If I place war file outside tomcat >>>>>>>>>>>> and point it by creating context.xml in >>>>>>>>>>>> conf/Catalina/localhost I am able to access >>>>>>>>>>>> my endpoint. >>>>>>>>>>>> >>>>>>>>>>>> Can someone pls tell what's wrong with the >>>>>>>>>>>> first approach and why its not working in >>>>>>>>>>>> that >>>>>>>>>>>> >>>>>>>>>>>> Regards, Prashant >>>>>>>>>>>> >>>>>>>>>>>> 07440456543 >>>>>>>> >>>>>>>> >>>>>>>> With your put method, are you trying to write to a >>>>>>>> file within the web application? >>>>>>>> >>>>>>>> . . . just my two cents >>>>>>> >>>>>>> This put method updates a record in database. The same >>>>>>> webapp(endpoint) works when I place war outside >>>>>>> tomcat. >>>>>> >>>>>> >>>>>> Check the permissions on the directories where you are >>>>>> placing the .war >>>>> file. .war file is places under tomcat webapps folder. >>>> >>>> Yes, I know. You need to check the permissions that are set >>>> on that directory. >>>> >>> >>> If that is really what is happening, maybe some warnings are >>> in order here : 1) from a security point of view, it does not >>> seem to me a very good idea to allow a PUT to add (or >>> overwrite) files in the webapps directory. What if someone uses >>> this to upload a malicious webapp there ? >> >> Re-read his post: he's not writing to the filesystem. Something >> else is wrong. >> >>> 2) from a portability point of view, the webapps directory is >>> not guaranteed to be writeable. It may not even be a >>> filesystem. >> >> +1, not probably not relevant. >> >>> Maybe there is something more subtle going on here : Have a >>> look at the HTTP RFC and its description of a PUT : >>> https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 I >>> am not saying that that /is/ how the actual code works, but in >>> function of that description, it seems to me that a webserver >>> would be entitled to map the given PUT URI into the "URI >>> space", and from there into the filesystem, and check if that >>> filesystem location is indeed writeable. In any case, it seems >>> to me dubious to use a PUT, to update a record in a database. A >>> POST would probably be more appropriate here. >> >> The only weird thing to me is the fact that this works when the >> OP deploys the same application in a different way. >> > > We do not know the webapp. We do not know the URI to which this is > being PUT. We don't know what security rules are (or are not) > implemented at the JVM or container level. We do know that there is > a PUT handler implemented, because a) it works in one case > (deployed outside of webapps) b) when it does not work (in > webapps), the error code returned is not 405 (not implemented), but > 403 (forbidden) Let's presume that the PUT URI does not change, no > matter where the webapp is actually deployed. Let's presume that > the application's security-constraints do not change either. > > I would also suppose that we know that when the example DAV > application (which handles PUTs) is deployed inside the webapps > directory, it does not return a 403 for allowed PUT URI's. > > Given the above, I can only imagine that it is the OP's > application itself, which is returning the 403 in one case. The > application could be trying to write to another file somewhere, > and return a 403 when it cannot. To really know why it does, would > require a knowledge of the application, which we don't have. My money is on the OP looking at the wrong context.xml file: when it's deployed in webapps/, Tomcat will use META-INF/context.xml. When it's deployed elsewhere, it's loading conf/[engine]/[host]/[appname].xml. I suspect that the file META-INF/context.xml is missing something important -- such as the "privileged" flag or something like that. Preshant said nothing about what is handling the PUT (e.g. DefaultServlet). - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAla1FmYACgkQ9CaO5/Lv0PA1ogCgnYpdV5Wf2XrYNZ8d+r9pdOd8 lggAoJVnJy6zJc8FX0waWw5C7FgFWCcG =f1Bq -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
