¶ How to Resolve 403 Forbidden Errors in OnDemand Dev Environments
This wiki article provides steps to diagnose and resolve HTTP 403 Forbidden errors when creating new cases or performing similar actions in the OnDemand Dev environment.
A 403 Forbidden error indicates that the server understands your request but refuses to authorize it. In the context of the OnDemand Dev environment, you might see a message like:
POST https://acme.com/VenioOnDemandAPI/vod/services/cases 403
When this happens, the user cannot create a new case, or other functionality requiring server access fails.
- Firewall Settings: If your organization uses a Web Application Firewall (WAF), it may be blocking traffic from your new URL or domain.
- Outdated Rules: After changing domains (e.g., from
roddev02.ricohdiscovery.com to dev.arrayondemand.com), any security settings tied to the old domain or IP address might cause the new requests to be rejected.
- Domain Not Resolving: If DNS records for the new domain (e.g.,
dev.arrayondemand.com) are not fully propagated, some users may see 403 or other errors.
- Typos in URLs: A slight mismatch—such as
acme.com instead of amce.com—can result in request failures.
- web.config or Database Settings: If the
tbl_pj_ControlSetting or web.config references outdated or incorrect URLs, the server may respond with a 403 Forbidden.
- Check WAF Configuration: Confirm your Web Application Firewall is updated to allow traffic from the new domain.
- Disable Temporarily: If possible, disable or bypass the firewall temporarily to test whether the 403 error disappears.
- DNS Propagation: Use a tool (e.g., DNSChecker.org) to ensure the new domain resolves correctly worldwide.
- Correct Domain Spelling: Ensure there are no typos such as
amce.com instead of acme.com.
- Propagation Time: DNS changes can take up to 24–48 hours, depending on your DNS provider’s TTL (Time To Live).
¶ 3.3 Review Server and Application Config
- web.config / tbl_pj_ControlSetting: Confirm any references to the base URLs (e.g.,
WEB_BASE_URL, VOD_API_URL) match the new domain exactly.
- Environment Variables: If your application reads domain or API paths from environment variables, verify they are up to date.
- Restart Services: After making changes, restart IIS or the relevant services to ensure the new configs are loaded.
- Bearer Token Validity: If the environment or domain changed, your application’s authentication tokens might no longer be valid.
- CORS Policy: Ensure the server-side CORS settings allow requests from the new domain.
- Logs: Check the server event logs for token validation errors or audience mismatch warnings.
- Load Balancer / Reverse Proxy: Confirm any load balancer or proxy has been updated to forward requests to the correct new domain without rewriting or filtering requests.
- IP Whitelists: Some environments block access by default, so ensure the new domain or IP is whitelisted across all security systems.
A real-world example:
- The client transitioned from
acme.com to coyote.com.
- The Web Application Firewall rules still referenced the old domain, resulting in 403 Forbidden for new case creation.
- Once the WAF configuration was updated (or temporarily disabled to confirm the cause), the error disappeared, and case creation worked normally.
- Test in Multiple Regions: If possible, test DNS from different geographical locations to confirm propagation.
- Retain Logs: Keep a record of server logs, especially around request failures, to pinpoint the root cause faster.
- Communication is Key: Coordinate with all stakeholders—DevOps, security teams, network admins—to ensure each layer of the environment is configured properly.
A 403 Forbidden error in OnDemand Dev environments often stems from mismatched domain settings or firewall/security rules. By verifying your WAF configuration, DNS records, server settings, and authentication tokens, you can quickly identify and resolve the underlying cause. If these steps don’t solve the issue, consult your server event logs or engage with the support team for deeper troubleshooting.