Zitat:

Die Connect-Daten sind in einer UnitConnection.pas gespeichert und werden in die Hauptform mit Uses UnitConnection; implementiert.

Ganz schlechte Idee.
Dieses Tutorial sollte vom Netz genommen werden.

Zitat von Glados:

Zitat:

Die Connect-Daten sind in einer UnitConnection.pas gespeichert und werden in die Hauptform mit Uses UnitConnection; implementiert.

Ganz schlechte Idee.
Dieses Tutorial sollte vom Netz genommen werden.

Es wäre schön wenn du, statt nur zu "fluchen", begründen würdest wieso du das denkst und eine Möglichkeit aufzeigst (mit SourceCode und den zugehörigen Res-, Config-Files o.ä.) wie es besser gemacht werden könnte. Alleine schon deshalb, damit andere die diesen Thread später mal lesen nicht nach unten scrollen und denken, dass ein besserer Lösungsvorschlag auch hätte gepostet werden können wenn man schon darüber meckert.

Nimm das bitte als positive Kritik wahr und fühl dich nicht angegriffen.

Zitat von Aviator:

Zitat von Glados:

Zitat:

Die Connect-Daten sind in einer UnitConnection.pas gespeichert und werden in die Hauptform mit Uses UnitConnection; implementiert.

Ganz schlechte Idee.
Dieses Tutorial sollte vom Netz genommen werden.

Es wäre schön wenn du, statt nur zu "fluchen", begründen würdest wieso du das denkst

Weil so die Zugangsdaten im Klartext im Compilat landen.

Zitat von Luckie:

Weil so die Zugangsdaten im Klartext im Compilat landen.

Jetzt hast du ihm seine Arbeit weggenommen.

Also ich speichere meine Daten generell in einer Ini- bzw. XML-Datei verschlüsselt ab und weiß was es für Probleme geben kann wenn man sie im SourceCode ablegt. Es wäre aber eben generell schön, wenn jemand eine Begründung abgeben würde weshalb man etwas besser nicht machen sollte oder derjenige es blöd findet wie etwas umgesetzt ist.

Besser machen ist schwierig, deswegen hab eich dazu nichts gesagt.

Zitat von Aviator:

Also ich speichere meine Daten generell in einer Ini- bzw. XML-Datei verschlüsselt ab und weiß was es für Probleme geben kann wenn man sie im SourceCode ablegt.

Die Gleichen, die du mit deiner verschlüsselten Datei hast Es muss sich ja dann konsequenterweise dein Crypto-Key im Kompilat befinden, damit das Programm die Daten entschlüsseln kann. Im Grunde hast du damit lediglich dein Geld in einen unverschlossenen Tresor gelegt. Der Aufwand an die Daten zu gelangen ist geringfügig höher, aber weit weg entfernt von aufwändig oder gar sicher. Sicher wird es erst, wenn Logins ausschließlich vom Benutzer selbst eingegeben werden - ohne dass sie standardmäßig irgendwie im Programm hinterlegt sind. Einen Update-Server sollte man demnach optimalerweise auch komplett ohne Login verwenden können (bzw. evtl. per Authentifizierung über ein Benutzerkonto was man beim Erwerb der Software erstellt hat, etc.).

ihr mach euch um Dinge Gedanken, wo TMS für wenig Euros das seit Jahren incl. UpdateBuilder recht stabil incl. UAC gelöst hat.

http://tmssoftware.com/site/wupdate.asp

Bei der "eigenen Updateprüfung" empfehle ich ein asymetrisches Verschlüsselungs Verfahren (z.B. RSA), da kann man im Programm den PublicKey ruhig mit rein linken.
Nur man selbst kann per PrivateKey die UpdateFiles so verschlüsseln, das es das eigene Programm dann auch dekodieren kann... Das ist dann quasi zugleich eine sehr sichere Authentifizierung der Herkunft, weil auch böse Hacker mit dem PublicKey aus der EXE noch lange keinen PrivateKey zur Erstellung eines modifizierten/bösen Updates haben.

Klar kann man alles selbst machen, aber es gibt wohl niemanden der das incl UpdateBuilder und Support in weniger Zeit wie ihm 50Eur wert sind mindestens so gut hin bekommen kann

Zitat:

Bei der "eigenen Updateprüfung" empfehle ich ein asymetrisches Verschlüsselungs Verfahren (z.B. RSA), da kann man im Programm den PublicKey ruhig mit rein linken.
Nur man selbst kann per PrivateKey die UpdateFiles so verschlüsseln, das es das eigene Programm dann auch dekodieren kann... Das ist dann quasi zugleich eine sehr sichere Authentifizierung der Herkunft, weil auch böse Hacker mit dem PublicKey aus der EXE noch lange keinen PrivateKey zur Erstellung eines modifizierten/bösen Updates haben.

Wie würde ein solcher Mechanismus schematisch gesehen ablaufen?

Wäre das hier nicht auch eine Idee oder ist das zu unsicher?

- Client fragt Updatedateien vom Server an
- ein Script auf dem Server antwortet, dass Updates vorhanden sind oder nicht
- sind welche vorhanden, entschlüsselt das Script, welches auf dem Server liegt, die Dateien die auch auf dem Server liegen und schickt sie dann los

Oder habe ich gerade einen Knoten im Hirn?