Wo Programmupdate hinspeichern

[freimatz]

Hallo,
Danke für alle Antworten. Ich nehme dann mal einen Unterordner von TPath.GetTempPath

[freimatz]

Das scheint nun zu funktionieren - zumindest bei den meisten. Bei einem Tester gibt es das Problem, dass er die Datei lädt. Danach liegt auch eine mit dem Namen in dem Ordner, jedoch ist das inhaltlich keine exe sondern eine HTML. Darin steht u.a.:

While trying to retrieve the URL: <meine exe> The content is blocked due to the following condition:

Your organization's Internet access policy suggests you should not be downloading this file type. You may proceed with this download at your own discretion. ...
<a class="orange" href="http://passthrough.fw-notify.net/proceed?extension=exe&filename=...

Mein Programm startet dann die "Exe", was dann nicht funktioniert.

Der Tester hatte zwar einige Vorschläge, aber was meint Ihr?

[mensch72]

ne "exe" irgendwo per WEB hinspeichern schägt auf gut gesicherten Sytemen fehl... das ist auch gut so!

Wenn eh die eigene Applikation das "Update" startet, kann man es auch via "PNG" in einem binary ZIP-TAG unterbringen... das klappt sogar auf Apple OSx&IOS Systemen.
Ich nutze wenn irgend möglich nur noch zipped binary MetaDatenTags via JPGs oder PNGs, nen schickes kleines ICON als echte Bilddaten dazu und es flutscht locker überall in den Dokumenten/Bild Ordner... Endungen wie "exe" oder was auch immer sehen StandardOS-Nutzer doch seit langem nicht mehr... aber die Mini-Vorschau für Bilddateien kennen "alle"!

Bilddateien als zipped binary Container zu mißbrauchen ist nicht ganz die feine Art, aber zumindest bei PNGs ist das sogar gemäß strenger Apple Richtlinien 100% erlaubt, weil so im PNG Standard echt vorgesehen und von Apple voll unterstützt!

=> es kommt aus meiner Sicht also nicht wirklich darauf an "wo" man etwas speichert, sondern viel wichtiger ist "wie" man etwas speichert!

[Schokohase]

Wenn du den Response-Header auswerten würdest, dann würdest du unterscheiden können, ob du jetzt das Update bekommst, oder eben so ein HTML.

Bei Update -> speichern und Update ausführen
Bei HTML -> anzeigen

In diesem Fall kann der Benutzer wohl über diesen die EXE herunterladen, muss das Update dann aber manuell durchführen.

[DieDolly]

Zitat:

=> es kommt aus meiner Sicht also nicht wirklich darauf an "wo" man etwas speichert, sondern viel wichtiger ist "wie" man etwas speichert!

Beim Herunterladen der nackten Dateien kann man aber vorher den Hash prüfen und mit der lokalen Datei gegenprüfen. Erspart unnötige Downloads.
Viele Entwickler machen es sich da ganz einfach und lassen einfach nur ein Setup laden.

[freimatz]

Hoi,
Danke für die vielen Rückmeldungen. Insgesammt sehe ich das als recht aufwendig an wenn ich das ordentlich machen möchte. Als kurzfristige "Lösung" mache ich eine kleine Prüfung der Datei und gebe nun ggf. eine Fehlermeldung mit URL aus. Dann mag der Anwender selber schauen wie er die Setup-Datei auf seinen Rechner bekommt. (Ist sowieso eher ein exotisches Problem.)

@mensch72: Das erscheint mir als ein Ausnutzen einer Lücke der Firewall zu sein (genausso wie der Vorschlag des Testers die exe umzubennnen)

@Schokohase: Das wäre wohl die sauberste Lösung. Leider komme ich an den Header nicht ran. Derzeit verwende ich WinInet für das Laden. Ich dachte auch schon daran das auf Indy umzustellen das ich woanders auch schon benutze. Da wäre das einfacher.

@DieDolly: Ein Hash ist mir derzeit zu aufwendig. Würde bei diesem Problem auch nicht helfen.

Nochmals Danke an alle!
freimatz

[mensch72]

..."@mensch72: Das erscheint mir als ein Ausnutzen einer Lücke der Firewall zu sein (genausso wie der Vorschlag des Testers die exe umzubennnen)"...

- ja, einfach exe oder zip umbenennen umbenennen wäre nen typischer Test für Virentests... das müssen die erkennen und automatisch als Gefahr ausweisen.
Wenn so "Contentfilter" schon als LowLevelFirewall und gar auf exterener Hardware laufen, ist da was besseres am Start (Symantec bietet sowas z.B. Standalone auf Ent. Level)

- aber sagen wir die Anwendung Metadaten von Bilddateien(z.B. PNG&JPEG) mit "speziellen" Nutzinformationen zu versehen kommt aus der Apple-Offline-Welt!
Ohne installiertes ITunes funktioniert bei IPhones&IPads nur der Bilddatentransfer von/zu jedem per USB Kabel angeschlossenem "Fremdrechner".
Also mal fix ein Fehlerlog oder einen lokales Backup/Restore einer SQlite-DB ist für Ottonormal Apple Anwender sobald er in freier Wildbahn offline (oder gar Sibieren/Wüste/...) mal was austauschen oder empfangen soll schlicht auf ECHTE Bilddateien begrenzt(also auch da keine nur umbenannten ZIP/... Dateien!).

Das dies funktioniert ist Hersteller und Betriebssystem übergreifend so gewollt und hat nix mit einer Lücke z.B. in der Firewall zu tun:)
Prof. Kamerasysteme verstecken da spezielle Farbraumdaten oder bisherige Filtermatritzen, damit "nur die eigene Spezialsoftware" bei Weiterverarbeitung dies beachten kann.
Oder wegen Datenschutz müssen Backlinks in zu den Bilddaten besonders vor Fremdzugriff geschützt werden... also wenn in einem Bild 5Leute zu sehen sind und deren pers. Daten bekannt und verlinkt sind, dürfen diese Informationenn bei Weitergabe nicht offen für alle weiter verfügbar sein... weil da harte & gute Schutzalgos nun (hoffentlich) normal sind, kann sich kein aktiver Contentfilter daran stören, wenn eine Bilddatei voll nach Standard vorgesehene zusätzliche beliebige Metadaten inetgriert hat.

=> die Methode ist daher sowohl der sehr sicher, hoch kompatibel und vor allem sehr Endanwender freundlich, denn Fotos vom/zum Smartphone via Rechner... das ist aktuell hoch verbreitetes Basiswissen von jund bis alt


Wer für online wie offline verfügbar was vergleichbar einfaches und universelles hat, möge es mir bitte sagen.

[Schokohase]

An den Header kommt man sehr leicht heran, wenn man das richtig angeht. Hier mal ein kleines Beipiel, wie das prinzipiell gehen könnte:

Delphi-Quellcode:

uses
  Winapi.ShellAPI,
  Winapi.Windows,
  System.Classes,
  System.SysUtils,
  System.Net.HttpClient;

procedure DownloadFile( const AUrl: string; const AMimeType: string; const AStream: TStream );
var
  clt:      THttpCLient;
  response: IHTTPResponse;
begin
  clt := THttpCLient.Create( );
  try

    response := clt.Get( AUrl );
    if response.StatusCode = 200
    then
      begin
        if response.MimeType = AMimeType
        then
          begin
            AStream.CopyFrom( response.ContentStream, response.ContentLength );
          end else if response.MimeType.StartsWith( 'text/html', true )
        then
          begin
            ShellExecute( 0, 'open', PChar( AUrl ), nil, nil, SW_SHOW );
          end
        else
          raise Exception.CreateFmt( 'Unexpected Content-Type %s', [response.MimeType] );
      end
    else
      raise Exception.CreateFmt( 'Unexcepted StatusCode %d (%s)', [response.StatusCode, response.StatusText] );

  finally
    clt.Free( );
  end;
end;

procedure Main;
var
  stream: TMemoryStream;
begin
  stream := TMemoryStream.Create;
  try
    DownloadFile( 'https://www.delphipraxis.net/attachments/50203d1541379986-kodezwergs-tinihelper-klasse-inihelper.7z', 'application/x-7z-compressed', stream );
    WriteLn( stream.Size );
    stream.Clear( );
    DownloadFile( 'https://avm.de/fileadmin/user_upload/DE/Labor/Download/fritzbox-7590-labor-63282.zip', 'application/zip', stream );
    WriteLn( stream.Size );
    stream.Clear( );
  finally
    stream.Free;
  end;
end;

[Delphi.Narium]

Kann man für den Header nicht einfach

Delphi-Quellcode:

response := clt.Head(AUrl);

nehmen, damit kommt man den HTTP-üblichen Header, der alle Infos enthält.

Da steht dann drinne, welcher Mimetype geliefert wird, wie groß das Ergebnis sein wird, ob man auf 'ne andere Seite umgeleitet werden soll, welcher Responscode bei 'nem Get zu erwarten ist, ...

Also eigentlich alles, um anschließend gezielt weiterarbeiten zu können, sei es Download der gewünschten Datei oder eben Fehlerbehandlung, wenn die Datei nicht verfügbar ist.

Zitat:

Zitat von https://developer.mozilla.org/de/docs/Web/HTTP/Methods

GET
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
HEAD
The HEAD method asks for a response identical to that of a GET request, but without the response body.

https://tools.ietf.org/html/rfc7231#section-4.3.2

[Schokohase]

Zitat:

Zitat von Delphi.Narium (Beitrag 1418347)

Kann man für den Header nicht einfach

Delphi-Quellcode:

response := clt.Head(AUrl);

nehmen, damit kommt man den HTTP-üblichen Header, der alle Infos enthält.

Warum sollte man das nicht können?