Allow/Deny IP on OpenLiteSpeed - litespeed

I want only allow from 127.0.0.1/localhost/0.0.0.0, but i tried with Access Control and .htaccess
And
order deny, allow
deny from all
allow from 127.0.0.1
Its doesnt work!

That deny allow rule won't work in OpenLiteSpeed.
For access control , make sure you have empty server-level access control list , and vhost -level won't override it.
[root#test ~]# cat /etc/hosts
127.0.0.1 mask.domain
[root#test ~]# curl -I -XGET http://mask.domain
HTTP/1.1 200 OK
Etag: "5-5d42a8ce-e18f0;;;"
Last-Modified: Thu, 01 Aug 2019 08:54:38 GMT
Content-Type: text/html
Content-Length: 5
Accept-Ranges: bytes
Date: Thu, 01 Aug 2019 08:58:50 GMT
Server: LiteSpeed
Connection: Keep-Alive
[root#test ~]# echo "123.456.789.000 mask.domain" > /etc/hosts
[root#test ~]# curl -I -XGET http://mask.domain
HTTP/1.1 403 Forbidden
Content-Type: text/html
Cache-Control: private, no-cache, max-age=0
Pragma: no-cache
Content-Length: 1139
Date: Thu, 01 Aug 2019 08:59:14 GMT
Server: LiteSpeed
Connection: Keep-Alive
The access control works on me , when I use hosts file to set to 127.0.0.1 - domain , it's 200 OK , and when I set it with public IP , it goes to 403 error.
Alternative way:
Use rewrite rule , like this:
RewriteEngine On
RewriteCond %{REMOTE_HOST} !^127\.0\.0\.1
RewriteRule .* - [F]
If you are going to use rewrite rule , make sure you have restarted OpenLiteSpeed once you changed the rules.
Best regards,

Related

.htaccess block wp-json

I have one normal Wordpress website on which I am trying to block requests to wp-json. I am aware that such requests go via the core of the Wordpress. My request looks like this:
[root#SV-CentOS-01 ~]# curl -i https://www.website.com/wp-json/wp/v2/users/1
When I add RewriteRule ^wp-json.*$ - [L,R=404] on top of my htaccess I get 404 server response and the API returns me the users of my website. Is there actually a way to achieve what I want via .htaccess or we need to make it the Wordpress way?
Example:
[root#SV-CentOS-01 ~]# curl -i https://www.website.com/wp-json/wp/v2/users/1
HTTP/1.1 404 Not Found
Date: Mon, 20 Sep 2021 14:14:13 GMT
Server: Apache
Vary: Accept-Encoding,Cookie,Origin
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Robots-Tag: noindex
Link: <https://www.website.com/wp-json/>; rel="https://api.w.org/"
X-Content-Type-Options: nosniff
Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages, Link
Access-Control-Allow-Headers: Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, Content-Type
Allow: GET
Set-Cookie: PHPSESSID=5c07eaa455457ca0ef4b358d016c3b8d; path=/
Upgrade: h2,h2c
Connection: Upgrade
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
{"id":1,"name":"User One","url":"","description":"","link":"https:\/\/www.website.com\/author\/admin\/","slug":"admin","meta":[],"_links":{"self":[{"href":"https:\/\/www.website.com\/wp-json\/wp\/v2\/users\/1"}],"collection":[{"href":"https:\/\/www.website.com\/wp-json\/wp\/v2\/users"}]}}[root#SV-CentOS-01 ~]#

Celery or urllib3 is redirecting me to https

I have a problem with making requests trough urllib3. So, I'm connecting through proxy and running script trough celery.
urllib3 setup:
self.http = urllib3.ProxyManager('http://127.0.0.1:24000')
Urllib3 request:
page = self.http.request('get', self.start_url, headers=self.headers)
And after that I see in celery logs something like this:
[2019-11-19 16:13:54,038: INFO/ForkPoolWorker-2] Redirecting http://www.olx.pl/nieruchomosci/mieszkania/wynajem/wroclaw/ -> https://www.olx.pl/nieruchomosci/mieszkania/wynajem/wroclaw/
How can I disable this redirect?
It's not urllib3 or celery, it's the remote server.
$ curl -D- http://www.olx.pl/nieruchomosci/mieszkania/wynajem/wroclaw/
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Location: https://www.olx.pl/nieruchomosci/mieszkania/wynajem/wroclaw/
Expires: Tue, 19 Nov 2019 16:33:49 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Tue, 19 Nov 2019 16:33:49 GMT
Connection: keep-alive
Server: OLXcdn
X-T: True
As you can see there the server is redirecting you to HTTPS, so you can't disable this on the client side.

nginx not returning Cache-Control header from upstream gunicorn

I'm using WhiteNoise to serve static files from a Django app running under gunicorn. For some reason, the Cache-Control and Access-Control-Allow-Origin headers returned by the gunicorn backend are not being passed back to the client through the nginx proxy.
Here's what the response looks like for a sample request to the gunicorn backend:
% curl -I -H "host: www.myhost.com" -H "X-Forwarded-Proto: https" http://localhost:8000/static/img/sample-image.1bca02e3206a.jpg
HTTP/1.1 200 OK
Server: gunicorn/19.8.1
Date: Mon, 02 Jul 2018 14:20:42 GMT
Connection: close
Content-Length: 76640
Last-Modified: Mon, 18 Jun 2018 09:04:15 GMT
Access-Control-Allow-Origin: *
Cache-Control: max-age=315360000, public, immutable
Content-Type: image/jpeg
When I make a request for the same file via the nginx server, the two headers are missing.
% curl -I -H "Host: www.myhost.com" -k https://my.server.com/static/img/sample-image.1bca02e3206a.jpg
HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Mon, 02 Jul 2018 14:09:25 GMT
Content-Type: image/jpeg
Content-Length: 76640
Last-Modified: Mon, 18 Jun 2018 09:04:15 GMT
Connection: keep-alive
ETag: "5b27758f-12b60"
Accept-Ranges: bytes
My nginx config is pretty much what is documented in the gunicorn deployment docs, i.e. I haven't enabled nginx caching (nginx -T | grep -i cache is empty) or done anything else I would think is out of the ordinary.
What am I missing?
The problem is that you have
location / {
try_files $uri #proxy_to_app;
}
directive in nginx config, so nginx just serves files himself and gunicorn doesn't even knows about it, and of course can't add headers.
It turns out I had forgotten the root directive I had configured many months ago, which was now picking up the static files. My error was in assuming that since I hadn't configured a location /static directive, nginx would be proxying all requests to the backend.
The solution for me was to remove the $uri reference from the try_files directive:
location / {
try_files /dev/null #proxy_to_app;
}
Alternatively, I could have simply put the contents of the #proxy_to_app location block directly inside the location / block.
Thanks to Alexandr Tatarinov for the suggestion in the comments.

Apache LocationMatch everything but root

I'm reading that <Location '/'> actually matches the entire domain, not just the root location. I want to create a Location or LocationMatch block that matches everything but http://my.domain.com/ This means it will trigger if any characters follow that final '/
Here is how I will be testing this:
<LocationMatch "REGEX GOES HERE">
AuthType Shibboleth
ShibRequireSession On
Require Shibboleth
</LocationMatch>
I think Shibboleth may change some behavior. Also note I am using Apache 2.2 but a solution that works on 2.4 will suffice as well.
You can use LocationMatch with this regex:
<LocationMatch "^/.">
</LocationMatch>
Single DOT after ^/ will make sure there is at least one character after http://my.domain.com/ hence causing it to not to match landing page.
More details about LocationMatch
Testing:
Create this directive as:
<LocationMatch "^/(?<sitename>.+)">
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI}?u=%{env:MATCH_SITENAME} [L,R=302]
</LocationMatch>
Now to test I am doing this:
curl -kI -A "Chrome" -L 'http://localhost/index.php'
HTTP/1.1 302 Found
Date: Mon, 11 Jul 2016 22:31:37 GMT
Server: Apache/2.4.12 (Unix) OpenSSL/1.0.1j PHP/5.6.9 mod_wsgi/3.5 Python/2.7.9
Location: http://www.localhost/index.php?u=index.php
Content-Type: text/html; charset=iso-8859-1
HTTP/1.1 200 OK
Date: Mon, 11 Jul 2016 22:31:37 GMT
Server: Apache/2.4.12 (Unix) OpenSSL/1.0.1j PHP/5.6.9 mod_wsgi/3.5 Python/2.7.9
X-Powered-By: PHP/5.6.9
Content-Type: text/html; charset=UTF-8
curl -kI -A "Chrome" -L 'http://localhost/user.php'
HTTP/1.1 302 Found
Date: Mon, 11 Jul 2016 22:33:57 GMT
Server: Apache/2.4.12 (Unix) OpenSSL/1.0.1j PHP/5.6.9 mod_wsgi/3.5 Python/2.7.9
Location: http://www.localhost/user.php?u=user.php
Content-Type: text/html; charset=iso-8859-1
HTTP/1.1 200 OK
Date: Mon, 11 Jul 2016 22:33:57 GMT
Server: Apache/2.4.12 (Unix) OpenSSL/1.0.1j PHP/5.6.9 mod_wsgi/3.5 Python/2.7.9
X-Powered-By: PHP/5.6.9
Content-Type: text/html; charset=UTF-8
curl -kI -A "Chrome" -L 'http://localhost'
HTTP/1.1 200 OK
Date: Mon, 11 Jul 2016 22:32:47 GMT
Server: Apache/2.4.12 (Unix) OpenSSL/1.0.1j PHP/5.6.9 mod_wsgi/3.5 Python/2.7.9
X-Powered-By: PHP/5.6.9
Content-Type: text/html; charset=UTF-8
You can clearly see that www redirection doesn't happen when I request landing page but happens when I request /index.php

Infinite redirect loop after cloning Heroku Rails app and putting on new domain with SSL

So here's the situation: I have a heroku rails app (let's call it original_app) sitting on a custom domain sitting at http://www.originaldomain.com. It is a standard Rails 4.2.0 app running on PG/Passenger/Nginx. The domain is hosted on DNSimple (with the root domain aliased to the Heroku SSL endpoint and the www CNAMEd to the endpoint) and it has an approved SSL certificate. The production.rb file forces the app to remain in SSL. This app works fine, without any problems.
THEN, I used the heroku fork command to "clone" the original_app to an identical app on heroku called, say, new_app. I purchased an SSL certificate from Godaddy for www.newdomain.com and provisioned it on the heroku SSL endpoint addon. The domain newdomain.com is hosted on AWS's Route 53 service. Because they don't allow for redirecting of the root (a.k.a. "zone apex"), I used a workaround detailed here [https://devcenter.heroku.com/articles/route-53] (which was a solution to a similar question posted on stack overflow) to alias newdomain.com root to www.newdomain.com via A record alias to an S3 bucket that redirects to www.newdomain.com. Meanwhile, on Route 53, www.newdomain.com redirects to the Heroku SSL endpoint URL.
PROBLEM: Whenever I access https://www.newdomain.com/somepath, I get a "too many redirects" error from the browser. Strangely enough, if I access the app directly at https://new_app.herokuapp.com, it works like a charm. And so does the original app. How is this possible if they're all identical?
Additional details:
The home page works (e.g. https://www.newdomain.com/) because it is actually a static page hosted on a github.io repository. The rails app redirects to it and other static pages via a Rack::ReverseProxy in config.ru. It's the non-static pages that are the problem.
If I do a wget command it shows the redirections bouncing back and forth between AWS (presumably Route53 and/or S3) and the Heroku Nginx/Passenger server. Here is an excerpt of the log:
bash
$ wget --server-response https://www.newdomain.com/somepath -O -
--2015-09-13 02:09:22-- https://www.newdomain.com/somepath
Resolving www.newdomain.com... [IP address hidden for SO], [IP address hidden for SO]
Connecting to www.newdomain.com|[IP address hidden for SO]|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Type: text/html
Transfer-Encoding: chunked
Status: 301 Moved Permanently
Cache-Control: no-cache
Strict-Transport-Security: max-age=31536000
X-Request-Id: 164c641d-c1f9-432b-aead-236dffa931a4
Location: http://newdomain.com/somepath
X-Runtime: 0.003392
Date: Sun, 13 Sep 2015 06:09:22 GMT
X-Powered-By: Phusion Passenger 5.0.6
Server: nginx/1.6.2 + Phusion Passenger 5.0.6
Via: 1.1 vegur
Location: http://newdomain.com/somepath [following]
--2015-09-13 02:09:22-- http://newdomain.com/somepath
Resolving newdomain.com... [IP address hidden for SO]
Connecting to newdomain.com|[IP address hidden for SO]|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 301 Moved Permanently
x-amz-id-2: tk7HsFoqcqgMtLwtofrFIE1ob1+gP50m1k6yo3f4Prinufu5w4R6lrsvPexFiCAyDSCO1c/OKwU=
x-amz-request-id: 9357AE308083C80D
Date: Sun, 13 Sep 2015 06:09:24 GMT
Location: http://www.newdomain.com/somepath
Content-Length: 0
Server: AmazonS3
Location: http://www.newdomain.com/somepath [following]
--2015-09-13 02:09:23-- http://www.newdomain.com/somepath
Connecting to www.newdomain.com|[IP address hidden for SO]|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Type: text/html
Content-Length: 0
Status: 301 Moved Permanently
Location: https://www.newdomain.com/somepath
Date: Sun, 13 Sep 2015 06:09:23 GMT
X-Powered-By: Phusion Passenger 5.0.6
Server: nginx/1.6.2 + Phusion Passenger 5.0.6
Via: 1.1 vegur
Location: https://www.newdomain.com/somepath [following]
--2015-09-13 02:09:23-- https://www.newdomain.com/somepath
Connecting to www.newdomain.com|[IP address hidden for SO]|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Type: text/html
Transfer-Encoding: chunked
Status: 301 Moved Permanently
Cache-Control: no-cache
Strict-Transport-Security: max-age=31536000
X-Request-Id: daf02b75-0d2d-4880-8a3d-e61b648d2a86
Location: http://newdomain.com/somepath
X-Runtime: 0.003992
Date: Sun, 13 Sep 2015 06:09:23 GMT
X-Powered-By: Phusion Passenger 5.0.6
Server: nginx/1.6.2 + Phusion Passenger 5.0.6
Via: 1.1 vegur
Location: http://newdomain.com/somepath [following]
--2015-09-13 02:09:23-- http://newdomain.com/somepath
Connecting to newdomain.com|[IP address hidden for SO]|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 301 Moved Permanently
x-amz-id-2: uyB1ckI+koqGzKFjTVLatqpJ0cpgAjubGpla62w+8yKpz363FTv6ogtQuzo8tibKKyjAM4X7k3I=
x-amz-request-id: BED63CC152C82099
Date: Sun, 13 Sep 2015 06:09:24 GMT
Location: http://www.newdomain.com/somepath
Content-Length: 0
Server: AmazonS3
Location: http://www.newdomain.com/somepath [following]
--2015-09-13 02:09:23-- http://www.newdomain.com/somepath
Connecting to www.newdomain.com|[IP address hidden for SO]|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Type: text/html
Content-Length: 0
Status: 301 Moved Permanently
Location: https://www.newdomain.com/somepath
Date: Sun, 13 Sep 2015 06:09:23 GMT
X-Powered-By: Phusion Passenger 5.0.6
Server: nginx/1.6.2 + Phusion Passenger 5.0.6
Via: 1.1 vegur
Please let me know if I can provide more details.