On 26-Sep-06, at 4:13 PM, Josh Hoyt wrote: > On 9/26/06, Barry Ferg <[EMAIL PROTECTED]> wrote: >> The signature generation algorithm specifies that the fields to be >> signed be ordered in byte order form. It seems to be implied that >> the ordering is based on using the field names as sorting keys > > I think the real topic of this discussion is whether or not multiple > parameters with the same name should be allowed by the specification. > > I *strongly* prefer tightening the specification by *disallowing* > duplicate parameter names. PHP is one environment in which the > implementation will be problematic, but other common environments > (e.g. Rails) do not easily support this idiom. There is *no deployed > code* that depends on duplicated parameter names, and I'd like to keep > it that way. Keep it simple if possible.
Yes, it is quite unfortunate that PHP makes it hard to access multiple values. It is not impossible or terrible hard though. A helper function in the PHP libraries can provide the needed functionality. You can use either HTTP_RAW_POST_DATA or reading from php://input, this gives you the url encoded list of parameters. Parsing this is trivial. I would guess that there is a work around for Ruby on Rails as well. The core protocol can disallow duplicate parameter names, but I think it should allow extensions to do that. Not sure about pass through parameters. > > I agree that the language in the specification should be clarified so > that the sort order is fully explicit. I would resolve this issue by > stating that the pairs must be sorted by key. Also, the spec should make it clear that duplicate parameter names cannot occur. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
