Es ist ein Fehler in Ihrem konzeptionellen Modell.
I S3 wissen behandelt beide Dateien und Ordner als
Objekte, die nicht korrekt ist.
Hier ist die richtige Version:
- Die S3-Service und API haben kein Konzept von Ordnern.
- S3-Objekte sind in keinem wirklichen Sinne hierarchisch.
- Die S3-Konsole ist das einzige Unternehmen mit einem Konzept von Ordnern.
- Die S3-Dienst und API-Unterstützung ein Konzept von Präfix, delimiter und gemeinsame Präfixe.
Wenn eine Liste Objekte anfordern an die API durch einen angegebenen Präfix begleitet wird, nur Objekte mit mit dem Präfix beginnen Schlüssel zurückgegeben werden, und zwar unabhängig von irgendeine / in ihrem Objektschlüssel nach dem Präfix.
Wenn eine Liste Objekte Anfrage einen Präfix begleitet wird und auch durch ein Trennzeichen (in der Regel /), gibt die API nur Objekte, deren Schlüssel entsprechen den gegebenen Präfix und, die keine nachfolgenden haben / (nach dem Präfix in der Anforderung angegeben) im Schlüssel. Diese sind analog zu den "Dateien im Ordner".
Die Präfixe der Tasten beliebiger Objekte die gegebene Präfix passende die aber tun, um eine nachfolgende haben (nach der angegebenen prefix) / werden auf eine eindeutige Liste ihrer Präfixe, abgestumpften zu ihrem nächsten / koalesziert unten. Dies sind die allgemeinen Präfixe, analog zu "Ordnern im Ordner".
Aber tatsächlich ist nichts wirklich "in" etwas anderes.
Die Konsole schafft eine Illusion von Ordnern durch die gemeinsamen Präfixe aus einer Liste zu lesen Objekte an die API anfordern, und diese als Ordner zeigt.
Die Konsole fördert die Illusion, indem Sie auf „Ordner erstellen“ - aber es ist nicht in der Tat ein Ordner, und es ist nicht einmal notwendig. Es ist einfach ein leeres Objekt mit einem Schlüssel, dessen letztes Zeichen / ist. Dieses Objekt wird nicht für den normalen Betrieb von S3 benötigt, sondern wird aus praktischen Gründen erstellt, so dass Sie "in" einen "leeren Ordner" navigieren und eine Datei "in" den leeren Ordner hochladen können.
Doch was ist wirklich passiert, ist dies:
Console: "create folder foo in the root of the bucket"
API: PUT /foo/
Content-Length: 0
Console: "click folder foo"
API: GET /?prefix=foo/&delimiter=/
Console: "upload file bar.txt inside folder foo"
API: PUT /foo/bar.txt
Nun ... wenn Sie einen leeren Eimer nehmen und verwenden Sie die API (nicht die Konsole), können Sie einfach PUT /foo/bar.txt und Sie bekommen genau das gleiche Nettoergebnis in der Konsole - Sie sehen einen Ordner namens "foo" mit "bar.txt." Der Ordner wird angezeigt da gibt es ein Objekt mit dem Präfix foo/. Löschen Sie das Objekt und der Ordner verschwindet. Umgekehrt, wenn Sie es von oben mit der Konsole gemacht haben, wäre nach dem Löschen von "bar.txt" immer noch der Ordner "foo", denn das ist wirklich nur ein leeres Objekt, dessen einziger Zweck darin besteht, dass ein Ordner erscheint in der Konsolennavigation, wenn keine anderen Objekte mit diesem gemeinsamen Präfix vorhanden sind.
Also, nein ... S3 behandelt nicht sowohl Dateien und Ordner als Objekte. Die S3 Konsole erstellt Objekte, die Ordner fälschen, ausschließlich als Navigationshilfe, und die Magie hier ist, dass der Schlüssel des Objekts mit / endet. Wenn diese leeren Objekte jedoch nicht vorhanden sind, zeigt die Konsole weiterhin Objekte an, als wären sie in Ordnern.
Sie sehen dann das Problem, das sich entwickelt. Der S3-Dienst kann nicht dazu aufgefordert werden, etwas zu testen, von dem es nichts weiß und das tatsächlich nicht existieren muss.
Also, es ist technisch nicht möglich genau das zu tun, was Sie gefragt haben; Es scheint jedoch eine begrenzte Problemumgehung zu geben. Die primäre Einschränkung besteht darin, dass Sie nicht angeben können, dass "der Ordner vorhanden sein muss", aber Sie können angeben "das Objektschlüsselpräfix muss mit einem vordefinierten Mustersatz übereinstimmen".
Der relevante Teil der Bucket- oder Benutzerrichtlinie sieht möglicherweise so aus ...
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::examplebucket/taxdocuments/*",
"arn:aws:s3:::examplebucket/personnel/*",
"arn:aws:s3:::examplebucket/unicorns/*"
...
],
Ein Benutzer von dieser Politik betroffen wäre in der Lage mit taxdocuments/oder Personal/oder Einhörnern/in dem „examplebucket“ bucket beginnt jedes Objekt zu erstellen, und würde ein Objekt nicht in der Lage sein, ohne dass einer von denen zu schaffen Präfixe. Darüber hinaus können Konsolenordner "in" Ordnern "in" Ordnern den ganzen Tag lang erstellt werden, solange eines dieser Präfixe am Anfang jedes Objektschlüssels eines gefälschten Ordners steht.
Die Einschränkung besteht natürlich darin, dass die Änderung der Richtlinie erforderlich ist, um einen anderen für den Zugriff geeigneten Ordner zu erstellen.
Dies könnte auch funktionieren, aber mit Vorsicht vorgehen:
"Resource": "arn:aws:s3:::examplebucket/?*/?*",
Intuitiv scheint es, wie dies funktionieren könnte, aber der Fehler hier - die ?*/?* unter der Annahme gültig ist (it seems to be) und dass ? nicht 0 überein Zeichen die Art und Weise * tut - ist, dass dies einem Benutzer ermöglicht, einen neuen (Pseudo-) Ordner im Stamm zu erstellen, solange sie gleichzeitig etwas in ihm mit einem Namen mindestens ein Zeichen lang, unter Verwendung der API erstellen - das heißt Erstellen eines Objekts mit Schlüssel pics/cat.jpg "erstellt" den Ordner "Pics", wenn er nicht bereits vorhanden ist, wie oben beschrieben. Von der Konsole aus sollte diese die Erstellung neuer Ordner im Stamm verhindern, aber von der API würde keine solche Einschränkung auferlegt.