1

We use Pac4j v5.7.0 in Magnolia CMS for our SSO module.

When requesting the configuration metadata of an OIDC Provider (a Content-type: application/json document), Magnolia sends the following Accept header:

text/html, image/gif, image/jpeg, *; q=.2, /; q=.2

This breaks the spec in two ways:

  1. Breaks https://www.rfc-editor.org/rfc/rfc9110.html#name-accept with the content-type *
  2. Breaks https://www.rfc-editor.org/rfc/rfc9110.html#quality.values with the q value of .2

This results in complying servers returning a 406 (content negotiation) error and Magnolia not getting returned the requested OIDC configuration metadata.

We traced it down and found Pac4J seems to be using standard java.net.URLConnection and unfortunately the Accept header we are seeing is the default for it. Here is what it is sent when doing a simple: new URL("http://localhost:8888").connect()

GET / HTTP/1.1 User-Agent: Java/17.0.6 Host: 127.0.0.1:8888 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive

And unfortunately, as we can see in https://github.com/pac4j/pac4j/blob/master/pac4j-core/src/main/java/org/pac4j/core/resource/SpringResourceHelper.java#L52-L56, Pac4J is not setting or changing any of the default headers before opening the connection and sending the request.

If the above analysis is correct, it means that Pac4J is breaking the HTTP standards and will be unable to contact any OIDC server respecting Content Negotiation "protocol".

A quick look at the commit history tells me that it may be quite recent... They introduced the SpringResourceLoader/Helper classes that may be responsible for that only recently (3 months ago) -> https://github.com/pac4j/pac4j/commit/bebd578596b11916b531c5e7da7ed4ba3d75c479

For 5.7.0 everything happens between these lines: https://github.com/pac4j/pac4j/blob/5.7.x/pac4j-oidc/src/main/java/org/pac4j/oidc/config/OidcConfiguration.java#L175-L195

Thanks in advance

Rich G

Expecting the response header to conform to standards

Rich
  • 71
  • 6

1 Answers1

3

I guess you have a problem in v5.7 although you referenced a commit from v6.

The commit has been introduced in the future v6 (not yet GA released) to replace the DefaultResourceRetriever (from the Nimbus library) by the SpringResourceHelper (in the pac4j-core) to be able to (re)load the metadata from any Spring resource (resource:, classpath:, file:, http:).

In both cases, they rely on URLConnection so they should have the same problem.

I just committed: https://github.com/pac4j/pac4j/commit/3a21347069b0de186a4269d058ac60988d587c73

Can you test again with the 5.7.1-SNAPSHOT version (in the Sonatype snapshots repository)? Thanks

jleleu
  • 2,309
  • 1
  • 13
  • 9
  • 1
    What a quick reply! However, I think it needs to be the Accept header, not the Content-type header. – pdr Apr 06 '23 at 15:57
  • Yes, sorry I meant 5.7 :p Thanks for responding so quickly. Much appreciated. – Rich Apr 06 '23 at 19:31
  • I switched to the Accept header: https://github.com/pac4j/pac4j/commit/47bcd9fe4c40995b9d6a17806b5858cd1d7a2810 Can you test again with `5.7.1-SNAPSHOT`? Thanks – jleleu Apr 07 '23 at 06:46
  • I works with the SSO module which Rich mentioned above, I'm gonna test it with 5.7.1-SNAPSHOT. Thanks for your quick fix @jleleu Do you guys have a plan to release the new version? Thanks – Nguyen Phung Apr 13 '23 at 07:34
  • I was waiting for an opportunity: in that case, I'll cut a release when you confirm the fix. – jleleu Apr 14 '23 at 08:39
  • Great, I've tested in our module and confirm that the fix works. I see the new `Accept: application/json` – Nguyen Phung Apr 17 '23 at 15:35
  • Excellent! I may need to fix one more issue for a customer. So I plan to cut the 5.7.1 release next week. – jleleu Apr 18 '23 at 06:38
  • Thanks so much @jleleu, really appreciate your quick response on this. We are looking forward to the new release. – Nguyen Phung Apr 20 '23 at 05:54
  • I just cut the v5.7.1 release. It will show up in the Maven central repo within a few minutes/hours... – jleleu Apr 20 '23 at 08:18