(If the imminent fix will be applied soon, and will fix both the ignoring-first-param problem and the realm-position/rejected-consumer-key problem, then please just ignore this comment).
Re. client-side work-arounds
By "pass a realm first", do you mean pass as the first parameter, or pass in an earlier parameter, of pass in an earlier transmission?
If you mean pass as the first parameter, that can't be tried as long as LaunchPad server is discarding the first parameter.
I have tried passing the passing realm as an earlier parameter and the consumer key is still rejected:
"dummy", "blah", "realm", "https://api.launchpad.net", "oauth_consumer_key", consumerKey, "oauth_token", accessToken, "oauth_signature_method", "PLAINTEXT", "oauth_signature", accessSignature, "oauth_timestamp", Long.toString(new java.util.Date().getTime()/1000), "oauth_nonce", "1", // just unique for reqs. for this session "oauth_version", "1.0"
If you mean I should pass the realm in an earlier transmittal, the only earlier transmittal in the handshaking would be the token request transmittal. Should I add the realm param to that or insert some new transmittal?
Re #14
(If the imminent fix will be applied soon, and will fix both the ignoring- first-param problem and the realm-position/ rejected- consumer- key problem, then please just ignore this comment).
Re. client-side work-arounds
By "pass a realm first", do you mean pass as the first parameter, or pass in an earlier parameter, of pass in an earlier transmission?
If you mean pass as the first parameter, that can't be tried as long as LaunchPad server is discarding the first parameter.
I have tried passing the passing realm as an earlier parameter and the consumer key is still rejected:
If you mean I should pass the realm in an earlier transmittal, the only earlier transmittal in the handshaking would be the token request transmittal. Should I add the realm param to that or insert some new transmittal?