We are running an API for our mobile app, and with the right HTTP headers, have been able to enable developing it locally using the live API without the need of a 'CORS plugin'.
Now, it does not work anymore, probably since moving the domain name from one user to another (using DirectAdmin), but I cannot figure out how to fix it. Moving the domain back to the original user does not fix it. We have been running Apache 2.4 for quite a while already, that's nothing new.
I tried adding the following to httpd.conf:
<Location /api>
AllowMethods GET POST OPTIONS DELETE PUT
Require all granted
</Location>
<Directory /home/username/domains/example.com/private_html/www/api>
AllowMethods GET POST OPTIONS DELETE PUT
Require all granted
</Directory>
I verified being in the right VirtualHost block by successfully changing the ErrorLog file location.
I also added Require all granted to all .htaccess documents from the private_html folder to the api folder, but the error log keeps saying: [allowmethods:error] [pid ...] [client ...] AH01623: client method denied by server configuration: 'OPTIONS' to /home/username/domains/example.com/private_html/www/api
Note that our mobile app actually still works (GET and POST), but PUT and DELETE don't, just like OPTIONS. It seems like the requests never even hit my domain folder, but get stuck in Apache config.
How can I debug this? How can I get Apache to tell me which policy is preventing that method?
I finally solved the issue with this httpd.conf block:
<Location "/">
AllowMethods GET POST OPTIONS DELETE PUT
Require all granted
</Location>
I was originally trying to limit that to just the API URL, but apparently that gets complicated because of RewriteRules. The first request on /api is passed through, but I needed a new block for each RewriteRule that happens. So I just used Location "/" to fully allow it... hope that doesn't introduce security issues.
#Sygmoral
This also fixed my problem!
If you ever get this message inside a new DirectAdmin environment getting the response on a OPTIONS method:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method OPTIONS is not allowed for this URL.</p>
</body></html>
Or if you've checked the apache error logs containing: AH01623: client method denied by server configuration: 'OPTIONS'
You should head out to the section in DirectAdmin " Custom HTTPD Configurations " (as admin) and add the lines to your domains custom httpd.conf:
<Location "/">
AllowMethods GET POST OPTIONS DELETE PUT
Require all granted
</Location>
Related
I can't wrap my head around why the .env is still exposed. The website has an HTTPS certificate. I have the .env file denied in the .htaccess file like so:
# Disable index view
Options -Indexes
# Hide a specific file
<Files .env>
Require all denied
</Files>
It is blocked properly (403 forbidden error) on these URLs:
https://example.com/.env
http://example.com/.env
http://###.IPaddress.###/.env
But is still visible here by ignoring the "not secure" warning:
https://###.IPaddress.###/.env
Likewise, there is still the Apache Testing 123 page being served as the homepage for the above URL (when not accessing the .env file). How can I block this file?
You probably have a default <VirtualHost *:443> that is catching the request (the first vHost that is defined in the server config is the "default") and this probably doesn't allow .htaccess overrides (ie. AllowOverride is not defined or set to None) so the .htaccess file is not processed.
You need to ensure that the default vHost that is catching the request either blocks requests to the IP address entirely, or redirects to the canonical hostname.
See the following question on ServerFault for more detail on configuring this:
https://serverfault.com/questions/914649/htaccess-block-access-when-http-host-is-ip-security
www.old-server.com/ws/ is the base URL for a web service on old-server. This is accomplished using a Location directive for "/ws" with a setHandler enclosed within the directive.
when a request for www.new-server.com/ws/ is received new-server needs to redirect the request to old-server/ws/. Any trailing parts of request URL need to be passed to old-server as well.
Running Apache2, with mod_rewrite.so loaded, on CentOS 7.
on new-server, the following does not work.
<Virtual Hosts>
...
<Location /ws>
Redirect "https://www.old-server/ $1"
</Location>
...
</Virtual Hosts>
I think the doc's say Redirect is not support inside of Location.
What is the correct way to do redirect the request URL to old-server?
The answer for me was to stop over thinking the problem. The Location directive is fine, but my redirect statement was wrong. The following is working at the moment, pending further testing with more complex scenarios.
<Virtual Hosts>
...
<Location /ws>
Redirect "/ws" "https://www.old-server/ws"
</Location>
...
</Virtual Hosts>
I have an IP-restricted site configured to allow access only from specific URLs. The configuration is in apache2.conf as follows:
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require ip 123.45.678.90
</Directory>
I'd like to display a custom 403 page instead of the default one, so I created 403.html. However, I'm having trouble finding the right place to put it in apache2.conf.
I've tried adding "ErrorDocument 403 403.html" inside the directive, but then the webpage literally displays "403.html" -- not the page, but that actual string. That'd be fine if I just wanted to have the message IN the apache2.conf, but I'd prefer to actually have a page I can edit a little more conveniently.
I've tried placing it outside the Directory directive, but that returns the typical 403, plus the following:
Additionally, a 403 Forbidden error was encountered while trying to
use an ErrorDocument to handle the request.
I figure that makes sense, since they're not allowed in that directory anyway. So, I tried creating a new folder called /var/error and adding it there. However, that returns the same "additionally..." error above.
Where's the proper place (and how) to put this?
I am very new to apache configurations and am trying to learn more. I am getting a 403 - Forbidden when making a PUT request, however a GET to the same URL works fine.
Is there something I need to enable to allow PUT requests?
I am using Apache and PHP
If you are working with Apache 2.4.x, a faulty or missing "Require" directive could the cause of the 403.
In the <Directory> block of your virtualhost config, or your .htaccess file add the following line:
Require all granted
For details on the "Require" syntax see: https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#require
our IT is trying to configure a new apache/jboss/apj setup.
When I browse to http://domain.com/jboss/test.jsp
and System.out.println request.getRequestURL()
I get http://domain.com/test.jsp
(without jboss)
My app encounteres a lot of 404's because of this.
The IT department said Jboss has no concept of the /jboss/ part of the url because of the proxy. Are they configuring things properly or do I need to change my code. To me my code is not portable if I have to hard code url paths.
Edit-
Here is what they told me:
<Location /jboss>
ProxyPass balancer://cluster stickysession=JSESSIONID
ProxyPassReverse https://domain.com/jboss/
</Location>
This article supports my question
https://sosiouxme.wordpress.com/2010/08/18/fixing-apache-httpd-reverse-proxy-redirect-rewrites/
Edit2
On our old server in a my login framework servlet used by a few apps I had
response.sendRedirect("login.jsp?message=You have successfully logged off.");
to get things to work with the new proxy I have to recode as
response.sendRedirect("/jboss/AppName/login.jsp?message=You have successfully logged off.");
I lose portablity and reuseabilty with the latter syntax.
The error (in Apache, not jboss) for
response.sendRedirect("login.jsp?message=You have successfully logged off.");
File does not exist: /WEB/wwwssl/AppNamelogin.jsp
Note there is no "/" between my appname and login.jsp
The error (in Apache, not jboss) for
response.sendRedirect("/login.jsp?message=You have successfully logged off.");
File does not exist: /WEB/wwwssl/login.jsp
Note the AppName is missing
Note that the article you mention uses mod_proxy_html (ProxyHTMLURLMap ProxyHTMLURLMap / /ajp/nocluster/), which will fix links to use the right path prefix. This is not part of the default mod_proxy modules provided with Apache Httpd.
Instead of putting these directives in a <Location> block, using a single line syntax might forward the path correctly:
ProxyPass /jboss balancer://cluster stickysession=JSESSIONID