I have many requests get\post from different ip with the browser Mozilla 5.0 compatible MSIE 9.0 on the main page of website. I don't want to block Mozilla fully, I need to block only this occurance. Can I do it?
In my apache logs it looks like:
172.68.25.54 - - [19/Sep/2018:18:00:32 +0300] "GET / HTTP/1.0" 200 11059 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0)"
If I use this rule:
BrowserMatchNoCase "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0)" bad_br
Deny from env=bad_br
It doesn't work, I think it's just because of un-quoted string or something else...
The first parameter of BrowserMatchNoCase is not an ordinary string but a regex (regular expression). Bracket symbols are the special symbols in regex and need to be escaped with backslash if you want to match them in a string:
BrowserMatchNoCase "Mozilla/5.0 \(compatible; MSIE 9.0; Windows NT 6.0\)" bad_br
Related
I'm configuring two Domains to host two websites: dev.example.com and test.example.com
I'm using Nginx as a webserver and my websites, dev and test, are configured with server_name directive as two separate websites sharing the same host Public_IP
When I connect to both domains using a VPN_Public_IP I get response 'websites' from Nginx as Expected
When I connect to both domains using my personal router Public-IP I only get a response from https://dev.example.com, while access_log of https://test.example.com shows this access_log which means the request has reached the server. But with empty error_log and no response in my Browser:
Personal_Router_Pub_IP - - [17/Feb/2022:07:02 +0000] "GET / HTTP/2.0" 200 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98 Safari/537.36"
Is it a Domain-blacklisting issue or Client-IP-blacklisting issue, and how to identify the problem here?
Yesh the issue was that the domain is blacklisted by Router ISP following the regulations of UAE where I reside
I want to force redirect HTTP to HTTPS via htaccess. Of course I looked for a tons of solutions here, but nothing helps. On other hosting this solution works but not here.
If I try it this way:
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
It will redirect to HTTPs, but then it says the page is not working, TOO many redirects.
But I have nothing more in my htaccess, so why too many redirects?
Another solution that works not:
RewriteCond %{HTTP:HTTPS} !on [OR]
RewriteCond %{HTTP_HOST} ^example.com
RewriteRule (.*) https://www.example.com/$1 [R=301,QSA]
Here is the dump of $_SERVER:
HTTP:
PHP_FCGI_CHILDREN: 0
SCRIPT_NAME: /test2.php
REQUEST_URI: /test2.php
QUERY_STRING:
REQUEST_METHOD: GET
SERVER_PROTOCOL: HTTP/1.0
GATEWAY_INTERFACE: CGI/1.1
REDIRECT_URL: /test2.php
REMOTE_PORT: 50086
SCRIPT_FILENAME: /hosting/www/.../test2.php
SERVER_ADMIN: admin#...
REQUEST_SCHEME: http
DOCUMENT_ROOT: /hosting/www/example.com/
REMOTE_ADDR: 178.41.4.145
SERVER_PORT: 80
SERVER_ADDR: 178.238.37.248
SERVER_NAME: www.example.com
SERVER_SOFTWARE: Apache
SERVER_SIGNATURE:
HTTP_ACCEPT_LANGUAGE: sk,en;q=0.9,en-GB;q=0.8,en-US;q=0.7,cs;q=0.6
HTTP_ACCEPT_ENCODING: gzip, deflate
HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.80 Safari/537.36 Edg/98.0.1108.50
HTTP_UPGRADE_INSECURE_REQUESTS: 1
HTTP_CACHE_CONTROL: max-age=0
HTTP_CONNECTION: close
HTTP_HOST: www.example.com
HTTP_AUTHORIZATION:
BACKEND_NAME: httpd1
HOSTNAME: lucy.onebit.cz
UNIQUE_ID: Yg_Luo5QXSFkFIZSmZji5AAAAMk
REDIRECT_STATUS: 200
REDIRECT_BACKEND_NAME: httpd1
REDIRECT_HOSTNAME: lucy.onebit.cz
REDIRECT_UNIQUE_ID: Yg_Luo5QXSFkFIZSmZji5AAAAMk
PHP_SELF: /test2.php
REQUEST_TIME_FLOAT: 1645202362.2178
REQUEST_TIME: 1645202362
URL: /test2.php
STATUS: 200
And HTTPS:
PHP_FCGI_CHILDREN: 0
SCRIPT_NAME: /test2.php
REQUEST_URI: /test2.php
QUERY_STRING:
REQUEST_METHOD: GET
SERVER_PROTOCOL: HTTP/1.0
GATEWAY_INTERFACE: CGI/1.1
REDIRECT_URL: /test2.php
REMOTE_PORT: 51668
SCRIPT_FILENAME: /hosting/www/example.com/www/test2.php
SERVER_ADMIN: admin#...
REQUEST_SCHEME: http
DOCUMENT_ROOT: /hosting/www/example.com/
REMOTE_ADDR: 178.41.4.145
SERVER_PORT: 443
SERVER_ADDR: 178.238.37.248
SERVER_NAME: www.example.com
SERVER_SOFTWARE: Apache
SERVER_SIGNATURE:
HTTP_ACCEPT_LANGUAGE: sk,en;q=0.9,en-GB;q=0.8,en-US;q=0.7,cs;q=0.6
HTTP_ACCEPT_ENCODING: gzip, deflate, br
HTTP_SEC_FETCH_DEST: document
HTTP_SEC_FETCH_USER: ?1
HTTP_SEC_FETCH_MODE: navigate
HTTP_SEC_FETCH_SITE: none
HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.80 Safari/537.36 Edg/98.0.1108.50
HTTP_UPGRADE_INSECURE_REQUESTS: 1
HTTP_SEC_CH_UA_PLATFORM: "Windows"
HTTP_SEC_CH_UA_MOBILE: ?0
HTTP_SEC_CH_UA: " Not A;Brand";v="99", "Chromium";v="98", "Microsoft Edge";v="98"
HTTP_CONNECTION: close
HTTP_HOST: www.example.com
HTTP_AUTHORIZATION:
BACKEND_NAME: httpd1
HOSTNAME: lucy.onebit.cz
HTTPS: on
force_response_1_0: 1
downgrade_1_0: 1
ssl_unclean_shutdown: 1
nokeepalive: 1
Front_End_Https: on
UNIQUE_ID: Yg_L4xNbf-I51ics4Sn1UQAAAdM
REDIRECT_STATUS: 200
REDIRECT_BACKEND_NAME: httpd1
REDIRECT_HOSTNAME: lucy.onebit.cz
REDIRECT_HTTPS: on
REDIRECT_force_response_1_0: 1
REDIRECT_downgrade_1_0: 1
REDIRECT_ssl_unclean_shutdown: 1
REDIRECT_nokeepalive: 1
REDIRECT_Front_End_Https: on
REDIRECT_UNIQUE_ID: Yg_L4xNbf-I51ics4Sn1UQAAAdM
PHP_SELF: /test2.php
REQUEST_TIME_FLOAT: 1645202403.7653
REQUEST_TIME: 1645202403
HTTP_FRONT_END_HTTPS: on
URL: /test2.php
STATUS: 200
But I think, the problem is with Mod rewrite disabled.
If mod_rewrite was disabled (and .htaccess overrides are enabled) then you'd get a 500 Internal Server Error, not a redirect loop.
You'll get a redirect loop if another service is managing the SSL connection with the client (eg. front-end proxy, load balancer, CDN, etc.) and your application server is connecting via insecure HTTP to this other service. (Not uncommon.)
Check the HTTP request headers reaching your application server, do you see an X-Forwarded-Proto header? This would indicate the application server is behind a front-end proxy that manages the SSL connection. In which case, you could do something like the following instead:
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
NB: Test first with 302 (temporary) redirects to avoid potential caching issues.
You will need to clear your browser cache before testing.
However, this could also be host-specific. Some shared hosts set an HTTPS environment variable (not to be confused with the HTTPS Apache server variable as used in your first example), so you could also try something like the following:
RewriteCond %{ENV:HTTPS} =off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
UPDATE: Based on the output from the PHP $_SERVER superglobal, try the following instead:
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Reasoning behind this... there is no HTTPS array index at all when requesting over HTTP and it is set to on when requesting over HTTPS. This must be an environment variable (set by the host), not an Apache server variable, since a server variable would always be set.
Aside: The two conditions in the rules above (ie. %{HTTP:X-Forwarded-Proto} =http and %{ENV:HTTPS} =off) would simply fail (since neither of these are set) and the rule would do nothing.
NB: You must test first with a 302 (temporary) redirect and ensure the browser cache is clear before testing.
I have a frontend running on AWS and a backend on Heroku. As such, users access a login page on AWS, make a request to login via the API on Heroku, and should get a cookie back with a session id. I have read all about CORS and even CORS + cookies, but still cannot successfully set a cookie through CORS (or at least I certainly cannot verify if I did via Chrome dev tools, and my Heroku app sure doesn't read any request header cookies). I am using fastify + fastify-cors + fastify-cookie
When running in dev environment, my frontend is https://localhost:3000 while the back is https://localhost:80
When I login, I should get back a cookie from the API # localhost:80. This is the response headers (ignore content length, I trimmed the session id for this question)
HTTP/1.1 200 OK
vary: Origin
access-control-allow-origin: https://localhost:3000
access-control-allow-credentials: true
set-cookie: session_id=66f9c629644b890fefaa9b4c58a10666; Max-Age=31536000; HttpOnly; Secure; SameSite=None
content-type: application/json; charset=utf-8
content-length: 587
Date: Tue, 02 Feb 2021 05:18:38 GMT
Connection: keep-alive
Keep-Alive: timeout=5
I followed this guide https://cors-errors.info/faq#cdc8
When I refresh the page, I should attempt to login via cookies. But my API at localhost:80 receives no cookies at all. This is what a login request via cookies looks like. Not sure if I should see some cookies being sent, but if I should, I presume they were never saved to the browser anyways.
POST /users/login/session HTTP/1.1
Host: localhost:80
Connection: keep-alive
Content-Length: 0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Accept: */*
Origin: https://localhost:3000
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Not sure what else to do at this point...
I believe adding path=/ and removing domain finally fixed everything.
I have three virtual hosts on apache2 web server.
Two of them use perl scripts that are working perfectly.
The third I just created with EXACTLY THE SAME configuration concerning the ScriptAlias directive
Number one: working
ScriptAlias /cgi-bin/ "/www/old/uep/cgi-bin/"
Number two: working
ScriptAlias /cgi-bin/ "/www/cssm/formulaire/cgi-bin/"
Number three: not working
(the perl script is about to be downloaded instead of being executed as the two others)
ScriptAlias /cgi-bin/ "/www/cssm/juin2019/cgi-bin/"
All the hosts are configured the same, all the scripts have sufficient rights to be executed, but only the last can not be executed.
Checked logs: no errors, the access log file indicates GET concerning the script with .pl extension and with execution permission.
Emptied the browser cache (everything).
Kompared the three involved .conf files in /etc/apache2/vhosts.d
All of the three .conf files are the same, with no difference but the path and the error/access log names.
I use the following settings in the three .conf files concerning the main directory
Options Indexes FollowSymLinks
IndexOptions +Charset=UTF-8 NameWidth=*
I don't use symbolic links in the path.
In the HTML file I use a FORM for one of the two site that are working, and a direct link /cgi-bin/forum.pl for the other working site.
NOT WORKING:
192.168.0.4 - - [02/Apr/2019:19:32:54 +0200] "GET /cgi-bin/examenjuin.pl HTTP/1.1" 304 - "http://www.examenjuin2019.cssm/" "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0"
WORKING:
192.168.0.4 - - [02/Apr/2019:19:51:38 +0200] "GET /cgi-bin/forum.pl HTTP/1.1" 200 2209 "http://www.uepsoundsystem.dezordi.world/" "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0"
Can not understand why two perl scripts in different folders with exactly the same permissions are working and this one can't...
If it is not your script producing the 304 status code, it is your server configuration.
On Apache, play around with mod_cache settings to prevent your server from sending them.
How to redirect to another website with basic auth (in node)
Here is my code
const headers = {
Authorization: "Basic " +
new Buffer(USER + ":" + PASS).toString("base64")
};
ctx.response.set(headers);
ctx.response.redirect(URL)
The First Response return with basic auth
Authorization →Basic QWRxXxXxYWRtaW4=
Connection →keep-alive
Content-Length →111
Content-Type →text/html; charset=utf-8
Date →Fri, 15 Dec 2017 21:49:57 GMT
Location →http://localhost:8080/edit/data/P0000013
The following redirected GET request doesn't contain basic auth and got redirected again, to a log-in page.
# General
Request URL:http://localhost:8080/edit/data/P0000013
Request Method:GET
Status Code:302 Found
Remote Address:[::1]:8080
Referrer Policy:no-referrer-when-downgrade
# Request Header
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.9
Connection:keep-alive
Cookie:....
Host:localhost:8080
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
You can specify username & password as part of URL:
ctx.redirect('http://username:password#example.com');
You CANNOT redirect with attached headers (including basic auth), HTTP protocol doesn't support it.
But you can put your basic auth key/value pair in the new url as an argument:
HTTP/1.x 302 Found
Location: /api?auth=asdf
Or save it in cookies
HTTP/1.x 302 Found
Location: /api
Set-Cookie: auth=asdf