We have an end user getting this 500 error on logi...
# gooddata-cn
We have an end user getting this 500 error on login (through an OAuth 2 flow):
Hi Philip, is this user still getting these errors? Are they still unable to login? Would you be able to share the ID of the error with us, so we can look it up on our logs?
it just occurred, nothing has changed as far as i know. where can i find the ID
is it not the one in the screenshot there?
Ah, you’re actually right! I was able to locate the error on our logs. The error he ended up getting is a generit 500 error, but it was caused by this one:
principalName cannot be empty
. I checked, and it looks like this error is caused by a misconfiguration on your side, related to oauth2. Are any other users being affected, or just this one? I would recommend re-checking the configuration for this user on your end (check your OIDC, for example).
okay, that is a helpful message, thank you
we'll check some things
✔️ 1
@Francisco Antunes we have looked into this and are still having a hard time figuring out why Auth0 is not providing a "principalName" to GD. is there any other diagnostic info we can get from GD indicating what kind of authorization handoff message is being sent?
This is an assertion message in Spring, which I'm guessing you guys are using on the backend for OAuth2 clients. But "principalName" is just a constructor parameter, not directly a SAML thing, AFAIK... so I think we need a little more information to understand what is being handed in to GD and why it would be failing like this.
The lack of any kind of logging we can access ourselves makes this pretty difficult to diagnose
Hi Philip, I’m sorry to hear that. Our logs do not show much more info that I can find, see below. The full error is:
Copy code
exc: java.lang.IllegalArgumentException: principalName cannot be empty
	at org.springframework.util.Assert.hasText(Assert.java:289)
It occurs when the oauth2 login API is called at:
Copy code
uri: <https://exstratus.cloud.gooddata.com/login/oauth2/code/exstratus.cloud.gooddata.com?code=q2qkpOeMuxwt3-kPWVI4t12RujkGFZcCQGc7Sp5HSf7BW&state=YjwRWT3A53t3AUBXlHrudQPa1hwFZYYEaDKVVTgzQqCV>
resulting in a 500 error. And I also see the SSO provider at:
Copy code
Otherwise, there isn’t a lot. I will reach out to the Level 2 team and ask them to investigate it as well! A member of the team will reply here once they have an update to share. 🙂
we discovered that it's because the SAML didn't have the "email" attribute mapped and handed to GD. Trial and error. It would be good if there was a way for us to see debug logging information for failed logins, etc. so we can diagnose this more easily in the future.
Happy to hear you’ve figured out the cause of the issue! I’ve made an internal note of that, so thank you for sharing. Regarding the logs, we do not provide external access to GoodData’s internal logging tools; we can only check them from our end, which I understand can be limiting. But you’re able to expedite the process a lot by being aware of the Error Response Payloads provided by the GoodData, which you can usually find in the browser’s Console. The
is usually the most helpful for us to locate the error. 🙂