kratos
kratos copied to clipboard
ory
Kratos PHP SDK: ISO 8601 encoded dates cannot be parsed as DateTime
Preflight checklist
- [X] I could not find a solution in the existing issues, docs, nor discussions.
- [X] I agree to follow this project's Code of Conduct.
- [X] I have read and am following this repository's Contribution Guidelines.
- [ ] This issue affects my Ory Cloud project.
- [ ] I have joined the Ory Community Slack.
- [ ] I am signed up to the Ory Security Patch Newsletter.
Describe the bug
It would seem that the ISO 8601 encoded dates, sent in the /sessions/whoami JSON response, is in a format that the DateTime constructor in PHP cannot parse.
The SDK itself does not produce errors but the output is incorrect. The dates that are in a bad format and are deserialized as 1970-01-01 00:00:00, because the parsing fails silently.
I debugged the issue, and found that in my case some of the dates are parseable such as the "identity.created_at" field and others like "expires_at" are not. It would seem that PHP do not like the long miliseconds part of the date. Through trial and error, I figured it starts erroring when the millis part of the date is 9 digits or more. Anything below that is fine, and that is why it works with some of the dates.
Here is a slice of the session data:
{ "expires_at":"2021-11-18T20:46:52.404576263Z", "authenticated_at":"2021-11-17T20:46:52.438441763Z", ... "identity":{ ... "created_at":"2021-11-17T20:46:52.390087Z", "updated_at":"2021-11-17T20:46:52.390087Z" } }
Reproducing the bug
- Running the ORY Kratos Quickstart
- Try using the Kratos Client PHP SDK
- Make a request to an endpoint and check the dates of the response models
Relevant log output
DateTime::__construct(): Failed to parse time string (2021-11-18T20:46:52.404576263Z) at position 0 (2): The timezone could not be found in the database
Relevant configuration
No response
Version
v0.8.0-alpha.3
On which operating system are you observing this issue?
macOS
In which environment are you deploying?
Docker Compose
Additional Context
No response
Oh damn, that's an interesting bug. Could it be related to your PHP version or does this affect all PHP versions? The format itself is complaint with the RFC afaik.
I will look into this later. PHP is built different... when it comes to standardized stuff that works in every other programming language it may not work in PHP. I already tried to fix this once in the generator but it seems there is more work to do: https://github.com/OpenAPITools/openapi-generator/pull/7943
Im using PHP 7.4.25 for macOS 12.0.1 Monterey arm64 build. But as @NickUfer pointed out, it looks like there already was a fix made, but it does not seem like is enough :)
Here is a link to the code for deserialization of DateTimes in the generated code: https://github.com/ory/kratos-client-php/blob/556c84db83d64a4447d3921c3a44e0c82966a9d6/lib/ObjectSerializer.php#L320
Okay, I tested it and this seems to be a problem in versions <= php7.4. It works without any problems with php8.0, even without the workaround. I think you should upgrade to php8.0 if it's possible... I also think there is no other fix for that except for cutting the string before creating a DateTime out of it, but such a solution would not be accepted in the generator project as it is too hacky. If you can't upgrade to 8.0 and need that fix I'd suggest making a fork of the php client and implementing your own fix for that... or just write the fix straight into the vendor folder but that's really not the way to do things.
Closing as it is 18 months old and relates to an old PHP version. please reopen if required.
