EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #10137

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] DDoS of EPrints advanced search

CAUTION: This e-mail originated outside the University of Southampton.

Metacpan itself has been up and down a lot too recently:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmetacpan%2Fmetacpan-k8s%2Fissues%2F154&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7Cf1e2cfc0d3414bd03b9608dda8f6a78c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638852499494944147%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fGHcOQlyvcxlDMDp2FoTOY7sRhuPek%2FtvOa1nvwLHpw%3D&reserved=0

Yours,
Andrew.

Quoting Matthew Kerwin <matthew.kerwin@qut.edu.au>:


CAUTION: This e-mail originated outside the University of Southampton.

CAUTION: This e-mail originated outside the University of Southampton.

Hi Florian,


may I ask how you try that? I wonder if browsers can disregard zhis
due to privacy extensions or settings when there is a e.g. <meta
name="referer" content="always"> hint in the page, rendering them
users unable to use your search altogether.


I've only ensured the server instructs browsers; they don't have to
comply. I actually send a standard Referrer-Policy header value in
the HTTP response: `origin-when-cross-origin` [1]. We use this a bit
across the university; the majority of our users navigate between
sites within the organisation so it's sometimes useful to see when
someone has come to eprints from somewhere, or vice versa.

I would be surprised if any browser extension redacted Referer
values even within a single origin/site, that's pretty paranoid.

In any case, when I have to choose between: a) some users can't
search my site because they have personal reasons to not be able to
comply with some technical requirements, but they can still browse;
vs b) malicious – or at least pathological – robots have crashed my
server making it entirely unusable for everyone; I'll opt for
solution (a). I still know of users who entirely disable javascript,
so a bunch of functionality is broken for them. That is their choice
and their prerogative; they just can't expect everything to continue
to work the same way.

Cheers

1:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FReference%2FHeaders%2FReferrer-Policy&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7Cf1e2cfc0d3414bd03b9608dda8f6a78c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638852499494962821%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kDnz%2Fjku%2FMeJnJWYNCti9pEq2BXu0hF%2F0YZaZHKh7cY%3D&reserved=0

--
Matty Kerwin (he/him)
Software Engineer
Education & Research
Digital Business Solutions

Queensland University of Technology
Email: matthew.kerwin@qut.edu.au
KG-X232, Kelvin Grove Campus