#5340 The 'fedora-web/websites' page omits a '/' in the URL when viewing source, thereby giving a 403 error
Opened a year ago by lcoogan. Modified a year ago

On https://getfedora.org, scrolling to the bottom of the page and clicking the hyperlink 'websites team' takes you to "https://pagure.io/fedora-web/websites/". That's intended behaviour.

Now, try clicking the 'Source' tab from that page, or from any page in the 'fedora-web/websites' repo. The new URL is "https://pagure.io/fedora-web/websites", which gives a '403 Forbidden' error. The difference is that the final '/' is absent in the latter URL.

The 'fedora-web/websites' repo is the only one I've encountered this bug on. On other pagure repos, clicking 'Source' works fine, even though the link generated also omits the final '/'.


I can confirm the behavior, accessing https://pagure.io/fedora-web/websites throws a forbidden error, https://pagure.io/fedora-web/websites/ (trailing slash) works just fine.

That's something one of the pagure.io admins (I'm only aware of @pingou) need to check, probably something odd with folder permissions or something.

This is not actually due to any bug in pagure, it's because there's a DDoS that is hitting https://pagure.io/fedora-web/websites but not https://pagure.io/fedora-web/websites/
So, I set our webserver to reject it to avoid bringing pagure.io down.

I can try and change it back again, but the last time I did the DDoS started up again. ;(

Thanks @kevin, didn't realized that there is already an Issue open: https://pagure.io/pagure/issue/5317

I removed the block 3 hours ago and so far it's fine.

So, perhaps we can close both these if it stays that way.

I removed the block 3 hours ago and so far it's fine.

So, perhaps we can close both these if it stays that way.

I've started getting a lot of error emails from the website project on pagure. I
think the DDOS attempt is back :(

I guess it's not on bad intention and probably the requests always come from the same source? Do you want dig deeper and maybe even try to get in touch with whoever fires all the requests to find a solution? Maybe it's just some CI or scripting that went bad? Or re-activate the rule and leave it as "works as designed" for this specific repo?

Sorry no, they are Distributed, so it comes from a vast pool of different IPs.
They also use lots of different user agents, so I can't block on that. :(

@pingou is it still erroring?

@pingou is it still erroring?

Last night it was I think, I'll monitor it today and report

@pingou is it still erroring?

Definitely still happening :(

I put the perm denied back in place.

I'm open on other ideas on how to solve this, but I am not sure what it would be.

I'm open on other ideas on how to solve this, but I am not sure what it would be.

Came across this Article yesterday, sounds somehow similar: https://utcc.utoronto.ca/~cks/space/blog/web/AggressiveStealthyWebSpider

@pingou can you share some data?
How much requests per second is coming?
How much requests per second is the limit for Pagure?
Are requests anonymous or with cookies?
What is IP distribution between provider pools?

@pingou can you share some data?
How much requests per second is coming?
How much requests per second is the limit for Pagure?
Are requests anonymous or with cookies?
What is IP distribution between provider pools?

No idea on all of these :)
I only see the error emails coming from a connection pool max'ed out error to
connect to the DB

I see there is no Logging & Monitoring chapter at https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/ Maybe worth to add one to collect metrics for things like this?

No idea on all of these :)
I only see the error emails coming from a connection pool max'ed out error to
connect to the DB

Could we increase this limit?

Login to comment on this ticket.

Metadata