ИНОГДА возникает ошибка при загрузке фотографий Amazon S3 iOS SDK — SignatureDoesNotMatch

Итак, мое приложение для iPhone успешно загружает фотографии в Amazon S3. Я использовал тот же код, что и пример проекта S3Uploader, с последней версией (версия 1.6.0) Amazon AWS SDK для iOS. Проблема в том, что я периодически получаю сообщение об ошибке SignatureDoesNotMatch (рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ и метод подписи.). В нем нет шаблона. В настоящее время мое приложение работает над этой ошибкой, выполняя определенное количество повторных попыток вызова делегата didFailWithError:.

На данный момент в моих тестах было достаточно повторных попыток, поэтому пользователь не заметит ошибку, но очень неприятно знать, что я получаю ошибку ключа подписи, когда моя подпись явно верна, поскольку она иногда работает. Я не уверен, что это ошибка кодирования URL-адреса (в моем ключе подписи есть знак +), но, поскольку я использую iOS SDK, я не вижу, как обрабатываются URL-адреса PUT.

Кроме того, я убедился, что имя моей корзины написано строчными буквами, а имена файлов — это просто цифры и несколько букв алфавита. Я также пробовал разные регионы, и все они имеют одинаковый результат. Короче говоря, может потребоваться от 0 до 5 попыток, чтобы получить успешный PUT без ошибки SignatureDoesNotMatch. У кого-нибудь была похожая проблема? Любая помощь будет принята с благодарностью. Спасибо за чтение.


ios amazon-web-services amazon-s3 amazon put
person rymagno    schedule 22.07.2013    source источник
comment
Я являюсь одним из сопровождающих AWS SDK для iOS. Вы указываете, что используете тот же код, что и S3Uploader. Означает ли это, что вы используете встроенные учетные данные? Обратите внимание: мы не рекомендуем этого делать, так как ваше приложение может быть скомпрометировано, а учетные данные извлечены. При этом возникает ли эта ошибка только на устройствах конечных пользователей или вы смогли воспроизвести ее на своем собственном устройстве или симуляторе?   -  person Bob Kinney    schedule 23.07.2013
comment
Привет боб. Спасибо за ответ! Кроме того, спасибо за информацию о встроенных учетных данных. Будет ли IAM более безопасным маршрутом? Если да, не могли бы вы указать мне несколько примеров использования IAM с iOS SDK? Что касается моего первоначального вопроса, приложение все еще находится в разработке, поэтому я смог протестировать и создать его только сам (в симуляторе - еще не пробовал его на устройстве). Так что до сих пор единственные запросы PUT были от меня. Спасибо за ваше время.   -  person rymagno    schedule 24.07.2013
comment
Использование учетных данных IAM определенно лучше, чем использование учетных данных root, но это не устраняет проблему возможной компрометации вашего приложения. Мы рекомендуем использовать либо TVM, либо федерацию веб-удостоверений. Версия 1.6.0 AWS SDK для iOS включает примеры для обоих этих методов управления учетными данными. Вы также можете прочитать следующие статьи для получения дополнительной информации об федерации веб-удостоверений, автомат по продаже токенов.   -  person Bob Kinney    schedule 24.07.2013
comment
Спасибо, Боб. Хотя моя проблема не имеет ничего общего с этим, я все же извлек пользу из вашего отзыва. Вместо использования IAM/встроенных учетных данных я получил сервер TVM, работающий на Elastic Beanstalk. Всегда приятно узнавать новое.   -  person rymagno    schedule 26.07.2013

Ответы (2)


arrow_upward
3
arrow_downward

Возможно, вам придется изменить подпись после ее создания, потому что допустимая база 64 не всегда действительна в строке запроса. Я, должно быть, столкнулся с той же проблемой однажды, потому что я нашел следующие комментарии в каком-то коде, который я написал:

# the "+" is not url-safe, as it gets converted to a space somewhere along the line

# '+' => '%2B'

# while we're at it, we'll go ahead and convert the other non-safe-ish 
# characters even though the links seem to work without this step

# '/' => '%2F'
# '=' => '%3D'

Мой код выполняет поиск и замену строк для этих 3 символов, заменяя их эквивалентами в кодировке URL, прежде чем возвращать строку запроса вызывающей стороне. Я использовал тактику поиска/замены, потому что в среде, в которой я работал, не было подходящей библиотеки кодирования URL-адресов. Поскольку это единственные 3 символа base64, которые мой код мог сгенерировать, которые явно не были безопасными для URL, я, очевидно, пошел дальше и обработал все три возможности.

person Michael - sqlbot    schedule 24.07.2013
comment
Спасибо, Майкл. Поскольку я использовал SDK AWS для iOS, он фактически обрабатывал URL-адреса для меня. Но я буду использовать это для справки, если в будущем буду обращаться с ними самостоятельно. - person rymagno; 26.07.2013
comment
Дружище, большое спасибо за это. Вы спасли меня от того, что, как я могу себе представить, потребовалось бы несколько часов, чтобы понять, что, черт возьми, происходит. Здоровья, приятель. - person Aaron Chambers; 25.06.2015

arrow_upward
2
arrow_downward

ХОРОШО. Итак, проведя последние пару дней, пробуя новые ведра... пробуя все разные кодировки NSString/UIImage в операторы NSData... переключаясь с встроенного на TVM... прыгая туда-сюда от моего проекта к демо-версии TVM... и читая страницы и страницы результатов отладки... Я обнаружил, что это не имеет ничего общего ни с одним из них! :П

Как только я понял, что непреднамеренно скопировал фреймворки AWS в папку своего проекта, я удалил их и повторно добавил, не установив флажок для копирования (ссылаясь на папку моего SDK). Бум - ошибок подписи больше нет.

Очевидно, что AWS SDK не любит иметь несколько экземпляров своих фреймворков в одной системе. Надеюсь, это поможет другим! :)

person rymagno    schedule 26.07.2013