[JIRA] Commented: (SSPCPP-504) ScopedAttributeDecoder fails on non-ascii chars?

[bajnokk@idp.protectnetwork.org (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SSPCPP-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14410#comment-14410 ] 

bajnokk at idp.protectnetwork.org commented on SSPCPP-504:
-------------------------------------------------------

(I wasn't aware that jira will add separate comments for the attachments, now it looks awful, sorry)

You may notice that even SAMLTracer gets confused with displaying the non-ascii chars. This either indicates the IdP sending them in an unexpected encoding or a bug in SAMLTracer.

> ScopedAttributeDecoder fails on non-ascii chars?
> ------------------------------------------------
>
>                 Key: SSPCPP-504
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-504
>             Project: Shibboleth SP - C++
>          Issue Type: Bug
>          Components: Attribute Resolution / Filtering
>    Affects Versions: 2.5.0
>            Reporter: bajnokk at idp.protectnetwork.org
>            Assignee: Scott Cantor
>            Priority: Minor
>         Attachments: livehttp-traffic.txt, native.log, samlresponse-text.txt, samlresponse.txt, shibd.log, sptest.pcap
>
>
> A customer reports that if the {{eduPersonPrincipalName}} of a user is {{ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP at sze.hu}} (which is indeed weird), the request and every subsequent HTTP requests of that session are getting closed in an invalid way. tcpdump showed that after the server processed the assertion and redirected back to the resource, it answers the GET with an ACK -> FIN,ACK. (No HTTP error. Firefox interprets this as "The connection was reset")
> During this, {{native.log}} says:
> {{2012-09-24 14:37:12 ERROR Shibboleth.Listener [28699] shib_check_user: socket call (unknown) resulted in error (32): no message}}
> It turned out that if the attribute is decoded as a simple string, it works OK, it only fails if it is decoded by the {{ScopedAttributeDecoder}}. Unfortunately I couldn't reproduce exactly this kind of error with the older test SP I have at hand, although the non-ascii chars are missing from the decoded value even there, that's why I suspect that the problem is somewhere with ScopedAttributeDecoder's handling of utf8 characters.
> Because I've not been able to reproduce this error myself with a controlled environment, I cannot rule out that some UTF-16 magic is happening somewhere at the IdP, although the debug log shows 'clean' utf8 data.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira