Issues with the Woosage50Service Connecting to the Website

Issues with the Woosage50Service Connecting to the Website

Occasionally, Woosage50 encounters issue when the Woosage50Service tires to connect to the website. This is usually due to website or server security measures and common causes and solutions are:

  1. Server/site blocks API requests - solution is to is usually to whitelist  the IP address, Woosage endpoints or user agent (see below).
  2. Site is password protected - some methods of protecting a site from access (e.g. during development) will also block API access. If the the site has password protection via the .htaccess file this will block the Woosage API, so must be disabled.
  3. Server blocks Woosage API - this is less common and may require investigation by your website hosting provider (see note highlighted below).
Further guidance on how to resolve specific issues are shown below:
  1. Website caches APIs – solution is cache plugin dependant (more information in this article).
  2. Website blocks API requests - the solution is usually to whitelist the IP address, Woosage endpoints or Woosage user agent, as follows:
    1. Whitelist the IP address of the location where the Woosage50Service is installed (only applies if location has a static IP address, which business broadband usually does).
    2. Whitelist the Woosage API endpoints which will allow Woosage through, but still block others. Woosage endpoints are of the form https://[site-name]/wp-json/woosage/* (* is wildcard, which may be different, depending on security plugin)
    3. Whitelist Woosage User Agent - solution is security plugin dependant, but add Woosage/50 as an allowed user agent. If the problems persists try changing the UserAgent key in the appsettings.json file to one of the common browser user agents, such as Mozilla/5.0, AppleWebKit/537.36, Chrome/126.0.0.0 or Safari/537.36
  3. Website doesn’t allow basic authentication method – solution if to set service to authenticate using OAuth 1.0 instead of passing credentials as parameters. To do this open the file C:\Program Files \Woosage50Service\Woosage50Service\appsettings.json in Notepad, or a similar txt editor, as an Administrator, locate the the WcRestOptions section and change UseOAuth1 key value to true.
  4. Captcha mechanisms - these can be implemented on the server or website and are used block non-human traffic. API requests are often detected by captcha mechanisms and blocked.  Resolving this issue will depending the type of captcha and where is is implemented, but will usually involves whitelisting the IP address, Woosage endpoints or Woosage user agent as covered in Website block API requests above.
  5. Local DNS override - A local DNS setting for the website address will override the IP address set in the domain DNS records. To check/amend local settings:
    1. On Windows Server use Windows Administrative Tools > DNS
    2. On Windows 10/11 use Notepad (run as Administrator) to open C:\Windows\System32\drivers\etc\hosts (no extension)
Alert
Note: Following a change to hosting services using Google Cloud Services in December 2025 the following issues were experienced
A new ModSecurity rule was  introduced that uses derived information about the source of a website request based on a “fingerprint” (JA4) and the rule determined that Woosage is presenting as “PowerShell-like”, which is being treated as malicious.  PowerShell is part of Microsoft .Net and is a scripting tool that can be used by hackers, so Woosage was being blocked following this change.

The Woosage50Service is built using the .Net framework so we cannot change how it is being presented (the fingerprint it is derived from multiple pieces of information about the applications environment), so the solution is to request that the web host or server provider does one of the following.
  1. Disable the rule for the IP address where the Woosage50Service is installed (Allowlist by IP) – PREFERRED OPTION (static IP address only)  
  2. Disable the rule for Woosage API endpoints [website-url]/wp-json/woosage/v1/[wildcard]   
  3. Adjust the rule to equate to “PowerShell-like JA4” ≠ “malicious”
  4. Disable the rule for the entire website