We have upgraded to Apache 2.x and Tomcat 7.x recently and seeing this issue.
Our Rest enabled Web services are deployed in Tomcat.
RESTful API's require hierarchical URI's that have nothing to do with directory structures on a filesystem. e.g. http://mycomp.com/product/123.
All the GET requests are working fine but when we try to use PUT/DELETE/POST etc, client is thrown out with "403 Forbidden" error, and Apache error.log shows : "client denied by server configuration"
I have checked httpd.conf file and it has <Directory> block with "Allow all" access.
The issue has been resolved by updating <LimitExcept GET POST> element.
Related
I am using Apache 2.4 on CentOs to power my website. However, I always get a 403 forbidden error when trying to access the website through my browser. When I consulted the file error_log in the log directory of /etc/httpd, I repeatedly see the error:
AH01630: client denied by server configuration
I have read in the Internet as well as in multiple StackOverflow questions that you can solve this error with Require all granted in the html directory configuration of the httpd.conf file (/etc/httpd/conf/).
I have configurated this directory (through which I am hosting my website) like recommended above (it was already configurated). The error persists, so there must be another problem in the server configuration that denies access to my website. My httpd.conf file is not changed at all, it is the default file that gets downloaded when installing Apache 2.4. Does anybody know why this error occurs? Can somebody explain to me what else can cause this error? I have looked everywhere in the internet for this error (links below) but nothing could help me at this problem.
I have no .htaccess file in my website. Only an index.html file to test it.
Stack Overflow Question: "Apache2: 'AH01630: client denied by server configuration'"
Apache Wiki
Serverfault
I just deleted the whole HTTPD configuration and then reinstalled Apache. I had to enable PHP too by using these lines of code:
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
Then Apache worked flawlessly.
I configure my Alfresco instance to be in a sub-URI (www.example.com/prefix/alfresco , www.example.com/prefix/alfresco/share) and all looks to be fine except that I can't log in Shared. The Catalina.out log this error:
ERROR [alfresco.web.site] [http-apr-28080-exec-10]
javax.servlet.ServletException: Possible CSRF attack noted when
asserting referer header
'http://www.example.com/prefix/alfresco/share/page/'. Request: POST
/prefix/alfresco/share/page/dologin, FAILED TEST: Assert referer POST
/prefix/alfresco/share/page/dologin :: referer:
'http://www.example.com/prefix/alfresco/share/page/' vs server &
context: http://10.140.8.144/ (string) or (regexp)
Then the browser show me this page (www.example.com/prefix/alfresco/share/dologin):
Something's wrong with this page...
We may have hit an error or something might have been removed or
deleted, so check that the URL is correct.
Alternatively you might not have permission to view the page (it could
be on a private site) or there could have been an internal error. Try
checking with your Alfresco administrator.
If you're trying to get to your home page and it's no longer available
you should change it by clicking your name on the Alfresco toolbar.
I tried to deactivate the CSRF filter in share-config-custom.xml, but then I can't log and I don't have any message in the log, the login page show:
Your authentication details have not been recognized or Alfresco may
not be available at this time.
My apache conf:
ProxyPass /prefix/alfresco
http://10.140.8.144:28080/prefix/alfresco ProxyPassReverse
/prefix/alfresco http://10.140.8.144:28080/prefix/alfresco
ProxyPass /prefix/alfresco/share
http://10.140.8.144:28080/prefix/share ProxyPassReverse
/prefix/alfresco/share http://10.140.8.144:28080/prefix/share
I could log before configure Alfresco for work in the reverse proxy.
There is no need to deactivate the CSRF filter. If you changed the context path as described in the documentation you need to make sure that the tomcat connector "knows" the outside context (hostname, port, context).
Either
set proxyName and proxyPort
set RemoteIpValve in tomcat server.xml and set required proxy header
variables in apache (x-forwarded-for, x-forwarded-by,
x-forwarded-proto)
use proxy_ajp instead of proxy_http and define a ajp connector in
tomcat
I'm getting an "Access Denied: Insufficient privileges to access this interface" message while trying to access the management console of Wildfly (running on Ubuntu).
I also got an Apache2 acting as ProxyReverse for the Wildfly server. It gets requests for alias.domain.com:80 and forwards to localhost:9990.
The Wildfly access-authorization is still using simple provider, so rbac is not the culprit. Or so I believe...
When I access alias.domain.com, I'm prompted for the user/password, and I do supply the correct admin authentication data.
Any help will be appreciated.
OK, just wanted to let you guys know that the issue was resolved with a
ProxyPreserveHost On
on Apache conf.
For those using Nginx, the following directive will help with this error:
proxy_set_header Host $server_addr:$server_port;
I'm trying to set up a webserver on my VPS (Running Debian 7). I have installed apache and configured it. However, when I try to connect to my IP I am faced with a 403 forbidden error saying that I don't have access to / on the server. I have attempted to set it up so that when connecting the webserver should direct to the directory: /home/webmaster/website. My main apache.conf file is as follows: http://pastebin.com/zgyik39y
and my site config, called "web.conf" is: http://pastebin.com/jpRJAaCw I don't know what to do, I've tried many suggestions on here and in other places and none so far have worked.
Line 18 of web.conf should be:
Allow from all
For apache 2.2 or:
Require all granted
For apache 2.4
I have a front-end apache server running in a windows server.
The system is setup with NTLM or BASIC Auth (same problem with both).
A download from a MS Word or Excel documents works fine in all browsers.
If I use the Internet-Explorer and download a office document the download the document request another url.
Watchging the apache access logs I saw that there are requests with OPTIONS and PROPFIND inside.
So I modified the config using this:
<Location /latest>
<Limit OPTIONS PROPFIND>
deny from all
</Limit>
</Location>
This worked so far, but with Office 2010 I encountered the problem again.
Searching the web I found this article: http://support.microsoft.com/kb/2019105
Therefor I don't have to send 403 (deny from all sends 403 I guess?), so I have to send 405.
So may I just do this? Is this correct?
<Location /latest>
<Limit OPTIONS PROPFIND>
redirect 405
</Limit>
</Location>
Finally debugging more the issue I found out that this is the correct configuration.
To mention I have to make also clear that I sometimes setup the authentication in the background webserver (IIS 7) and sometimes inside the Apache (depends on customer situation).
1.
As Apache is my frontend proxy and the backend server is the IIS7, when IIS7 authenticate this worked:
Disable support of the OPTIONS and PROPFIND verbs – If the web application is not intended to be used for WebDAV, the Web Service Extension that provides the WebDAV functionality can be set to Prohibited on a default server that is running IIS. (This might be WebDAV or FrontPage Server Extensions.) If the site provides WebDAV functionality through another extension, the provider of that extension should be involved. For example, to do this with Windows SharePoint Services (WSS), the site should be configured to disable Client Integration, or the OPTIONS and PROPFIND verb should be inhibited. (On IIS 6, remove the verbs from the registration line in the web.config file. On IIS 7.0, use the HTTP Verbs tab of the Request Filtering feature to deny the verbs.) Be aware that this approach will open the content in read-only mode because this approach disables direct-edit functionality.
from: http://support.microsoft.com/kb/2019105/en-us
So I set the content filter for the verbs and then it worked fine for me finally.
2.
Then I tested using the NTLM Auth in Apache.
My original config worked fine when Apache authenticate itself.
So I ran only into the problem mixing the behaviours :)
** EDIT **
For IIS web.config this should work:
<system.webServer>
<security>
<requestFiltering>
<verbs applyToWebDAV="false">
<add verb="OPTIONS" allowed="false"/>
<add verb="PROPFIND" allowed="false"/>
</verbs>
</requestFiltering>
</security>
</system.webServer>