Re: CORBA and GSSUP fix -- please review

[Jeppe Sommer (Trifork)]

According to the CORBA 3.0.3 spec (and I believe the original CSIv2 spec says the same): Scoped-Username GSS Name Form The scoped-username GSS name form is defined as follows, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. scoped-username ::= name_value | [EMAIL PROTECTED] | @name_scope The '@' character shall be used to delimit name_value from name_scope. All nondelimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within a scoped-username. This suggests that the right way to fix this is to make the decoder tolerant to both name and [EMAIL PROTECTED]. I don't known how the third variant  - just @domain - is to be interpreted though. I'm also uncertain how an empty domain part is to be interpreted. To be on the safe side, I would suggest always encoding the full form ([EMAIL PROTECTED]) and live with the redundancy. Cheers, /Jeppe Aaron Mulder wrote: So it turns out our GSSUP token encoder set the username to [EMAIL PROTECTED] and the GSSUP token decoder did not lop off the @domain part, so Geronimo could not talk to itself using GSSUP. I changed the token encoder to just pass the username straight through -- there is a separate field in the token that holds the domain, after all, so mangling the username did not seem to make much sense. Just want to make a note of this in case someone thinks it should be changed the other way (that is, the GSSUP token encoder should send [EMAIL PROTECTED] and the GSSUP token decoder should lop off and ignore the @domain part, or compare the @domain to the domain that is sent in the other field). Thanks, Aaron P.S. Actually the GSSUP token encoder set the username to [EMAIL PROTECTED] due to an additional bug in the dynamic GSSUP configuration, so I gather no one's actually used this code before. :)