Skip to main content

General Troubleshooting

About 3 min

Redirect URL does not match

One usual Identity Provider (IdP) misconfiguration is the incorrect setting of the redirect URI in your IdP. You will encounter the IdP error page in such instances:

For Okta: okta redirect url not match

For Azure AD aad redirect url not match

For Google: google redirect url not match


By default, Datawiza Access Proxy utilizes the following format for the IdP login redirect URL: public domain + /datawiza/authorization-code/callback. Please verify this value in your IdP settings console to ensure it aligns correctly.

Datawiza Access Proxy configuration applied failed

Once the initiation or updates to the Datawiza Access Proxy (DAP) are complete, the status of this process can be tracked on the Datawiza Cloud Management Console Deploymentsopen in new window page.

This page displays Notifications updates related to configuration application outcomes, encompassing both DAP launch and configuration updates. config applied list

If DAP applied the new configurations successfully, you could see the Notifications and Status below: config applied success

However, if the DAP fails to apply the new configurations, different Notifications and Status updates will be visible, as illustrated below: config applied failed

A common instance of failure could be due to the provided domain name for the upstream server not being resolvable. The tool nslookup can verify domain name resolution:

nslookup your-service-domain-name

Alternatively, Docker's exec command can also be used:

docker exec -it datawiza-access-proxy nslookup your-service-domain-name.

In a scenario where the upstream server's DNS name can be resolved, but the IP address remains inaccessible, a 5xx error will be displayed after login. On the DCMC, this issue does not display under Notifications as "configuration applied failed". Instead, it is manifested under Status as a WARNING situation. Moreover, you can scout for a note that reads Upstream is unavailable: config applied failed reason

For a more comprehensive troubleshoot, you can access more details by clicking on the deployment. This will provide granular information such as the specific upstream of the DAP that is unreachable: upstream-unreachable

It's essential to note that this type of situation may occur if the resolved address of the upstream service undergoes changes. Restarting the DAP can help update the resolving address.

Troubleshooting endpoints

If you encounter difficulties receiving headers or configuring user attributes, you can utilize the following debug endpoints to assist with your diagnosis:

/datawiza/.auth/meReturn the basic user info including username, groups, email, first name, and last name.
/datawiza/.auth/me?includeToken=trueReturn access token, access token expire time, id token, and refresh token besides basic user info.
/datawiza/ab-userinfoReturn two types of user info: oauth_user_info returns all user profiles DAP can get, and user_info returns basic user info.

Build-in testing application and Attribute Pass debugging

We offer a built-in service on port 9902 specifically designed for attribute pass testing. To proceed, modify the upstream server configuration to point to http://localhost:9902, and ensure that you include the necessary attribute pass in your setup. upstream-unreachable

After a successful login, the user information should be displayed. Additionally, you'll find an option to view the raw request headers that will be sent to the upstream services by clicking on Raw. upstream-unreachableupstream-unreachable

In addition, it is possible to verify header-based authentication for your applications leveraging browser extensions like ModHeaderopen in new window. modheader Alternatively, the -H command-line option in Curl can also be employed to carry out this task. By using the 'Key: Value' format, you can easily send an HTTP header within your Curl request. Here's an illustrative example:

curl -H 'x-dw-user: true' -H 'email:' http(s)://your-application

In this command, x-dw-user and email are header names with respective values true and which are sent along with the request to your application.


Since we do not provide any HTTPS configuration other than the public domain from getting-started, you need to set HTTPS after finishing the getting-started configuration: upstream-unreachable

If you did not set SSL but accessed the application URl, you would see the error page: upstream-unreachable

On the flip side, if you configure the SSL settings but attempt to access the URL using the http://your-host protocol, you'll encounter a 400 error. This error will be accompanied by an error page resembling the following: upstream-unreachable

You can see SSL Configuration for more details.