The Kladde’s public appointment booking is reachable by everyone, and that’s exactly what it’s for. Since K2 (lesson 2.6.6), it limits bookings per visitor address. This lesson asks the question behind that: Which address does the app actually see? Between the browser and the Kladde in Azure there are at least one, often two proxies, and each of them writes something into the headers. Which of it is true, and what did the visitor write themselves? On top of that come the basics of Front Door and the Web Application Firewall (WAF), which can stand in front of an app like the Kladde.
The path of a request
A browser never connects directly to the Kladde’s container. It talks to the ingress of the Container Apps environment, a proxy
that terminates TLS, passes the request on to the container’s port and sets headers along the way. For the app, the ingress is the sender:
HttpContext.Connection.RemoteIpAddress is the ingress’s address, not the visitor’s, and the request arrives over HTTP even if the
browser used HTTPS.
What the app can learn about the visitor is in the headers that the ingress sets:
| Header | Content | What the ingress does with a value sent along |
|---|---|---|
X-Forwarded-For |
the addresses of the sender and the proxies in front | appends the address it sees; whatever is in front came from the sender |
X-Forwarded-Proto |
http or https |
overwrites it |
The decisive sentence is in the Container Apps documentation: Only the rightmost entry in X-Forwarded-For comes from the
ingress. Everything to the left of it was sent along by the sender and can be anything. If someone sends X-Forwarded-For: 203.0.113.66, then
203.0.113.66, 198.51.100.23 arrives in the app, and only the second address is the real one.