General Troubleshooting

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:

For Micosoft Entra ID (Azure AD):

For Google:

Resolution

By default, Datawiza Access Proxy utilizes the following format for the IdP login redirect URL: Application URL + /datawiza/authorization-code/callback. For example, if the Application URL is https://test.datawiza.com, then the redirect URL should be https://test.datawiza.com/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 Deployments page.

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

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

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

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:

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:

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:

Endpoint	Use
/datawiza/.auth/me	Return the basic user info including username, groups, email, first name, and last name.
/datawiza/.auth/me?includeToken=true	Return access token, access token expire time, id token, and refresh token besides basic user info.
/datawiza/ab-userinfo	Return 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.

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.

In addition, it is possible to verify header-based authentication for your applications leveraging browser extensions like 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: test@example.com' http(s)://your-application

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

HTTP/HTTPS

Currently, we only support Enable SSL and use datawiza self-signed certificate from getting-started.

You need to set HTTPS after finishing the getting-started configuration for production:

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

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:

You can see SSL Configuration for more details.