I need to make a transparent redirect (without the user seeing the address change in the address bar). When the user types example.com he/she should be redirected to 123.123.123.123:9090 (IP:PORT). I cannot use CNAME or A cause it does not accept the PORT. How can I do that? I know that using SRV I can do that but my webserver does not allow it.
I also tried using THE mod_proxy on Apache to rewrite the request from domain example.com -> 123.123.123.123:9090 however it is absurd cause the user requests the content, the apache requests the content to my IP and after that the response has to go up all way back. I need the user request to reach the webserver directly without proxy.
Well, DNS doesn't care about ports, only about hostnames. Thats why you can access every server like example.com:8080 (will probably fail for 99% of all servers though ;)). So what should happen when I try to request your site via example.com:8080? Does port 8080, or 9090 takes precedence?
Long story short: There is no way around a proxy. But easier would be to let it listen on port 80 directly.
Related
I've searched a lot but I couldn't find a PHP proxy server which can be run on a shared host, so I decided to build a very simple one from scratch but I'm still on the first step. I've created a subdomain httpp.alvandsoft.com and also redirected all its subdirectories (REQUEST_URI) to the main index.php to be logged and to know what whould a proxy server exactly receive and send
(The log is accessible through https://httpp.alvandsoft.com/?log=1&log_filename=log.txt)
But whenever I set it as a proxy for Telegram or other apps, it doesn't receive ANY requests at all, even when I use 443 or 80 ports, neither in different proxies such as HTTP, SOCKS or MTPROTO.
Is proxy something that depends on the server's settings and works in a way other than regular HTTP requests and responses or I'm missing something?
I found it out myself. HTTP(s) proxies send their requested URL as Host request header and many hosts and websites, check this request header and if it's not a member of their valid IPs, redirect it immediately.
Problem
I am facing a unique problem here. I have a nginx server with an admin panel (admin.example.com). Now I want to allow only specific IP addresses to access that server and I know that we can do that through nginx allow and deny tag. But that approach is quite difficult for non-technical users and would require access to the server itself to make the change and then reload nginx. The purpose is to make it easy for anyone to whitelist IP addresses.
Solution
We came up with a UI app.example.com (hosted on a different server) to allow manage the IP addresses. Now I want to route all (admin.example.com) requests through this new server which will check if the IP is allowed then proxy the request to admin.example.com otherwise deny the access.
Question
My question is how do we route all the requests through app.example.com and once the IP has been verified only then forward the request to the origin which is admin.example.com here?
If it is possible through the nginx reverse proxy then do I need to process the request through a local upstream such as PHP or python and then forward the request after the verification?
Anyone example with pseudo code for nginx configuration will be highly appreciated.
I know services like Cloudflare does it but I need only a basic setup.
This is what I wanted How do I make web service calls within nginx? . Another approach is to use the Openresty lua JIT to preprocess the request and then forward it to the reverse proxy.
https://openresty.org/en/
How would this have to be created if possible? Can it only be created in cPanel, or is it possible to make a script for users to use without logging into cPanel that allows them to make their domain?
That should be possible depending on your hosting / server setup:
Add a wildcard domain CNAME record *.yourdomain.com;
Use a rewrite rule to direct all traffic to anything.yourdomain.com to a php script to handle the requests;
Do whatever you want in your php script: Use a header redirect, present another page in an iframe, etc.
A subdomain is just an entry in the DNS server configuration. Likely you'll be able to update the configuration by adding a bunch of lines in a file, or a new file altogether. This really depends on the DNS server software, maybe the one you use also has an API to be updated via a TCP socket.
Also if the target IP is shared (and thus you use name-based virtual host), or it's a different one, maybe you want an HTTP server listening on the port 80 on that IP.
I'm doing a PHP cURL post, using a complete URL (http://www.mysite.com), from one page to another on the same site. (I know this isn't the best way to do it; but for my purpose this is what I need)
My question is:
Will the cURL post still go out across the internet, do a name lookup and travel a route as though it were a post coming from a different site. Or will the post stay on the servers local network?
There are multiple parts to the request, the dns lookup and the get or post to the site.
DNS Records are usually cached on most OSes, so it's rather unlikely that the server would have to do a dns lookup for it's own external ip, but it's possible.
As for the post, let's assume a basic layout:
Firewall => DMZ Apache PHP Server (www.mysite.com)
222.xxx.xxx.123 => 192.168.0.2
And mysite.com resolves to 222.xxx.xxx.123, then your request will go to your firewall's external interface and bounce back in. That's not terribly public traffic, but it goes out none-the less.
However, if you wanted to bypass that, you could put an entry in the host file of the server to say
127.0.0.1 mysite.com
(assuming you control the server, ie not shared hosting)
No. The post itself (unless you have multiple interfaces and your routing is totally screwed up) will not traverse the internet. Your local host ought to be able to resolve its own name as well, but there is a possibility that a DNS request will be made to determine the IP address corresponding to the name. I would hope that the network stack implementation on your system would prevent the post's packets from even hitting the wire (similar to localhost), but I wouldn't count on it.
It depends on your network setup. Many sites have a domain name pointing to the IP address of a front facing router or load balancer which forward the request to the web server.
If that's the case a request to your own site can make a round-trip to the router. Though it's unlikely that the request will go through the internet unless you have a very unusual setup (such as round robin DNS with multiple datacenters).
You can avoid the round-trip by associating the site FQDN to the loopback interface in your webserver /etc/hosts which will also save you a DNS request.
So kind of very similar to "Detecting https requests in php":
Want to have https://example.com/pog.php go to http://example.com/pog.php or even vice versa.
Problems:
Can't read anything from $_SERVER["HTTPS"] since it's not there
Server is sending both requests over port 80, so can't check for 443 on the HTTPS version
apache_request_headers() and apache_response_headers() are sending back the same thing
Can't tell the loadbalancer anything or have it send extra somethings
Server feedback data spat out by the page on both URL calls is exactly the same save for the session ID. Bummer.
Are there any on page ways to detect if it's being called via SSL or non-SSL?
Edit: $_SERVER["HTTPS"] isn't there, switched on or not, no matter if you're looking at the site via SSL or non-SSL. For some reason the hosting has chosen to serve all the HTTPS requests encrypted, but down port 80. And thusly, the $_SERVER["HTTPS"] is never on, not there, just no helpful feedback on that server point. So that parameter is always be empty.
(And yeah, that means it gets flagged in say FF or Chrome for a partially invalid SSL certificate. But that part doesn't matter.)
Also, the most that can be gotten from detecting the URL is up to the point of the slashes. The PHP can't see if the request has https or http at the front.
Keyword -- Load Balancer
The problem boils down to the fact that the load balancer is handling SSL encryption/decryption and it is completely transparent to the webserver.
Request: Client -> 443or80 -> loadbalancer -> 80 -> php
Response: PHP -> 80 -> loadbalancer -> 443or80 -> Client
The real question here is "do you have control over the load balancer configuration?"
If you do, there are a couple ways to handle it. Configure the load balancer to have seperate service definitions for HTTP and HTTPS. Then send HTTP traffic to port 80 of the web servers, and HTTPS traffic to port 81 of the webservers. (port 81 is not used by anything else).
In apache, configure two different virtual hosts:
<VirtualHost 1.2.3.4:80>
ServerName foo.com
SetEnv USING_HTTPS 0
...
</VirtualHost>
<VirtualHost 1.2.3.4:81>
ServerName foo.com
SetEnv USING_HTTPS 1
...
</VirtualHost>
Then, the environment variable USING_HTTPS will be either 1|0, depending on which virtual host picked it up. That will be available in the $_SERVER array in PHP. Isn't that cool?
If you do not have access to the Load Balancer configuration, then things are a bit trickier. There will not be a way to definitively know if you are using HTTP or HTTPS, because HTTP and HTTPS are protocols. They specify how to connect and what format to send information across, but in either case, you are using HTTP 1.1 to make the request. There is no information in the actual request to say if it is HTTP or HTTPS.
But don't lose heart. There are a couple of ideas.
The 6th parameter to PHP's setcookie() function can instruct a client to send the cookie ONLY over HTTPS connections (http://www.php.net/setcookie). Perhaps you could set a cookie with this parameter and then check for it on subsequent requests?
Another possibility would be to use JavaScript to update the links on each page depending on the protocol (adding a GET parameter).
(neither of the above would be bullet proof)
Another pragmatic option would be to get your SSL on a different domain, such as secure.foo.com. Then you could resort to the VirtualHost trick above.
I know this isn't the easiest issue because I deal with it during the day (load balanced web cluster behind a Cisco CSS load balancer with SSL module).
Finally, you can always take the perspective that your web app should switch to SSL mode when needed, and trust the users NOT to move it back (after all, it is their data on the line (usually)).
Hope it helps a bit.
$_SERVER["HTTPS"] isn't there, switched on or not, no matter if you're looking at the site via SSL or non-SSL. For some reason the hosting has chosen to serve all the HTTPS requests encrypted, but down port 80. And thusly, the $_SERVER["HTTPS"] is never on, not there, just no helpful feedback on that server point. So that parameter is always be empty.
You gotta make sure that the provider has the following line in the VHOST entry for your site: SSLOptions +StdEnvVars. That line tells Apache to include the SSL variables in the environment for your scripts (PHP).