![]() |
SQLite iOS encrypt password klappt nicht
Ich verwende eine SQLite Datenbank.
Das "Backend" (Windows VCL) pflegt diese, die iOS-App (FMX mobile) (iPad iOS7) liest diese. Die *.sdb für die App wird beim deployen mitverteilt und später via FTP aktualisiert. Alles hat im Prinzip schon funktioniert. Jetzt habe ich die *.sdb verschlüsselt, im Backend unter Windows:
Delphi-Quellcode:
Im Backend alles schön, das Öffnen geht danach wie folgt:
FDSQLiteSecurity1.Database := FDConnection1.Params.Values['Database'];
FDSQLiteSecurity1.Password := constCryptDatabasePassword; FDSQLiteSecurity1.SetPassword;
Delphi-Quellcode:
Im Backend geht das auch wunderbar.
function openDb(cPath : string; db : TFDConnection) : boolean;
begin if cPath <> '' then begin db.Params.Values['Database'] := cPath; end; db.Params.Values['LockingMode'] := 'normal'; db.Params.Values['Password'] := constCryptDatabasePassword; // ohne diese Zeile hatte alles funktioniert... db.Connected := true; ... result := true; end; ABER in der App kommt die Fehlermeldung "...file is encrypted or is not a database" Als Gegenprobe habe ich die PW-Konstante geändert und bekomme dann im Backend "...invalid password is specified or db is corrupted". In der App wie oben. (D.h. in der App wird das PW nicht falsch interpretiert (könnte ja sein, das iOS automatisch ein "aesXYZ-" davor setzt o.ä.) - denn dann käme ja auch in der App diese Fehlermeldung, sondern einfach nicht beachtet) Der obige Code zum Öffnen wird gleichermassen von der App und vom Backend benutzt. (Ich hab also keinen Schreibfehler gemacht) Es ist, als ob die SQLite-Bibliothek (sagt man unter iOS so?) sich gar nicht für den Parameter "Password" interessieren würde... ("password" mit kleinem "p" hab ich auch probiert) Hat jemand eine Idee? PS: in der Doku ![]() |
AW: SQLite iOS encrypt password klappt nicht
Der Mist ist, dass es mobil nicht unterstützt wird...
Ärgert mich extrem! |
AW: SQLite iOS encrypt password klappt nicht
Wie kommst Du denn darauf, kannst Du das etwas präzisieren?
Ich hab jetzt in alle möglichen Richtungen (apple embarcadero anydac) gesucht und nirgendwo eine definitive Aussage gefunden. |
AW: SQLite iOS encrypt password klappt nicht
Erkenntnis vom 02.09.2013:
Frage von mir: Zitat:
Zitat:
|
AW: SQLite iOS encrypt password klappt nicht
Aha.
Ich bin parallel auf anderem Weg zu derselben Erkenntnis gekommen. FireDac ist ja wohl nichts anderes als das seit XE4 inkorporierte AnyDac von DA-Soft ( ![]() Die hab ich gefragt und die folgende Antwort bekommen: "Hello ... SQLite encryption is supported only on Windows. -- With best regards, Dmitry Arefiev / FireDAC Architect FireDAC - Firebird, SQLite, MySQL, SQL Server, Oracle, PostgreSQL, DB2, SQL Anywhere, Access, Informix, ODBC high-speed data access lib" Das ist doof. Und noch doofer ist, das im Emba-Wiki ( ![]() Ein Absatz über der ganzen Verschlüsselungsgeschichte wird noch OS-X und iOS aufgelistet. Das könnte ein Querlesender ruhig mal einpflegen... |
AW: SQLite iOS encrypt password klappt nicht
Und Interbase toGo kann das zwar, kostet aber pro Client Lizenzgebühren im unterem 2 stelligen Bereich, völlig inakzeptabel. So kann man preislich im AppStore nicht mithalten
|
AW: SQLite iOS encrypt password klappt nicht
Nur so als Abschluss, falls jemand die gleiche Randbedingung "App braucht nur lesen" (<=> Datenaustausch in eine Richtung reicht aus) haben sollte, ich hab's jetzt mit SQLite folgendermassen gelöst:
- Backend erstellt + verschlüsselt periodisch eine Textdatei, die alle SQL-Anweisungen zum kompletten erstellen der DB enthält (create insert usw.) - Textdatei wird on demand via FTP bei der App aktualisiert - App liest bzw. entschlüsselt die Textdatei jedes Mal bei Start und erzeugt dann die komplette DB im Speicher (database=":memory:"). Damit ist auf dem iOS Gerät anstelle der nicht-verschlüsselbaren SDB nur eine verschlüsselte Textdatei. Klappt, bis jetzt. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz