Sparkle: Sicherheit - Webspace mit .htaccess schützen?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Sparkle: Sicherheit - Webspace mit .htaccess schützen?

    Ich werde wohl Sparkle für den automatisierten Updatemechanismus verwenden.

    Gibt es eine einfache Möglichkeit die Updates so zu schützen, so dass sie nicht jeder herunterladen kann?


    Die einzige Möglichkeit die mir einfallen würde, wäre es mit einer .htaccess-Datei das Verzeichnis auf dem Webserver zu schützen.


    Kann ich in Sparkle Benutzername und Passwort so hinterlegen, dass es weiterhin automatisch funktioniert, ohne dass der Benutzer etwas tun muss? Es ist nicht schlimm, wenn er das Passwort auslesen kann, es geht nur um Dritte, die nicht einfach so, es herunterladen sollen.

  • Gebe da Objcler recht. Prinzipiell sollte es aber auch kein großes Problem sein, Sparkle derart zu modifizieren, dass es das Update aus einem passwortgeschützten Verzeichnis herunterlädt.

    Der Download ist in Sparkle über NSURLDownload realisiert. Da gibt es die Delegate-Methode -download:didReceiveAuthenticationChallenge:, von der aus du einen Benutzernamen und das Passwort via -useCredential:forAuthenticationChallenge: für den Download bereitstellen kannst.

  • Ja aber das macht doch so keinen Sinn. Wieso möchtest du kontrollieren, wer ein Update saugen darf und wer nicht? Ich nehme mal an, da du nur Nutzern Updates zukommen lassen möchtest, die für dein Anwendung gezahlt haben. Aber dann ist es wie schon gesagt wesentlich günstiger diese Logik im Programm selbst zu implementieren. Denn beschränkst du lediglich den Zugriff auf die Updates, so kann ja dennoch jeder einfach so dein Programm in der Weltgeschichte verteilen, der Kunde ist.
    Die Objective-Cloud ist fertig wenn sie fertig ist. Beta heißt Beta.

    Objective-C und Cocoa Band 2: Fortgeschrittene
    Cocoa/Objective-C Seminare von [co coa:ding].

  • nein, es geht nicht um "saugen darf nur wer gezahlt hat".

    Das Programm wird nur vom eigenen Innen- und Aussendienst verwendet.

    Innendienst ist kein Problem. Hier werfe ich das Programm via AppleRemoteDesktop einfach den Benutzern auf den Schreibtisch. Das geht recht komfortabel.

    Beim Aussendienst wäre es aber schön, wenn es sich von selbst aktualisieren würde, da ich per AppleRemoteDesktop nicht ohne weiteres an die Notebooks komme, da nicht jeder eine feste IP hat.

    Also: Programmupdates auf den Webserver. Vorteil: Sobald die Jungs wieder online sind, wird es automatisch geupdatet.

    Nachteil den ich aber sehe: es könnten fremde das ganze runterladen, wenn sie die URL kennen. Das wäre problematisch, da auch Firmendaten enthalten sind.


    Wenn ich das ganze per htaccess schütze, wäre sicher gestellt, dass google nicht drüberstolpert. ;)


    Falls der Aussendienst irgendwie das Passwort auslesen würde, wäre es halt nicht schlimm, da diese eh zugreifen dürfen. Nur ich will sicher stellen, dass keine Fremde dran kommen.


    PS: Kann ich nicht Name und PW in die URL eintragen, die abgefragt werden soll? Hab so was in der Art glaube ich schon mal gesehen.

    z.B.: user:pass@host.tld/ müsste doch hinhauen?

  • Okay. Nun wenn du Name und Passwort in die URL einträgst, dann ist das ja erstmal auch garnich verschlüsselt so wie ich das sehe.

    NSURL kannst du mit dieser Syntax passwörter übergeben. Aber schau dir mal NSURLAuthenticationChallenge an.
    Die Objective-Cloud ist fertig wenn sie fertig ist. Beta heißt Beta.

    Objective-C und Cocoa Band 2: Fortgeschrittene
    Cocoa/Objective-C Seminare von [co coa:ding].

  • Okay. Nun wenn du Name und Passwort in die URL einträgst, dann ist das ja erstmal auch garnich verschlüsselt so wie ich das sehe.

    Mit Verschlüsselung hat so ein .htaccess-Verzeichnisschutz doch eigentlich ohnehin nichts zu tun.

    Prinzipiell sollte das eigentlich funktionieren, wenn du Benutzernamen und Passwort sowohl im Appcast als auch der enthaltenen Download-URL mit übergibst. Probier's halt einfach mal aus. Falls das nicht geht, bleibt dir immer noch die Alternative mit NSURLAuthenticationChallenge.

  • Original von omz
    Okay. Nun wenn du Name und Passwort in die URL einträgst, dann ist das ja erstmal auch garnich verschlüsselt so wie ich das sehe.

    Mit Verschlüsselung hat so ein .htaccess-Verzeichnisschutz doch eigentlich ohnehin nichts zu tun.


    Ja aber wenn du zb. im Terminal ein:

    Quellcode

    1. ftp -u ftp://user:password@ftp.myserver.de/remote.png local.png


    ausführst, dann wird der Benutzername und das Password erstmal unverschlüsselt durchs Netz gejagt. Oder irre ich?
    Die Objective-Cloud ist fertig wenn sie fertig ist. Beta heißt Beta.

    Objective-C und Cocoa Band 2: Fortgeschrittene
    Cocoa/Objective-C Seminare von [co coa:ding].

  • Schon. Aber das ist mit der Antwort auf einen authentication request m.E. genauso. Für echte Verschlüsselung bräuchte man ja SSL und Konsorten.

    EDIT: Obwohl, es mag durchaus sein, dass ich mich da irre und in dem Fall nur ein Hash geschickt wird. Keine Ahnung...

  • also Zusammengefasst:

    Es klappt genauso wie ich es mir vorgestellt habe.

    Ich habe es mit htaccess geschützt, und wenn man in der info.plist - Datei die URL incl. dem Name:Passwort@url angibt, wählt es sich korrekt an und zeigt an das ein Update da ist. Perfekt. Ich danke Euch.


    Bleibt nur noch die GC-Version für Sparkle offen (siehe Nachbarthread).

  • Original von Objcler
    Ja aber wenn du zb. im Terminal ein:

    Quellcode

    1. ftp -u ftp://user:password@ftp.myserver.de/remote.png local.png


    ausführst, dann wird der Benutzername und das Password erstmal unverschlüsselt durchs Netz gejagt. Oder irre ich?

    Das wird es in jedem Fall. Bei Basic Auth (anders ist es etwa bei Digest) wird das Passwort lediglich Base64-kodiert.

    Ciao
    Carsten

  • Original von Nasir
    ausführst, dann wird der Benutzername und das Password erstmal unverschlüsselt durchs Netz gejagt. Oder irre ich?



    Ja, wenn Du die Leitung mit Ethereal mitschreibst, kannst Du das PW natürlich im Klartext lesen.
    [Dann dürfte man aber auch keine eMails mit POP3 runterladen.]

  • Original von Marcel Zimmer
    Original von Nasir
    ausführst, dann wird der Benutzername und das Password erstmal unverschlüsselt durchs Netz gejagt. Oder irre ich?



    Ja, wenn Du die Leitung mit Ethereal mitschreibst, kannst Du das PW natürlich im Klartext lesen.
    [Dann dürfte man aber auch keine eMails mit POP3 runterladen.]


    Macht das noch jemand unverschlüsselt?

    Also ich habe mal vor einigen Jahren mit den typischen Programmen 5 minuten unser kleines Heimnetzwerk beobachtet und fast alle emailpasswörter geliefert bekommen ohne viel zu tun...
    Die Objective-Cloud ist fertig wenn sie fertig ist. Beta heißt Beta.

    Objective-C und Cocoa Band 2: Fortgeschrittene
    Cocoa/Objective-C Seminare von [co coa:ding].

  • also eMails zu verschlüsseln nutzt nichts, wenn das Passwort dann im Klartext übertragen wird. :D


    [Problem bei PGP ist: wenn man es verschlüsselt, kann man es parallel mit IMAP nicht mehr auf dem iPhone lesen, da es dort kein PGP gibt. Falls jemand noch eine Idee für ein eigenes iPhone-App benötigt, hier wäre sie: ein PGP für iPhone wäre nett.]

  • Original von Marcel Zimmer
    also eMails zu verschlüsseln nutzt nichts, wenn das Passwort dann im Klartext übertragen wird. :D

    Obcler redet nicht vom Verschlüsseln der Mails, sondern vom Nicht-Klartext-Versenden der Authentifikations-Daten.

    Ciao
    Carsten