v14 compatibility - #233
Conversation
|
Thanks for your contribution! |
liayn
left a comment
liayn
left a comment
There was a problem hiding this comment.
Please update changelog too
|
The MR has conflicts currently. Can you please resolve those too? |
|
@svewap Can you please resolve the conflicts? |
# Conflicts: # Classes/OidcConfiguration.php # composer.json
|
This still lacks the changelog doc entry, but I'll merge and add it myself. |
… TypoScript setup during OIDC authentication
Guzzle's PrepareBodyMiddleware sets Content-Length as int via Utils::modifyRequest. TYPO3's PSR-7 Message::withHeader() is strict-string and rejects non-string values with InvalidArgumentException #1436717266, breaking every OIDC token exchange (/redirect-to-login/?logintype=login&tx_oidc[code]=...). The injected RequestFactoryInterface resolves to TYPO3's factory in a TYPO3 context, so the request that goes through the Guzzle client stack ends up being TYPO3-strict instead of Guzzle-lax. Switching to a Guzzle Request directly keeps the OIDC server-to-server HTTP stack consistent: Guzzle middlewares populate a Guzzle Request, no strict-string contract is violated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
I added the site set now with 1aa62b8. |
| // The Causal\Oidc HTTP flow is purely server-to-server through the | ||
| // Guzzle client, so a Guzzle Request is the correct PSR-7 implementation | ||
| // here regardless of the injected RequestFactoryInterface. | ||
| $request = new GuzzleRequest($method, $uri); |
There was a problem hiding this comment.
I'm not sure what's broken here. this line has been working all the time, why is it now broken?
There was a problem hiding this comment.
Please create a separate issue for this. Thanks.
|
We meanwhile changed quite a bit in our core-v14 branch. I hope it's okay to close this PR therefore and continue with #242 |
3 participants
No description provided.