Unicode strings with encoding declaration are not supported

[johnbarney]

I'm attempting to get SAML working and am running into the following issue:

[I 2023-05-03 08:04:08.926 JupyterHub samlauthenticator:806] Starting SP-initiated SAML Login
[W 2023-05-03 08:04:08.927 JupyterHub samlauthenticator:402] Got exception when attempting to parse SAML metadata
[W 2023-05-03 08:04:08.927 JupyterHub samlauthenticator:346] Exception: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.
[E 2023-05-03 08:04:08.927 JupyterHub samlauthenticator:714] Error getting SAML Metadata

I've searched documentation and issues and find no reference to Unicode strings. I also checked my SSO provider and found no options related to changing Unicode strings.

My configuration is very basic.
c.JupyterHub.authenticator_class = 'samlauthenticator.SAMLAuthenticator'
c.SAMLAuthenticator.metadata_filepath = '/etc/jupyterhub/metadata.xml'
# Disable creation of system users. User will assigned singleuser container.
c.SAMLAuthenticator.create_system_users = False

I have configured the SP to use urn:oasis:names:tc:SAML:2.0:nameid-format:transient format.

Upon inspecting my SP's metadata I found it included <?xml version="1.0" encoding="UTF-8"?> at the start. Removing encoding="UTF-8" has solved the issue for the moment

It seems like this plugin would be benefit from handling that edge case more gracefully in the future. I'm not well versed in the best way to do that without causing problems for existing users and any PR I submit will likely cause more problems than it'll solve.

[distortedsignal]

Unfortunately, this is a library issue.

I don't have a ton of time to maintain this plugin, so I'm not sure when this is going to get fixed. Thanks for calling it out, but it's pretty low on my priority list these days.

Also -

I'm not well versed in the best way to do that without causing problems for existing users and any PR I submit will likely cause more problems than it'll solve.

I'm not in the users' (user's?) heads, so every change that I make, I see as a breaking change. Don't sweat sending bad PRs. It's part of learning and growing.

[johnbarney]

Makes sense to me. Maybe this thread will do for anybody running into the same issue as I did.

…

On Fri, May 5, 2023 at 12:09 AM, Tom Kelley ***@***.***(mailto:On Fri, May 5, 2023 at 12:09 AM, Tom Kelley <<a href=)> wrote: Unfortunately, this is a library issue. I don't have a ton of time to maintain this plugin, so I'm not sure when this is going to get fixed. Thanks for calling it out, but it's pretty low on my priority list these days. Also - > I'm not well versed in the best way to do that without causing problems for existing users and any PR I submit will likely cause more problems than it'll solve. I'm not in the users' (user's?) heads, so every change that I make, I see as a breaking change. Don't sweat sending bad PRs. It's part of learning and growing. — Reply to this email directly, [view it on GitHub](#71 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAHZ3N2YUKQ6ZQPHXPUBAQDXEPPFNANCNFSM6AAAAAAXUFCFBI). You are receiving this because you authored the thread.Message ID: ***@***.***>

[distortedsignal]

I'll leave the issue open (it's sure not closed!). Thanks for understanding. 🙂