403 forbidden on API calls to adguard store about os-scripts HOT 21 CLOSED

Okay, mystery solved, in my case, I need both Powershell Core and to Jump on VPN, I am blocking some things on my home network, but nothing specific to russia, its possible some of the pfBlockerNG rule sets are blocking commination when it sent over API. Honestly, I would have never guessed, the site works normally from a browser, but I have enough information that I can work around it and possibly fix it later for good. When I am finished with my current project, I will circle back and see if I can write a check for that and share it with you.

from os-scripts.

Yes, that fixes it!! Line 98 I do beleive
-UserAgent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36"

Notably, I use cloudflare for DNS, domains, proxy service, but do not do webscraping. I will take some time to see if I can figure that our, but I think setting the agent will be a net win for just about anyone using the script.

Thanks again Andrew, this was fun. I will return the favor by refactoring some of this code in the future, but I have a sea of stuff I need to refactor before I will be done.

from os-scripts.

This is now working in both Powershell 5 and Powershell Core. Nicely done Andrew.

from os-scripts.

What package were you trying to download?? Have you tried other packages?

from os-scripts.

Just took a quick look myself, and I'm guessing the API is now requiring more information to be sent in with API requests, I'll see what I can do the next time I have free time to work on this.

from os-scripts.

@agentoranger I'm unsure if it affected it, but I did realized the changed function name I gave it (Get-AppxPackage) was technically already used by PowerShell by default to list packages on the machine, so I renamed it back to what I originally had it as (Download-AppxPackage).

I tested it today, and it seems to be working fine. If you're still getting 403 errors when trying to download a package, let me know what region your ISP is from, and test to confirm you can even access the adgaurd.net website from your internet.

Additionally, let me know what package you're trying to download.

But for now, I'm going to go ahead and close this ticket.

from os-scripts.

I'm not certain the real cause, but I went ahead tried the updated code and I am seeing a similar error, like what is shown in the screenshot above. Perhaps the API is restricted based on geo location, I am in the United states.

I worked around it using the code found on this project
https://dev.to/antidisestablishmentarianism/powershell-script-to-download-appx-files-from-the-microsoft-store-for-currently-installed-packages-501e

I do plan to dig into the windows update method to see if I can select a specific package by name as your original script intends to do. In this case, I have reviewed similar scripts that attempt to use adguard and I experience a similar problem resulting in 403.

I don't think the issue is exclusive to your code.

I would totally understand if you do not have time to look into this further, it was nice of you try to resolve the issue, and I appreciate your time.

from os-scripts.

I just attempted the same connection from vpn in Germany and the issue persists, perhaps that was not a great guess on my part.

from os-scripts.

I just attempted the same connection from vpn in Germany and the issue persists, perhaps that was not a great guess on my part.

My ISP is based in the US, so it couldn't be quite that.

However, although rg-adguard uses a .net domain suffix, it's API is hosted on Russian servers. So, if you are using a company device, or some sort of personal antivirus, that blocks connections to Russian websites, that's the more likely reason why you're getting a 403 error.

from os-scripts.

I ran another test in powershell core, which I dont use very often and seen a new result, I will investigate this more in time:

from os-scripts.

I ran another test in powershell core, which I dont use very often and seen a new result, I will investigate this more in time:

Yes, this is normally what I get, if I try running the script at my place of work (which does block Russian websites).

That's why I assume it's something on your end also blocking the API.

from os-scripts.

Do you have ipv6 working at your location?

from os-scripts.

Do you have ipv6 working at your location?

That's actually a good point, I think mine mainly goes through ipv4, so I suppose I might just need to force the script to make the API requests stay on ipv4 somehow.

from os-scripts.

I will try that, standby

from os-scripts.

I will try that, standby

See what [Net.ServicePointManager]::SecurityProtocol displays when running it from Windows PowerShell (v5.1), and then again from Core.

from os-scripts.

Is it not related to ipv6, I was able to confirm that.

Windows Powershell

Powershell Core

from os-scripts.

Tls12 and Tls13 does not change the outcome, this is continuing to look like a blocked IP or URL when over VPN the issue does not occur on default, Tls12 or Tls13

from os-scripts.

Tls12 and Tls13 does not change the outcome, this is continuing to look like a blocked IP or URL when over VPN the issue does not occur on default, Tls12 or Tls13

I was able to figure something else out, it looks like the API is hosted through CloudFlare. I'm guessing it's not liking your IP, assuming you probably do a lot of webscraping already.

Edit the script at the Invoke-RestMethod line, and include the following at the end of it: -UserAgent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36"

Let me know if that changes the results when ran in either PowerShell version

from os-scripts.

Yes, that fixes it!! Line 98 I do beleive -UserAgent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36"

Alright, that clears up the issue then, so it just means I need to use a UA other than PowerShell, luckily that should be an easy fix.

from os-scripts.

This issue is closed, Andrew is the man. certifiably.

from os-scripts.

This issue is closed, Andrew is the man. certifiably.

I updated the script on my end, test the new script to see if that works (trying to use the built in Chrome UA that powershell has). If that works then great, if not, then I'll need to code in a little extra bits to grab the latest UA from somewhere online.

from os-scripts.