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

[Scott Cantor (JIRA)]

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

Scott Cantor commented on SSPCPP-504:
-------------------------------------

Bug was easy to identify and fix, although it brings to light the fact that people running mixed versions of the SP with a shared shibd daemon are in a bad position when I have to change serialization formats internally.

For the scoped fix, I implemented it so that rolling upgrades of the mod_shib half ahead of the shibd half will work.

I found at least one other instance of the same bug, in the NameIDAttribute case. Will scan for others.

> 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