Open chezzer64 opened 3 weeks ago
Think it looks like SourceForge has added some 'anti-web scraping' protection?
Have tested a workaround by adding some additional headers to the request but not sure how long they will continue to be successful?
$headers = @{ 'Accept' = "text/html,application/xhtml+xml,application/xml;q=0.9" 'Accept-Language' = "en-US,en;q=0.9" 'Sec-Ch-Ua-Platform' = "Windows" }
Update: Workaround appears to have already stopped working unfortunately.
I don't have a kind word to say about SourceForge, so I'll attempt some restraint. I do however, wish developers would stop using it.
Hi everyone,
at the moment it works for me when I use TLS 1.3 in my Windows PowerShell (5.1) scripts. So just adding "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls13" at the beginning should work already. I guess .NET 4.8 should be installed upfront when using this on older systems as Windows Server 2016. But I did not test this on older OS. My Server 2022 deployments just work fine now.
@aaronparker I absolutly agree about SF. But nobody knows what Microsoft will do, if everybody moves things to Github. Possible Vendor-lock-in incoming ....
Andre
Using something like the below code was working about two days ago, however, this too is failing.
I'll test with TLS 1.3
$session = New-Object Microsoft.PowerShell.Commands.WebRequestSession
$session.UserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0"
$session.Cookies.Add((New-Object System.Net.Cookie("VISITOR", "010663f5-784c-4b89-95b3-b94caeb35ef9", "/", "sourceforge.net")))
$session.Cookies.Add((New-Object System.Net.Cookie("__cf_bm", "757znJGmuebOAc5M59hKsO28h_ubXpvGGcDYocIlwX0-1730205433-1.0.1.1-VpbSE2aiIXI17YraYEUFZL6BKHo73NgKSDsxGrYdMyjwIphBVXE43T05YKDzuRWP9sjXYzacGHBMHYrFVUOxTQ", "/", ".sourceforge.net")))
Invoke-WebRequest -UseBasicParsing -Uri "https://sourceforge.net/projects/keepass/best_release.json" `
-WebSession $session `
-Headers @{
"authority"="sourceforge.net"
"method"="GET"
"path"="/projects/keepass/best_release.json"
"scheme"="https"
"accept"="text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7"
"accept-encoding"="gzip, deflate, br, zstd"
"accept-language"="en-AU,en-GB;q=0.9,en;q=0.8,en-US;q=0.7"
"cache-control"="max-age=0"
"dnt"="1"
"priority"="u=0, i"
"sec-ch-ua"="`"Chromium`";v=`"130`", `"Microsoft Edge`";v=`"130`", `"Not?A_Brand`";v=`"99`""
"sec-ch-ua-mobile"="?0"
"sec-ch-ua-platform"="`"macOS`""
"sec-fetch-dest"="document"
"sec-fetch-mode"="navigate"
"sec-fetch-site"="none"
"sec-fetch-user"="?1"
"upgrade-insecure-requests"="1"
}
Maybe they had too many issues with regular user requests using specific filters or probably a "scoring system". I bet they saw in the logs that many PowerShell-Sessions used TLS 1.2 and use this as a filter now.
To be safe one could determine a current Chrome version to assemble a custom UserAgent (and setting $DownloadUserAgent upfront) and just use that with TLS 1.3 on top so they can't detect PowerShell directly :-)
I've pushed a change to the Apps
branch that includes a custom useragent for SourceForge requests. Looks OK to me here in PowerShell 5.1 on Windows 10, and PowerShell on macOS.
I've added this change to a new module version to see whether it helps, so should be ready to test now
What happened?
All Evergreen apps hosted on SourceForge are currently returning '403 Forbidden'
Version
2410.1527
What PowerShell edition/s are you running Evergreen on?
Windows PowerShell
Which operating system/s are you running Evergreen on?
Windows 10+
Have you reviewed the documentation?
Verbose output