Encountering a 500 Error When Retrieving Users from a Misconfigured User Store

[melanisilva]

Describe the issue:

When a user selects a misconfigured User store from the User store dropdown on the Users page, an "Something went wrong" error is displayed.

How to reproduce:

1. Create a read/write LDAP user store
2. configure the Userstore with default configs (According to IS Docs.)
3. Go to the Users page
4. select the newly created User store from the user store dropdown.

https://github.com/wso2/product-is/assets/41188245/f7218bfc-a42c-411e-9408-974b3efba31b

Expected behavior:

The UI should not display an Error page saying something went wrong. (Suggestion - Can display "No users found" message like we follow on Asgardeo)

Environment information (Please complete the following information; remove any unnecessary fields) :

• Product Version: IS 7.0.0 M2
• OS: mac
• Database: H2
• Userstore: LDAP

---

Optional Fields

Related issues:

Suggested labels:

[pavinduLakshan]

To clearly identify that the 500 error occurs due to a misconfigured userstore from the frontend, the API should capture the scenario and send a proper error code. The current error response sent from the backend (pasted below) does not have such an error code.

{
    "config": {
        "transitional": {
            "silentJSONParsing": true,
            "forcedJSONParsing": true,
            "clarifyTimeoutError": false
        },
        "transformRequest": [
            null
        ],
        "transformResponse": [
            null
        ],
        "timeout": 0,
        "xsrfCookieName": "XSRF-TOKEN",
        "xsrfHeaderName": "X-XSRF-TOKEN",
        "maxContentLength": -1,
        "maxBodyLength": -1,
        "headers": {
            "Accept": "application/json, text/plain, */*",
            "Access-Control-Allow-Origin": "https://localhost:9001",
            "Authorization": "Bearer 5baca0f2-a178-31bd-a245-8c748df2e54d"
        },
        "withCredentials": true,
        "method": "get",
        "params": {
            "attributes": "name,emails,userName,profileUrl,meta.lastModified",
            "count": 11,
            "domain": "saml4547",
            "filter": null,
            "startIndex": 0
        },
        "url": "https://localhost:9443/scim2/Users",
        "startTimeInMs": 1696844565811
    },
    "request": {},
    "response": {
        "data": {
            "schemas": [
                "urn:ietf:params:scim:api:messages:2.0:Error"
            ],
            "detail": "Error while retrieving users for the domain: saml4547 with limit: 11 and offset: 1.",
            "status": "500"
        },
        "status": 500,
        "statusText": "",
        "headers": {
            "cache-control": "private",
            "content-length": "169",
            "content-type": "application/scim+json"
        },
        "config": {
            "transitional": {
                "silentJSONParsing": true,
                "forcedJSONParsing": true,
                "clarifyTimeoutError": false
            },
            "transformRequest": [
                null
            ],
            "transformResponse": [
                null
            ],
            "timeout": 0,
            "xsrfCookieName": "XSRF-TOKEN",
            "xsrfHeaderName": "X-XSRF-TOKEN",
            "maxContentLength": -1,
            "maxBodyLength": -1,
            "headers": {
                "Accept": "application/json, text/plain, */*",
                "Access-Control-Allow-Origin": "https://localhost:9001",
                "Authorization": "Bearer 5baca0f2-a178-31bd-a245-8c748df2e54d"
            },
            "withCredentials": true,
            "method": "get",
            "params": {
                "attributes": "name,emails,userName,profileUrl,meta.lastModified",
                "count": 11,
                "domain": "saml4547",
                "filter": null,
                "startIndex": 0
            },
            "url": "https://localhost:9443/scim2/Users",
            "startTimeInMs": 1696844565811
        },
        "request": {}
    },
    "isAxiosError": true
}

[pavinduLakshan]

In asgardeo, GET /users for a misconfigured userstore returns an empty list whereas the same on on-prem throws a 500 error, hence the something went wrong screen. The backend impl therefore needs to be improved to match asgardeo API behaviour, to deliver a unified experience.

[chamathns]

In asgardeo, GET /users for a misconfigured userstore returns an empty list whereas the same on on-prem throws a 500 error, hence the something went wrong screen. The backend impl therefore needs to be improved to match asgardeo API behaviour, to deliver a unified experience.

If the user store is misconfigured, it is incorrect to send a 200 response and return an empty list. What should happen is, it should throw an error with a proper exception denoting what went wrong. So, what is happening on the IS side is the correct behavior. What probably happens on the Asgardeo side is that, we have a different implementation with the user store agents. So, it might be creating a user store properly in the Asgardeo side, even the configurations are not properly sent on the front end.

From UX perspective, it is good to not show the error in the front end side since this would be a server side error. But we can log it in the console and show an empty page as we currently do.

[pavinduLakshan]

From UX perspective, it is good to not show the error in the front end side since this would be a server side error. But we can log it in the console and show an empty page as we currently do.

Without some error code that indicates failing to connecting to userstore, it's not possible to show the empty users page, because otherwise we will have to show the empty users page, even if when there is a connection error while there are already users, which wouldn't certainly be a good UX.