Suppose we have two servers A and B behind some load balancer that distributes requests between these servers somehow. What is the best practice of tracking which server processed a request? Suppose we have REST API with one endpoint GET /ping. Is it a good idea to include the host information into headers for example?
What we do usually, is that we configure the LB to include a header only if the client requested it.
When you forge your /ping query, also add a header only known by you , like "X-Debug-Me: true". When this header is present, then either your LB or your server can insert its real hostname into whatever header you want.
Baptiste
are you attempting to track this at the LB or at the origin/API servers?
shouldn't the host information already be in the header? is the LB acting as a reverse-proxy and replacing the requesting hostname with it's own hostname?
i would agree with #baptiste that if you need to track this type of information a custom header is the best way to do it.
Related
I'm curious whether if it's possible to set up a server to respond with html fetched from another domain rather than simply redirect the requester to that domain.
For example, I set up a simple node express server that has a GET route /google, which fetches google.com, and then responds with the response from the fetch. However, in this case, it does not respond with the google webpage as I would expect.
It is not only possible but quite common especially in larger server environments. The term you are looking for is reverse-proxy.
Proxying is typically used to distribute the load among several servers, seamlessly show content from different websites, or pass requests for processing to application servers over protocols other than HTTP.
Source: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
Most major web servers support it.
More than likely the response you're getting from google (and passing on) is some kind of redirection. Try it with a static web page of your own to rule out any redirection shenanigans.
I am attempting to get sustainsys.saml2 to operate behind an SSL load balancer with the SSL truncated at the load balancer. If I pass SSL requests into the app, it all works as expected. What I want to do is pass HTTP requests into the app, and have sustainsys create logon requests with SSL based consumer assertion urls. Is this possible ?
Solved this one fast, for those interested all you have to do is handle the GetPublicOrigin notification
As you've found out you can use the GetPublicOrigin notification. But that is really meant for an advanced scenario when you want to alter this per request. For normal cases just setting the SpOptions.PublicOrigin property is easier.
I need to simulate real user behavior. Each of real user must have new IP. Can I set Proxy programmatically via jmeter ? Example - I launch tests without Proxy, then, after 1-2 sec I activate the proxy and after 3-4 sec - I disable. Is that possible without stopping the test ?
If you need to spoof the ids then you can use csv to get the different IPs (proxy IPs) and pass them as a variable in the HTTP Request Server Name field under advanced tab as shown below:-
Please check this article for more information.
I hope this help.
There is a possibility to define a proxy per HTTP Request, the relevant configuration lives on "Advanced" tab of the HTTP Request sampler.
A better option would be going for IP Spoofing, this way you will be able to bind each virtual user to a real (or virtual) IP address so source address will be different.
I have some REST services available with on an ip+port address. Now I want to configure a DNS entry to have it available through my domain. I've tried a masked redirect but once I do it I can't access the REST services using the redirected address. What type of DNS entry should I use?
DNS only works at the IP Address level, its only concern is mapping domain names to IP Addresses, there is no way to specify a port number.
If you have a server located at 12.34.56.78, you can use an A record to point to it. There is no way to specify a port in DNS.
Edited to add
While RFC 2782 A DNS RR for specifying the location of services (DNS SRV) does provide a method to use Srv records to specify port numbers, it was ultimately allowed to expire and was never renewed.
Specifically the proposal was rejected because it could break too many things in the HTTP layer.
A message was posted to the IETF message boards explaining the decision.
I was proposing it, but after long discussions in the maillist I've
understood that mandating DNS SRV in WS clients would break too much
assumptions in HTTP world (which commonly just sees above HTTP layer
and not below).
The existence of HTTP proxies is also a big handicap since those
proxies should be upgraded/modified in order to perform DNS SRV
resolution just in case the HTTP request is a WebSocket handshake.
This last argument is enough to not mandate SRV resolution.
(copied from another answer)
There actually is a mechanism called DNS Service Discovery originally specified in RFC 2052 (obsoleted by RFC 2782). This allows for autodiscovery of services through special SRV (type 33) DNS entries, specifying ports and weights (i.e. preferences) for named services. There were some considerations extending this to HTTP URIs, but the respective drafts have ultimately been allowed to expire before they could reach RFC status. Some of the reasons are being mentioned in section 2 of latter one.
While SRV records are seeing active usage in other protocols, HTTP client support for this is quite rare. So if you want to provide your service through a dedicated, non-standard port, your best bet is to specify it in the URL as specified in RFC 3986, section 3.
I'm building an endpoint which returns images. I want to only allow requests from the same domain for this endpoint so that other people won't have access to it. I can't use CORS because you can essentially make the call inside an image tag and bypass any cors restrictions. Is there anyway to do this?
If your goal is to prevent simple hotlinking, you can do a referrer check: Check the Referer [sic!] header, make sure it contains a whitelisted domain.
Keep in mind that the Referer header is sometimes missing, e.g. because it has been removed by security software concerned about the user’s privacy.
Also, it is needless to say that referrer-based checks are easily circumvented by anybody who is determined to abuse your service.
Although you cannot (as far as I know) forge the referrer in a browser request (e.g. to download the image with AJAX), you could simply set up a proxy server which would download the images with a forged referrer header and deliver them to the actual client.
But, at least, it would take some energy to do so, and you could easily block such a server by IP address (unless it's a pool of IP addresses).