In our application(Deployed in IIS), we have enabled only HTTPS(Disabled HTTP access).
While accessing API endpoint using http protocol with OPTIONS verb, its returning 200 Ok response.
How to fix?
You can try to disable the OPTIONS verb in IIS, the steps are as follows:
Start the IIS Manager, double-click to open the Request Filtering module, select HTTP Verbs, select Deny Verb… on the right, enter OPTIONS and click OK.
Disable OPTIONS Verb
Related
We have an Angular app hosted on Apache that is going through QA testing. The app communicates with an app server hosting our web services via a reverse proxy setup in Apache's httpd.conf:
ProxyPass /SVCS/ https://dev.mycompany.test/SVCS/
ProxyPassReverse /SVCS/ https://devws.mycompany.test/SVCS/
We noticed the original developer hard-coded the Basic Auth header the downstream web services require in the JavaScript. We want to remove this from the web app and instead have Apache append the Basic Auth header in the proxied request.
<IfModule mod_headers.c>
Header add Access-Control-Allow-Origin: "*"
Header set Access-Control-Allow-Methods: "OPTIONS, GET"
Header set Access-Control-Max-Age: 1
Header set Access-Control-Allow-Credentials: true
Header set Access-Control-Allow-Headers: "authorization, X-my-header, X-your-header"
RequestHeader set Authorization "Basic FOOBAR123ZZZZZZZZZZZZZZZZZZZZZ="
</IfModule>
This IfModule snippet was already in the file, I just added the RequestHeader line (obfuscated here). As soon as this is added, the browser starts prompting for a username/password "Authentication Required". I tried setting the Access-Control-Allow-Credentials=false but there was no effect. The Basic auth user/password is a service account created for the app to access the web services, we don't want the end user to have to enter anything, they are already authenticated via SSO from another app.
How can I get the basic auth added to the proxied request's headers and not prompt the user for a password?
I tried something along the lines of this post apache-basic-authentication-issue-with-reverse-proxy which essentially configures a password file. But that wasn't working, even when entering the correct password the service was returning a 401 not authorized (plus I don't want the user to have to enter anything)
The authentication prompt was due to the fact I was setting the Authentication header for ALL requests instead of just the one service that required it. There was a followup service called that if I add the Auth header to, the server was complaining about the Authentication. I was able to narrow the setting of the header to this service only (via RewriteCond and RewriteRule) and all is well.
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 would like to validate cookies' authenticity using a backend http service, which is hidden behind an Apache HTTP Server - set as reverse proxy. I would also like to avoid scripting (CGI, Perl, Ruby, etc.) and use the Apache configuration only.
This should enable the decoupling of the cookies' validation logic from the reverse proxy itself.
Here are the actors in the flow I would like to implement:
Backend main service [Main]
Backend Cookie validation service [CookieValidation]
Backend reverse proxy [RevProxy]
Frontend web browser [Frontend]
Here is the flow I would like to implement:
[Frontend] requests a resource from [Main]
[RevProxy] intercepts the request
***** Pseudo code *****
response = send cookie to [CookieValidation] for validation
// e.g. *http://CookiValidation.server.com/validate?cookie={...}*
if (response.status == STATUS_OK) {
Proxy original request to [Main]
} else {
return response
}
Will that be possible?
You can't do it with just Apache "configuration".
If you don't want to write your own Apache module, you'd have to at least write a small script and ivnoke it as a RewriteMap prg: script. It would contact the cookie validation server, and you'd use its output as a test in RewriteCond to determine whether to proxy / where to proxy (it wasn't very clear what actions you expected)
I am trying to make a (non-simple) CORS GET request (AJAX) made by my client server (running on Apache # port 443) to a 3rd party endpoint server (running on Tomcat # port 8443), which fails to trigger when tried over HTTPS.
When SSL is not enabled it works just fine indicating that the CORS is set up properly.
The problem is that since the GET is (not-simple) it sends a pre-flight OPTIONS request.
According to this:
Pre-flight OPTIONS request failing over HTTPS
Pre-flighted requests don't include the client certificate. He states this is in the CORS spec however I was unable to find this specifically listed in the spec:
http://www.w3.org/TR/cors/
The third party cannot enable
SSLVerifyClient optional
as they require all communication be sent with SSL.
However they do have their CORS setup right and they have
access-control-allow-credentials: "true"
In our AJAX call we included in the xhrFields
withCredentials: true
So we are telling it to pass withCredentials (which includes cert / cookie / etc)
And on our APACHE we have
SSLOptions +ExportCertData
Somehow when we make the call though, they are still seeing the error "key/cert was not included "
Am I missing something? Is there a way to force this in Apache?
At the moment I'm getting ready to create a man the middle script to attach the cert to the initial request but it seems like there has to be a better way.
Any suggestions?
I am using an Apache 2.4 server with mod_proxy as an HTTP reverse proxy for Tomcat server. The reverse proxy works on a Split-DNS configuration where "server.com" might point either to the actual HTTP server or to my reverse proxy depending on where the client is.
The problem that I'm having is that our client application had a problem where sometimes it would include an header more than once. For example, an HTTP request could end up looking like this:
POST server.com HTTP/1.1
Some-Header: foo
Authorization: BASIC abc123
Authorization: BASIC abc123
Other-Headers: ...
This works fine if the client is talking directly to Tomcat but if it goes through the reverse proxy then the duplicated headers seem to get mangled and Tomcat ends up receiving a request that looks like this:
POST server.com HTTP/1.1
Some-Header: foo
Authorization: BASIC abc123, BASIC abc123
Other-Headers: ...
I used Wireshark to inspect the HTTP requests as they are sent/received in the Client->Proxy->Tomcat chain and Apache is definitely the component that is "collapsing" the two headers into one.
Is there a way to configure this behavior in a way where it either sends both headers or just one? What I don't want is this "collapsing" taking place...
You can use mod_headers to remove the duplicate header. See their official docs for information on how to enable it.
Then you can add a line like this to your configuration file so that the first part of header disappears:
RequestHeader edit Authorization "^BASIC\ abc123\\,\ " ""
Let me know if that works for you.