In diesem Artikel werden wir uns mit dem neuen S3-Transport befassen. Funktionell unterscheidet sich S3 stark von dem, womit die meisten Menschen gewohnt sind zu arbeiten. Daher werden wir zu Beginn dieses Artikels seine wichtigsten Merkmale im Detail betrachten.
Hinweis! Für die Nutzung des HTTPS-Protokolls werden die folgenden OpenSSL-Bibliotheken benötigt: libssl-3.dll und libcrypto-3.dll. Diese Dateien befinden sich im Verzeichnis der Haupt-Demo-Anwendung. Sie müssen die Bibliotheken entweder in den Anwendungsordner oder in das Systemverzeichnis kopieren.
S3 ist kein Dateispeicher wie Dropbox, Google Drive, Mega und andere. S3 ist ein Objektspeicher. Und zuallererst müssen wir den Unterschied zwischen diesen beiden Konzepten verstehen.
Ein Dateispeicher verfügt über eine übliche hierarchische Struktur (Baumstruktur). Das sind bekannte Verzeichnisse (Ordner), in denen andere Verzeichnisse und Dateien gespeichert sind.
Objektspeicher sind relativ neu (der älteste ist jetzt etwa 20 Jahre alt). Sie unterscheiden sich geringfügig in ihren Implementierungen, so dass die meisten Funktionen gleich sind, aber es gibt einige, die nur auf S3 anwendbar sind.
Alle Objektspeicher sind "flach", d. h. sie haben keine hierarchische Struktur, wenn auch sie eine solche "simulieren" können.
Die erste Entität, auf die Sie stoßen werden, wenn Sie mit S3 arbeiten, ist ein Bucket. Die nächstliegende Analogie ist die "Map" in vielen Programmiersprachen, bei der ein Schlüssel verwendet wird, um Daten abzufragen. Ein Bucket kann nur Dateien speichern, aber keine anderen Buckets.
Zur Veranschaulichung betrachten wir einen Bucket einmal genauer.
Bucket |
|
Schlüssel |
Daten |
video.mp4 |
Daten |
text_file.txt |
Daten |
code.pas |
Daten |
Nach dem Schlüssel können Sie die dazugehörigen Metadaten abrufen und diese nach Bedarf selbst interpretieren. Viel interessanter ist die Simulation der hierarchischen Ordnerstruktur in einem solchen System.
Bucket |
|
Schlüssel |
Daten |
video.mp4 |
Daten |
folder1\text_file.txt |
Daten |
folder1\video.mp4 |
Daten |
folder1\folder1_1\video.mp4 |
Daten |
folder2\text_file.txt |
Daten |
folder1\ |
Leer |
folder1\folder1_1\ |
Leer |
folder2\ |
Leer |
Bei einigen „Ordnern“ handelt es sich um dieselben Objekte wie bei Dateien. Sie sind nur aus Gründen der Übersichtlichkeit anders eingefärbt. Ein weiteres Unterscheidungsmerkmal ist ein Schrägstrich (\) am Ende des Schlüssels. Oft haben solche "Ordner" keine Daten (obwohl sie Daten haben können).
Um zu sehen, was sich in dem "Ordner" folder1 befindet, müssen wir nach dem Anfang des Schlüssels "folder1\" filtern. Viel interessanter ist jedoch das Löschen von "Ordnern". Wenn wir versuchen, den "Ordner" folder1 in der Web-GUI zu löschen, werden einige Dienste dies tun, aber die übrigen werden uns die Fehlermeldung "Ein leerer Ordner kann nicht gelöscht werden" geben.
Wenn wir einen Datensatz mit dem API-Schlüssel "folder1\" löschen, wird dieser "Ordner" in den meisten GUIs nicht mehr angezeigt. Auch können wir ihn nicht mehr darauf zugreifen, aber tatsächlich werden die Dateien in diesem „Ordner“ nicht verschwinden. Sobald wir anschließend den „Ordner“ folder1 erstellen, enthält dieser bereits die von uns vergessenen Dateien. Der Schlüssel selbst unterliegt nur sehr wenigen Einschränkungen und kann beispielsweise so lauten: „////“. Und das werden „Ordner“ mit leeren Namen sein.
1. Objektspeicher sind wesentlich kostengünstiger. Jedes Objekt ist nicht an ein bestimmtes Gerät gebunden, so dass der Objektspeicher problemlos auf die benötigte Kapazität erweitert werden kann. Sie können ganz einfach ein Petabyte Objektspeicher (ca. 1.000.000 Gigabyte) mieten.
2. Objektspeicher ermöglichen eine sehr schnelle Suche. Aber natürlich sind Objektspeicher am besten für unstrukturierte (nicht baumartige) Daten geeignet.
Alle bisherigen Transporte funktionierten mit dem OAuth-2-Protokoll. S3 könnte theoretisch auch mit OAuth 2 arbeiten, aber in seine API ist sein eigenes Authentifizierungssystem eingebaut. OAuth 2 erhielt mit der Client-ID und der Secret-ID ein Token, das für eine bestimmte Zeit gültig war und alle Anfragen signieren konnte.
Die interne S3-Authentifizierung mit derselben Client-ID und Secret-ID erstellt für jeden Vorgang ein neues einmaliges Token unter Verwendung von SHA256HMAC auf der Grundlage von etwa 30 Variablen (einschließlich Zeitpunkt der Token-Generierung, erforderlicher Vorgang usw.). Der Server prüft nur, ob das Token korrekt generiert wurde, und wenn das vom Server akzeptierte Token mit dem vom Server generierten Token übereinstimmt, wird der Vorgang abgeschlossen. Danach kann das Token nicht mehr verwendet werden.
Der Transport heißt zwar "TfrxS3IOTransport" und bezieht sich eindeutig auf AWS S3 (Amazon Simple Storage Service), aber dessen API wurde von vielen Objektspeichern kopiert (die bedingt als S3-ähnlich bezeichnet werden können), so dass dieser Transport es Ihnen ermöglicht, nicht nur mit dem Amazon-Service zu arbeiten.
Ganz am Anfang müssen Sie die entsprechende Komponente aus der Registerkarte „FastReport VCL Internet Transports“ hinzufügen.
Sie können das Kontextmenü der Komponente verwenden. Dadurch wird die Verbindung direkt aus der Entwicklungsumgebung heraus hergestellt. Klicken Sie auf das Untermenü “Edit connection”.
Wenn Sie eine Datei mit Hilfe eines Transports öffnen oder darin speichern müssen, steht Ihnen der folgende Standard-Autorisierungsdialog zur Verfügung (falls Sie sich zuvor nicht angemeldet waren).
Schauen wir uns die einzelnen Felder in diesem Formular an:
Server URL ist eine URL-Adresse, die in der API verwendet wird. Um die URL herauszufinden, müssen Sie die Dokumentation lesen. Bei AWS S3 sollte sie standardmäßig "s3.amazonaws.com" lauten.
Client ID ist ein öffentlicher Schlüssel zur Autorisierung (oft wird als Access Key bezeichnet).
Secret ID ist ein geheimer Schlüssel zur Autorisierung (oft wird als Secret Access Key bezeichnet).
Region - Sie müssen die Dokumentation lesen, um mögliche Regionswerte zu wissen. Manchmal gibt es ungewöhnliche Anforderungen, z. B. ist es in AWS S3 möglich, eine Liste von Bucket-Listen nur mit der Region "us-east-1" anzufordern.
Bucket - um nicht jedes Mal einen Bucket manuell auswählen zu müssen, können Sie ihn in diesem Feld angeben, manchmal sind Buckets durch eine bestimmte Region gekennzeichnet.
Bucket style - ein Bucket kann auf zwei Arten angegeben werden: path style (aws.s3.com/bucket) und virtual hosted style (bucket.aws.s3.com). "Path style" ist veraltet, weil es mehrere Zugriffe auf verschiedene Buckets über einen bestimmten DNS geben kann, was eine zusätzliche Belastung verursachen kann. Einige Dienste unterstützen beide Arten, einige nur eine, und einige sind für verschiedene Situationen anpassbar. Unter folgendem Link können Sie mehr darüber lesen.
Nach erfolgreicher Verbindung sehen Sie den FastReport-VCL Standard-Dateibrowser (im Screenshot unten ist die Liste der Dateien im Bucket dargestellt).
Damit ist der Verbindungsaufbau erfolgreich abgeschlossen. Jetzt wissen Sie, wie in FastReport VCL die S3-Verbindung hergestellt wird.
Es bleibt nur noch, die letzten Feinheiten unserer Implementierung zu erwähnen. Unser Team hat die Erstellung und Löschung von Buckets nicht implementiert. Bisher unterscheiden sich Buckets optisch nicht von Ordnern (in unserer ersten GUI-Version), da dies zu gefährlich wäre. Auch das Löschen eines Ordners mitsamt seinem Inhalt ist noch nicht implementiert. Und es gibt auch kein teilweises Herunterladen der Datei (was bei einer Dateigröße von 100 Megabyte oder mehr empfohlen wird).
Dieser Transport hat eine Menge Details und Feinheiten bei der Konfiguration, aber in einigen Fällen wird er ein optimaler Ersatz für Dateispeicher sein.