Разрешенията на политиката на Amazon S3 Bucket не позволяват на Dropbox API да изтегля файлове от Bucket

Това ме подлудява цяла нощ.

Написах приложение DropBox в PHP/MYSQL, което работи перфектно, изтегля файлове от Amazon S3 Bucket и ги изпраща до папките на Dropbox на потребителите.

След това промених правилата за кофата на кофата на Amazon S3, за да позволя файловете да се изтеглят само от няколко референти и подписани URL адреси (пример: /musicfile.mp3?AWSAccessKeyId=[accesskeyid]&Expires=[expires]&Signature=[signature] ).

Това работи чудесно за всякакви цели, освен че научих, че моята функционалност на Dropbox вече не работи, защото подавате на API на Dropbox URL адреса на mp3 на Amazon S3, а от страната на Dropbox те изтеглят файла, така че сега, когато имам кофата политика, позволяваща само определени референти, dropbox получава разрешение, отказано и API ми казва, че е неуспешно.

Така че си помислих лесно решение, просто бих добавил ?AWSAccessKeyId= blah blah в края на файла, който се предава на dropbox и всичко ще работи незабавно, но не, защото файлът тогава не завършва с разширение Dropbox разпознава, така че отново не работи.

Тогава си помислих, че просто ще добавя референта от Dropbox към моята политика за кофа, но все още нямам представа какво е и добавих всеки вариант на dropbox.com и api.dropbox със и без https, всички без късмет.

Ако някой има някаква идея или решение, сериозно ще ми улесните седмицата.

Абсолютно последното нещо, което искам да направя, е да бъда принуден да изтегля файла първо на моя сървър, след това да го изпратя в dropbox, наистина не искам да правя това и знам, че това работи перфектно, както беше, и работи незабавно, когато премахна изцяло политиката си за кофата, просто искам тя да работи с нея.


person Island    schedule 28.08.2013    source източник


Отговори (2)


Предполагам, тъй като споменавате предаване на URL адрес към Dropbox, че използвате Saver ? Ако е така, можете да кажете на Saver какво име на файл да използва, така че му дайте оторизирания URL адрес и посочете име на файл, така че да има файлово разширение. напр.:

<a href="https://...?AWSAccessKeyId=..." class="dropbox-saver" data-filename="myfile.txt"></a>

или в JavaScript:

Dropbox.save('https://...?AWSACcessKeyId=...', 'myfile.txt');

Когато казвате, че „тъй като файлът след това не завършва с разширение, което Dropbox разпознава, така че отново не работи“, какво точно имате предвид? Какво се обърка, когато файлът няма разширение?

person user94559    schedule 28.08.2013

Когато всичко друго се провали... проверете регистрационните файлове.

Включете регистрирането за вашата кофа, изпълнете някои тестове, изчакайте няколко минути, за да се появи дневник, и след това прегледайте дневниците, за да видите какъв е референтът. Изглежда сигурен залог, че няма да има референт, защото потребителски агент, който не е уеб браузър (като бек-енд процесите на Dropbox), обикновено няма причина да изпрати референт.

Ако това е някаква утеха, "защитяването" на кофа чрез ограничаване на препоръчания е почти като да не осигурите кофата изобщо. Изключително лесно е да се победи и затова е наистина ефективна защита само срещу два класа хора:

  • честни хора
  • мързеливи хора

http://en.wikipedia.org/wiki/Referer_spoofing

person Michael - sqlbot    schedule 30.08.2013