Skip to main content


reshared this

in reply to pasjrwoctx👽

Could this be implemented as an add-on? I think it should be possible

reshared this

in reply to Carlos Solís

@Carlos Solís I have no idea about making it an addon, personally I think that defeats the purpose, as this really acts like the first line of defense after .htaccess rules, before anything else even happens, at least that is how I saw it working;

reshared this

in reply to pasjrwoctx👽

@pasjrwoctx👽 I did not test it yet, but I believe you should exclude the /inbox route e.g. too?

reshared this

in reply to Melanie Wehowski

@Melanie Wehowski the only reason to exclude the /inbox route is if you are finding a lot of bots and scrapers accessing your inbox before they scrape your profile, in theory friendicas rules and activitypubs rules should already have your inbox blocked from that activity, I created this because even with a very robust .htaccess file I was getting a lot of bots and scrapers accessing "GET" and "Profile" in my access logs, most where defeating my robots.txt and breaking the rules in .htaccess, this at the moment has killed them, first 2 days they all got 403's and then they just stopped trolling my instance at all; I think it could be customized to your individual needs, I made it shareable, I wont maintain it, it works for me and if by chance it helps anyone well all the better, by all means adapt and modify it to your instance's needs and if it works share it with the community, security and privacy in numbers I say;

reshared this

in reply to pasjrwoctx👽

@pasjrwoctx👽 Sorry, I mean the /inbox route from the check

$is_fediverse =
str_contains($request, '/.well-known/') ||
str_contains($request, '/activitypub/') ||
str_contains($request, '/api/') ||
str_contains($request, '/assets/') ||
str_contains($request, '/inbox');

You could also check for Request-Type headers.

A cookie can be faked, you should consider to store the OK in the session instead?

reshared this

in reply to Melanie Wehowski

@Melanie Wehowski cookie could be faked but so can headers, and the way I have it now the cookie is only good for the session, bots and scrapers start a new session every time they probe a domain so no need to store, each time they troll its a new session, putting inbox in the check I guess could be useful to gate it, but when I sat down to do this and dug through all my access logs I did not have even one call for the inbox to be worried about it, now if I get bots or scrapers that start calling for my inbox I will gate it, but my understanding of how friendica and activitypub are setup the inbox should not be callable by bots and scrapers, I maybe wrong on that, I have had this instance up an running a year, and it has be en a lot of learning and trial and error so many errors, but so far this gate has really made my access logs go empty, which for me is good, im still fully federated but the datahogs have slowed or stopped trolling me

reshared this

in reply to Melanie Wehowski

@Melanie Wehowski also if you wanted to go that far as adding /inbox following the logic you should probably also add /nodeinfo as well;

reshared this

in reply to pasjrwoctx👽

@pasjrwoctx👽 You are right, sorry I did not read the complete code, I was in $is_fediverse =... line.
if ($request === '/' makes it clear, sorry!
$is_fediverse and is_static is not necessary then?

reshared this

in reply to pasjrwoctx👽

@pasjrwoctx👽

cookie could be faked but so can headers, and the way I have it now the cookie is only good for the session, bots and scrapers start a new session every time


The sessionID is in the cookie yes, but the info can be in the session. If a bad bot starts a new session, well it will not have the "OK" in the session.
Accept headers can be faked but that would make less sense as it breaks content negotiation, and you can use it as ONE aspect of other bot indicators.

, but my understanding of how friendica and activitypub are setup the inbox should not be callable by bots and scrapers


For server to server protocol an instance will act like a "legitim bot", it will not pass a captcha or session check, validation of the request is done via signatures.

reshared this

in reply to Melanie Wehowski

@Melanie Wehowski the other reason I elected to not have a server side stored is one privacy of actual humans that visit my site directly, and I just rather not be collecting useless data on a fairly restricted shared hosting environment, I am sure with a little time and a bit more effort on my part I could build fort knox around my instance, but the whole point of this was to cut down on the constant abusive bots and scrappers, and at this time it appears to have worked or is working as is;

reshared this

in reply to pasjrwoctx👽

@pasjrwoctx👽 to fend off bots I use anubis which I have placed in front of Friendica.

reshared this