I have a domain foo.com registered with google domains. I have configured it to forward to myfoo.com (including path forwarding, etc.).
When HTTP requests are sent, it successfully forwards
foo.com --> myfoo.com
foo.com/abcd --> myfoo.com/abcd
But when the HTTP requests include JSON data (Content-Type JSON), I cant see the data on myfoo.com. I do see that the forwarding to myfoo.com happens. But there is no data. Does this involve some configuration on my server side or something on google domain forwarding? PS: I have made sure that my server side can handle JSON data. When I directly reach myfoo.com/something with Content-Type JSON, I can handle it.
Related
I have an nginx server serving both as an http server (frontend) on / and reverse proxy on /api, where it forwards the requests to a node server (backend) on the same machine (localhost).
I am using authentication only on the frontend. The backend accepts all incoming requests and does not authenticate again the requests.
I would like to allow all requests coming from the frontend to the backend. I would like to block all requests coming to the backend from other sources (via the reverse proxy of course).
For example, the frontend will try to login the user using the user third-party auth id via https://domain/api/login/id. The reverse proxy will forward it to the backend. This is fine.
I can also access the backend directly from any other machine via https://domain/api/login/id.
My question is the following. I would like to block all requests not originating by the frontend. I have tried figuring out how to find the information but it seems that the X-Real-IP header always refers to the browser originating the request (either by using the frontend or directly). I am wondering if there is any header I can set in the reverse proxy which will tell the backend that this is an allowed call, or even use nginx own allow/deny rules. Right now, I do not manage to make a distinction between the two types of requests.
Thank you very much!
I want to set up a custom proxy that proxies connections to some destinations (inside a network) but not other destinations (in the global internet). Is there any HTTP response the proxy server can send to make the browser connect directly to the requested destination?
For example, I request redirection to Google to my proxy server. The proxy server decides not to proxy, so I get this HTTP response, and my browser connects directly to Google.
You could send a redirect http response code like 302 to redirect the client directly to the website. See: https://moz.com/learn/seo/redirection
When a web server receives a http(s) GET request from a client, it has access to some information such as:
The client IP
The request itself :
the headers (including the cookies)
the content
and... that's all ?
I am wondering if there is something else.
Indeed, I am trying to make a server that can access to a page where it can collect some information to update its database. The site denied access to my server but not to web browsers, even if I replicate the IP, the headers and the content.
Thanks for your help.
Yes, it's only what is contained in the request itself. The server cannot reach back to the client to "pull" information, it only has the information contained in the HTTP request and the underlying TCP/IP packet. That's:
the requesting IP address
the HTTP headers, including requested URL and HTTP method
the HTTP request body, if any
if it's HTTPS, any data exchanged during the TLS handshake, which is usually not very relevant for identifying anything significant
All of that information is voluntarily provided by the requesting client.
I was just wondering this small little question. I know it is irreverent to coding, but I just had to know quickly.
If you type in http:// for a https:// will it still take you to the correct place?
That is mostly dependent on the server configuration. The server has to accept the initial HTTP request and be configured to redirect the client to an appropriate HTTPS url.
That being said, there are some Internet standards related to automating HTTP-to-HTTPS upgrades. HTTP Strict Transport Security and Upgrade Insecure Requests allow an HTTP/S server to tell clients that it wants them to automatically use HTTPS for all subsequent requests. If a client visits an HSTS/UIR-enabled server, it will receive a normal HTTP response with additional HSTS/UIR-related headers. If the client supports HSTS/UIR, it will then know to automatically send all subsequent HTTP requests to that same server using HTTPS, and in the case of UIR also treat any received HTTP URLs as if they were HTTPS URLs.
Imagine a webbrowser that makes an HTTP request to a remote server, such as site.example.com
If the browser is then configured to use a proxy server, let's call it proxy.example.com using port 8080, in which ways are the request now different?
Obviously the request is now sent to proxy.example.com:8080, but there must surely be other changes to enable the proxy to make a request to the original url?
RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, Section 5.3.2. absolute-form:
When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target
URI in absolute-form as the request-target.
absolute-form = absolute-URI
The proxy is requested to either service that request from a valid
cache, if possible, or make the same request on the client's behalf
to either the next inbound proxy server or directly to the origin
server indicated by the request-target. Requirements on such
"forwarding" of messages are defined in Section 5.7.
An example absolute-form of request-line would be:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
So, without proxy, the connection is made to www.example.org:80:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org
With proxy it is made to proxy.example.com:8080:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org
Where in the latter case the Host header is optional (for HTTP/1.0 clients), and must be recalculated by the proxy anyway.
The proxy simply makes the request on behalf of the original client. Hence the name "proxy", the same meaning as in legalese. The browser sends their request to the proxy, the proxy makes a request to the requested server (or not, depending on whether the proxy wants to forward this request or deny it), the server returns a response to the proxy, the proxy returns the response to the original client. There's no fundamental difference in what the server will see, except for the fact that the originating client will appear to be the proxy server. The proxy may or may not alter the request, and it may or may not cache it; meaning the server may not receive a request at all if the proxy decides to deliver a cached version instead.