setHTTPBody отправляет неверные данные в NSMUtableURLRequest

У меня проблема с правильной настройкой HTTPBody запроса. Я использую Oauth для связи с нашим сервером API, единственная разница в том, что мне нужно отправлять данные через тело, а не через заголовок (используя OauthConsumer.framework - http://code.google.com/p/oauthconsumer/wiki/UsingOAuthConsumer).

Это мой код:

NSString *oauthHeader = [NSString stringWithFormat:@"OAuth realm=\"%@\", oauth_consumer_key=\"%@\", %@oauth_signature_method=\"%@\", oauth_signature=\"%@\", oauth_timestamp=\"%@\", oauth_nonce=\"%@\", oauth_version=\"1.0\"%@",
                         [realm URLEncodedString],
                         [consumer.key URLEncodedString],
                         oauthToken,
                         [[signatureProvider name] URLEncodedString],
                         [signature URLEncodedString],
                         timestamp,
                         nonce,
                         extraParameters];

//[self setValue:oauthHeader forHTTPHeaderField:@"Authorization"];
NSLog(@"%@", oauthHeader);
[self setHTTPBody:[oauthHeader dataUsingEncoding:NSASCIIStringEncoding]];

Это вывод NSlog.

OAuth область = "", oauth_consumer_key = "ключ", oauth_signature_method = "HMAC-SHA1", oauth_signature = "HT2UwJoW4dSNh1gXkAzQThLp0Sk% 3D", oauth_timestamp = "1340789377", oauth_nonce = "3BDF0A1A-4FB0-40EF-95EA-5CB8B0FD07C1", oauth_version = «1.0»

А это то, что читает сервер, почему неправильный массив? Это не ошибка на стороне сервера, наш клиент C # делает это без проблем.

array(1) {
  ["OAuth_realm"]=>
  string(215) """, oauth_consumer_key="key", oauth_signature_method="HMAC-SHA1", oauth_signature="HT2UwJoW4dSNh1gXkAzQThLp0Sk=", oauth_timestamp="1340789377", oauth_nonce="3BDF0A1A-4FB0-40EF-95EA-5CB8B0FD07C1", oauth_version="1.0""
}

person Thunder    schedule 27.06.2012    source источник
comment
Вот что сервер получает от клиента Windows: ‹pre› array (7) {[app_status] = ›string (67) {downloads: [], application: {status: Idle, transfer_speed: 0}} [oauth_consumer_key] =› строка (40) 1e98d7a0b09c4a155b78cdb5ca09bee309355bb7 [oauth_nonce] = ›строка (8) 91942949 [oauth_signature_method] =› строка (9) HMAC-SHA1 [oauth_time_version] = ›строка oauth179 [oauth_time_version] =› outh179 строка (10_time_version)] = ›строка outh179 (10_time_version) = ›Строка (28) Q1Ac4eF690stWrvaOCi0knxThjY =} ‹/pre›   -  person Thunder    schedule 27.06.2012


Ответы (3)


Проблема, похоже, в том, что вы не отделяете разные пары ключ-значение друг от друга. Это просто делается путем объединения их с помощью «&» (без кавычек). Вы устанавливаете запятую между ассоциациями "ключ-значение".
Кроме того, вам не нужно заключать значения в кавычки, если вы не хотите, чтобы эти кавычки были частью значения на стороне получателя.

Полученная в результате строка данных должна выглядеть так:

NSString *oauthHeader = [NSString stringWithFormat:@"OAuth_realm=%@&oauth_consumer_key=%@&%@oauth_signature_method=%@&oauth_signature=%@&oauth_timestamp=%@&oauth_nonce=%@&oauth_version=1.0%@",
                     [realm URLEncodedString],
                     [consumer.key URLEncodedString],
                     oauthToken,
                     [[signatureProvider name] URLEncodedString],
                     [signature URLEncodedString],
                     timestamp,
                     nonce,
                     extraParameters];

Имейте в виду, что дополнительные параметры также необходимо разделять знаком "&".

person TRD    schedule 27.06.2012

Похоже, что oauth_signature неправильно закодирован (знак процента все еще там). Вместо [signature URLEncodedString] попробуйте следующее:

[signature stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding]

и посмотрим, имеет ли это значение.

person lawicko    schedule 27.06.2012
comment
Нет, не то. Проблема в том, что массив, который получает сервер, состоит из 1 объекта, но это должен быть массив (7). OAuth_realm рассматривается как ключ для первого элемента, но его значение - это остальная часть полученной строки. - person Thunder; 27.06.2012

Хорошо, я был достаточно глуп, чтобы не заметить, что наш API использует «&» вместо «,» для отделения друг от друга ключей. Проблема решена.

person Thunder    schedule 27.06.2012
comment
Это именно то, что я написал в своем ответе, может, вы согласитесь? - person TRD; 28.06.2012