Open AH-dark opened 3 days ago
Hey @AH-dark,
This crate follows the standard Rust error chaining approach using the Error
trait's source
method. The UserInfoError::Parse
variant includes the underlying serde error as its source: https://github.com/ramosbugs/openidconnect-rs/blob/052f4a7234f9df9e1510cf6e49c8a45b0bf0d941/src/user_info.rs#L526
See some example code here for logging errors including all of the underlying causes.
At first glance, those timestamps look like milliseconds, while the standard defines them as seconds. That might prevent them from being parsed successfully as chrono::DateTime<Utc>
types.
My usual suggestion for dealing with spec-noncompliant identity providers is to define a custom HTTP client to rewrite the response as a compliant one before returning it to this crate for further processing. This is a bit easier to do in the 4.x alpha release of this crate, which should be stabilized soon.
I use Logto's Traditional Web application. The front end provides Access Token to the back end and then performs back end user operations.
In this code, the asynchronous method
request_async
returns the errorFailed to parse server response
. The specific response is obtained through tracing:I don't know if there is a problem with my thinking or with the implementation. I used the standard
CoreClient
andCoreUserInfoClaims
.