fix: ignore all unmarshal errors from locale

[muir]

This changes unmarshal of Locale so that rather than ignoring just language.ValueError errors, it ignores all errors. Generally speaking, a bad locale value should not prevent users from authenticating.

Resolves #672

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 60.94%. Comparing base (0992c5f) to head (8475675).
Report is 101 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #673      +/-   ##
==========================================
+ Coverage   60.06%   60.94%   +0.88%     
==========================================
  Files          80       81       +1     
  Lines        6998     7454     +456     
==========================================
+ Hits         4203     4543     +340     
- Misses       2498     2601     +103     
- Partials      297      310      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[muhlemmer]

I'm approving this fix as I understand the rationale that locale is not so important as failed authentications. However, I have a dislike of ignoring errors in general, as it may hamper debug efforts. If this ever backfires in complaints where people couldn't figure out why the Locale is missing (silent error) we might rollback this change.

I do recommend pressuring Okta to do their job and fix this on their side for the sake of long-term stability.

[github-actions]

🎉 This PR is included in version 3.32.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[muir]

@muhlemmer We could preserve the raw value sent somewhere in the object and allow it to be interrogated. Would you like me to do that?

[muhlemmer]

The raw values should already be available in the Userinfo.Claims map. So no need to do that.

[muir]

The raw values should already be available in the Userinfo.Claims map. So no need to do that.

@muhlemmer
Hmm, in that case I think the value may be ""

[muhlemmer]

Good one. Yes, with an empty string on the previous version I can reproduce. I was under the impression omitempty on the Userinfo field should catch that. 😕

I will open a seperate PR which reverts and tries to catch the empty string. Perhaps you can try that out instead, and if it works we can go that way.