620200137e
- Rearranged navigation significantly
- Navbar is now unlimited width on desktop
- Navbar is now always on top of the screen, even on the landing page
- Navbar has been replaced with hamburger menu on mobile
- Significant styling alterations to look good on phones tm
- Most of the credit goes to a certain meta tag.
- (Appearance on desktop is mostly unchanged)
- The background on mobile is now 100% image, but darkened to improve contrast
- Table pages such as /links/ and /stats/ now rearrange on mobile:
column a column a column b
column b vs column a column b
column a column a column b
column b column a column b
- font size on landing page scales with device width on tall displays
- guestbook posts use CSS grid now
- Working on a @media (prefers-contrast: more) theme as well. Can't figure out how to test it though
- Updated /stats/
- Added some new stats
- Updated CD collection size
- Updated /about/uses/
- I now use Nextcloud News instead of Yarr
- My phone runs Graphene
- I use Fennec browser on mobile instead of standard Firefox
- New background as the old one was horrible for contrast
- Added Waxlimbs - For Science! to /about/music/
- The oldest three articles on /blog/ now show a warning on hover that they're from the legacy v2 site
- Corrected various markup issues with the help of validator.w3.org/nu/
- Added alt text to a ton of images
- todo list is no longer a separate html file. it was fucking with the scaling on mobile and I couldn't be bothered
- /stuff/ remains unchanged. I'll get to it
- Hopefully that's everything lol
70 lines
4.2 KiB
HTML
70 lines
4.2 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<title>Guide - How to Block User Agents With Nginx</title>
|
|
<link href="../../../style.css" rel="stylesheet" type="text/css" media="all">
|
|
<style>
|
|
h1 {
|
|
background-image: url('nginx.svg');
|
|
}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<h1>guide:</h1>
|
|
<h2 id="caption">How to Block User Agents With Nginx</h2>
|
|
<nav>
|
|
<a href="../../../">home</a>
|
|
<a href="../../">blog</a>
|
|
</nav>
|
|
<p>Recently, Cloudflare has launched a clumsy, poorly-executed attempt to centralize the fediverse on their platform known as Wildebeest. There are <a href="https://blog.cloudflare.com/welcome-to-wildebeest-the-fediverse-on-cloudflare/" title="This one's kind of a joke, but it explains in detail just how much Wildebeest is fundamentally dependent on Cloudflare's platform, and if you agree with me about anything you should already know why that's bad.">a</a> <a href="https://stop.voring.me/notes/9bka8dyjjo" title="Gleason, of getting-kicked-off-the-dev-team-for-the-fedi-server-he-created-for-sucking-so-much fame, is now contributing code to Wildebeest.">few</a> <a href="https://glitterkitten.co.uk/@doot/109910496299181873" title="This one's the most important. Wildebeest literally just publically displays messages marked as direct. Think admins being able to read your "direct messages" was bad? Try everyone.">reasons</a> not to want to use it, and you probably don't want to be federating with it either. However, blocking every instance running it on sight would be both tedious and ineffective.</p>
|
|
<p>The way I've chosen to deal with this is to just configure my reverse proxy, Nginx, to deny connections from anything with "wildebeest" in the user agent string. There are several other good reasons to do this, such as blocking bots that ignore robots.txt, or adapting this approach to serve specialized pages to old browsers, or just denying access to anything that isn't Chrome if you want to earn your place in the 9th circle of Hell.</p>
|
|
<p>I'm assuming here that you already know the basics of configuring Nginx, otherwise this article won't really be of much use to you.</p>
|
|
<h2>How to do it</h2>
|
|
<p>Paste this into the main <code>server</code> block of your Nginx config to instantly drop the connection to any client with a "Wildebeest" (case insensitive) user agent:</p>
|
|
<code>
|
|
<span class="codetitle">/etc/nginx/sites-available/yoursite</span>
|
|
if ($http_user_agent ~* (wildebeest)) {<br>
|
|
return 444;<br>
|
|
}
|
|
</code>
|
|
<h2>More configuration</h2>
|
|
<p>If all you want is to block Wildebeest and forget about it, you can leave now. If you want to customize this behavior further, read on.</p>
|
|
<h3>Different HTTP responses</h3>
|
|
<p>444 is a custom response code in Nginx that just drops the connection immediately. You can use any other HTTP error code you like, for example to return a <code>403 Forbidden</code> error:</p>
|
|
<code>
|
|
return 403;
|
|
</code>
|
|
<p>To issue a permanent redirect to some other URL:</p>
|
|
<code>
|
|
return 301 https://example.org/;
|
|
</code>
|
|
<p>Or just to be silly :3</p>
|
|
<code>
|
|
return 418;
|
|
</code>
|
|
<h3>Block multiple user agents</h3>
|
|
<p>You can also block multiple user agents in one statement like so:</p>
|
|
<code>
|
|
<span class="codetitle">/etc/nginx/sites-available/yoursite</span>
|
|
if ($http_user_agent ~* (wildebeest|googlebot)) {<br>
|
|
return 444;<br>
|
|
}
|
|
</code>
|
|
<h3>Includes</h3>
|
|
<p>One thing I'd recommend doing is moving all your user agent blocks to a separate file that you can include in all your Nginx sites. I place this file at <code>/etc/nginx/includes/bans</code>:</p>
|
|
<code>
|
|
<span class="codetitle">/etc/nginx/includes/bans</span>
|
|
if ($http_user_agent ~* (wildebeest|googlebot)) {<br>
|
|
return 444;<br>
|
|
}
|
|
</code>
|
|
<code>
|
|
<span class="codetitle">/etc/nginx/sites-available/yoursite</span>
|
|
include /etc/nginx/includes/bans;
|
|
</code>
|
|
<p>The <code>include</code> statement goes in your <code>server</code> block as before.</p>
|
|
</body>
|
|
</html>
|