tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat) ...@ice-sa.com>
Subject Re: Http 403: access to requested resource denied
Date Thu, 04 Feb 2016 11:27:23 GMT
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.



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


Mime
View raw message