From the documentation:
When the end user has filled in their login details, the form will make an HTTP POST request to the original password protected URL. mod_auth_form will intercept this POST request, and if HTML fields are found present for the username and password, the user will be logged in, and the original password protected URL will be returned to the user as a GET request.
I have an running at port 45001
and apache reverse-proxying to it. I use form authentication and ErrorDocument
to enforce login. This is my config:
<VirtualHost myip:44302>
ServerName myserver.com
# Pass auth info
RequestHeader set X-Remote-User %{REMOTE_USER}s
# Login page is directly on the server - don't use reverse proxy
ProxyPass /login/ !
# Proxy all requests to the app running in a docker container
ProxyPreserveHost On
ProxyPass / http://localhost:45001/
ProxyPassReverse / http://localhost:45001/
# Require auth for all requests except the login page
<LocationMatch ^/(?!login).*$>
AuthType form
AuthName "login"
AuthFormProvider ldap
AuthLDAPURL <url>
AuthLDAPBindAuthoritative off
# Redirecting to login page if auth is needed
ErrorDocument 401 /login/index.html
# If authorization fails, return 403 insead of 401
AuthzSendForbiddenOnFailure On
# Use session cookie
Session On
SessionCookieName session path=/;httponly;
SessionCryptoPassphrase <passphrase>
Require valid-user
</LocationMatch>
</VirtualHost>
Form (simplified of classes and div wrappers):
<form action="" method="POST">
<input name="httpd_username" type="text">
<input name="httpd_password" type="password">
<button type="submit">
Login
</button>
</form>
For other scenarios, where I don't use the reverse proxy, the workflow is correct:
- access URL
- check for the session cookie
- request login if needed
- send
HTTP GET
request to the original intercepted URL
But when I use the reverse-proxy, instead of sending HTTP GET
to the intercepted request, apache sends HTTP POST
. The app behind the proxy doesn't work with POST
and prints an error.
If the user refreshes the page, it all works correctly because the session cookie is already set.
What's causing this misbehavior and/or how do I properly configure this authentication to work?