Is it possible for to configure NGINX such that the healthcheck calls a post endpoint on a server and match the response?
For example, I'd like to do a healthcheck using an existing post endpoint in a node - this would mean having to set a RequestBody in order to allow the check.
My options now are to expose an endpoint that does that for me and just go through that, but I am not completely sure if that's the most optimal way.
Related
I have implemented an EnvoyFilter for one of my services by following this sample. Now I want to implement a similar one, but it is for a service that is out of my control.
The current request flow is like this:
browser sends a request
istio ingress receives the request
the request is routed to the 3rd party service in the cluster but does not have a istio-proxy sidecar
I need to inject some headers at step 3 before routing the request to the other services. The header content is dynamic, and I need to make some HTTP requests to get the content.
Is there a filter that can do this? Or is it simply impossible with Istio?
Thanks
Situation
I have a REST API in place that returns JSON objects to its clients. Part of said JSON responses are absolute URLs to other "linked" resources/objects of the form "http://myservice.com/servicePath/apiVersionA/123". In the example URL "servicePath" is the web root of my service, "apiVersionA" is the specific version of the REST API being used, and "123" is the identifier of the actual resource. The fact that my API is returning absolute resource URLs in the response body is prescribed by the protocol I'm using, I am not at liberty to change that.
Problem
The problem I'm facing now are reverse proxies, and more specifically how I assume they handle request patterns like the following:
Client sends request "GET http://myproxy.com/rest/apiVersionA/123" to the Reverse Proxy.
Reverse Proxy forwards the request to its final destination: "GET http://myservice.com/servicePath/apiVersionA/123". Please note that the proxy modifies both the host name and the URL path ("rest" is changed to "servicePath") of the request.
AFAIK, the usual suspects (i.e. HTTP headers "Forwarded", "X-Forwarded-For", "X-Forwarded-Host" etc.) only contain either IP addresses or domain names, but not the entire URL path. So right now in the best case scenario I can generate URLs like "http://myproxy.com/apiVersionA/123" - notice the missing "rest" URL path element that is required by the proxy. This URLs will thus not be accepted by the proxy in a subsequent request made by the client, e.g. to retrieve a resource that is referenced in the response message.
Questions
Is there an obvious proxy-safe HTTP header I am missing that would deliver the original request URL to the actual REST API service?
If not, is there another way how I can generate correct absolute URLs in my service?
So far I have thought about using a custom HTTP header (which might get removed by an intermediate proxy), or by using something like https://httpd.apache.org/docs/2.4/mod/mod_substitute.html on the reverse proxy (which I'd say is not possible as I do not control the networking infrastructure of my customers or any intermediaries). Another "non-solution" that I came up with is to document this as part of my API: "do not use custom URL path elements on your HTTP proxies". This would allow me to generate URLs using just X-Forwarded-Host and X-Forwarded-Proto.
Any help is appreciated!
After some more research it became apparent that there is indeed no standard HTTP header that can do the job. I have thus proceeded with implementing a combination of "Forwarded/X-Forwarded-For" and Microsoft's proprietary "X-Forwarded-PathBase" (https://microsoft.github.io/reverse-proxy/articles/transforms.html) header. This works as intended - customers that cannot or do not want to use the proprietary header still get back valid absolute URLs via the reverse proxy, as long as they do not implement request path mapping in their proxy configuration.
Is there a way to forward query parameters from original request to auth-url? I know we have X-Original-URL but can we directly get them as query parameter for auth-url?
Ingress controller cuts off url query parameters from the original request when calling external authorization endpoint.
This is an issue in OAuth scenario when the OAuth server sends the authorization code back to the resource server.
The auth enpoint needs that code to get access token.
Try to use the image quay.io/aledbf/nginx-ingress-controller:0.185 it uses the rd parameter for the correct redirect url after the login.
You can also add State Parameter. It will help for oauth2_proxy.
State parameter will reserve the state prior to authentication request and pass random generated state value in request to authenticate and in call back request they will add state back i.e. Oauth2_Proxy generated id. Then Oauth2_Proxy will read that ID and provide the URL back and respond.
Take a look: ingress-nginx-issue, configuring-http-basic-authentication/, url-to-oauth-proxy-as-redirect.
Is there any way to use method PATCH inside either POST or PUT?
I'm using a smart mirror repo on my Raspberry Pi, and the only methods it has for custom commands are GET/POST/PUT. And the only method the GPIO-Server has is PATCH
I've tried put but it just returns a 405 Method Not Allowed.
No, it's not possible. HTTP method can be either POST or PATCH, but you can't use one method via another. The only solution I can think of is using a proxy, which would change POST requests to PATCH. For example, you would send a POST request to the proxy server, and the proxy server would send a PATCH request with the same data to the destination server.
I want to route SOAP messages to different servers depending on the message content.
I tried the Application Request Routing (ARR), but it seems, that you can only route by server variables and the HTTP header.
I found this tutorial:
Developing a Custom Rewrite Provider for URL Rewrite Module
My Question is, can I route depending on the HTTP body with a custom ReplaceProvider (IRewriteProvider, IProviderDescriptor)?
This is not possible!
Application Request Routing (ARR) can only access information from the http header.