tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Http 403: access to requested resource denied
Date Fri, 05 Feb 2016 21:38:46 GMT
-----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" <dckerber@verizon.net> 
>>>>> wrote:
>>>>>> 
>>>>>> On 2/3/2016 12:23 PM, prashant sharma wrote:
>>>>>>> 
>>>>>>> On 3 Feb 2016 16:38, "Mark Eggers" 
>>>>>>> <its_toasted@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" 
>>>>>>>>> <dckerber@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.0900@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message