You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a feature request to support non-US-ASCII content in claims when passing claims as individual HTTP headers.
Right now, the content is treated as if it were US-ASCII and it is difficult to correctly interpret the content.
For example, if UTF-8 data is passed in a header and you read that header in a Java Servlet, the servlet interprets it as ISO-8859-1 and a corrupted string results.
The solutions I come up with are the following:
Historically, ISO-8859-1 has been used in headers and Java Servlets interpret them this way. A configuration option could allow to convert the original charset into ISO-8859-1. This has never been standard, and, anyway, only characters in ISO-8859-1 would be allowed, so it would be a partial solution.
It could be configured to URL-or-Base64-encode claim content, but you would still need to be able to find out whether the content has been encoded, the encoding used and the original character encoding. Additional headers could be used to provide this information.
It could be configured to use MIME encoding for claim headers, as per RFC2047. This allows also for base64 encoding and it can be easily recognised whether a header has or has not been encoded.
I personally find the latter the best solution, and more than one solution could be supported.
This feature request could be extended to passing claims in environment variables. I haven't checked that, but non-ASCII data is most probably not supported either.
Environment
mod_auth_openidc version (e.g. 2.3.8) 2.3.10
Apache version (e.g. 2.4.34) 2.4.37
platform/distro (e.g. Ubuntu Bionic or Centos 7) Windows 7
Expected behaviour
Claim headers contain only US-ASCII data, possiblly with encoded non-ASCII data.
Actual behaviour
Claim headers contain non-ASCII data and there is no information about the original character encoding.
Minimized example
Use the following:
OIDCPassUserInfoAs claims
OIDCPassClaimsAs headers (or both)
You need a user with some userinfo containing non-ASCII characters.
Connect with that user and check header content.
Configuration and Apache server log files
Config and logs for the minimized example, possibly provided as attachments.
The text was updated successfully, but these errors were encountered:
and properly test Unicode attributes.
Use Fedora to get mod_auth_openidc 2.4.12.2 which adds support
for OIDCPassClaimsAs base64url, related to
OpenIDC/mod_auth_openidc#417.
This is a feature request to support non-US-ASCII content in claims when passing claims as individual HTTP headers.
Right now, the content is treated as if it were US-ASCII and it is difficult to correctly interpret the content.
For example, if UTF-8 data is passed in a header and you read that header in a Java Servlet, the servlet interprets it as ISO-8859-1 and a corrupted string results.
The solutions I come up with are the following:
I personally find the latter the best solution, and more than one solution could be supported.
This feature request could be extended to passing claims in environment variables. I haven't checked that, but non-ASCII data is most probably not supported either.
Environment
Expected behaviour
Claim headers contain only US-ASCII data, possiblly with encoded non-ASCII data.
Actual behaviour
Claim headers contain non-ASCII data and there is no information about the original character encoding.
Minimized example
Use the following:
OIDCPassUserInfoAs claims
OIDCPassClaimsAs headers (or both)
You need a user with some userinfo containing non-ASCII characters.
Connect with that user and check header content.
Configuration and Apache server log files
Config and logs for the minimized example, possibly provided as attachments.
The text was updated successfully, but these errors were encountered: