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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
