• Hi!

    ich habe folgendes problem:

    die liebe Inode hat ein eigenes verzeichnis für daten die ssl verschlüsselt werden sollen... dieses verzeichnis is über https://ssl.inode.at/domainname.net etc erreichbar.

    so, nachdem diese url aber schirch is und ich eigentlich nicht zwischen den beiden seiten (o.g. url und domainname.net) hin und her switchen will hab ich mir gedacht ich stell einfach alles ins ssl verzeichnis und mach auf domainname.net einfach eine index.php in der dann einfach steht:

    PHP
    <? include 'https://ssl.inode.at/domainname.net/index.php'; ?>



    funktioniert auch herrlich.... nur, bin ich jetzt geschützt oder nicht? normalerweise zeigt der browser bei einer ssl verbindung ja ein schloß an... (unten in der leiste oder oben bei der adresse, je nachdem), in diesem fall is das nicht so...

    weiss da wer mehr?

    lg, Phil.

    Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders!
    http://www.chuckbronson.net/

  • Argl. Nein, nein, nein! So sicher nicht :)

    Du tust so, als ob ein include ein iframe oder ein frame wäre. Ist aber nicht. Wenn Du eine verschlüsselte Seite wo anders einbauen willst, brauchst Du https im Browser.

    Nicht als Transferprotokoll für php. php kann URLs wie ganz normale Dateien öffnen. Also "<? include 'https://ssl.inode.at/domainname.net/index.php'; ?> " ist nicht nur nicht das was Du nicht haben willst. Sondern genaugenommen auch ein Sicherheitsproblem. Ist wie ein include aus dem lokalen Dateisystem. Siehe auch C, etc.

    Alles klar?

  • more or less... ja. obwohl ich mich mit c net beschäftige...

    *g* mist... na dann muss ich halt im shopsystem wieder auf ssl hüpfen.... *würg* das haut zwar ein bissl meinen plan übern haufen aber was solls.

    gut was is wenn ich von einem http:// form auf die https:// absende? is der kanal dann sicher oder is das eine lücke? (ich denk mir mal dass das ne lücke is, aber vielleicht überzeugt mich ja wer vom gegenteil...)

    Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders!
    http://www.chuckbronson.net/

  • Zitat von MarvinTheRobot

    gut was is wenn ich von einem http:// form auf die https:// absende? is der kanal dann sicher oder is das eine lücke? (ich denk mir mal dass das ne lücke is, aber vielleicht überzeugt mich ja wer vom gegenteil...)


    du meinst in einem normalen Formular <form action="https:/...">...</form> ?
    da sind dann alle POST- und GET- Variablen verSSLüsselt - ab dem Moment, wo du auf "absenden" klickst, alles vorher (HTML-Datei mit Formular-Default-Values) kann natürlich abgehört werden.

    Ein Formular abzusenden ist ein ganz normaler HTTP-Request, wenn das Ziel ein https-Server ist, dann kümmert sich schon der Browser vor dem Versenden der Daten um die Sicherheit (Handshake, ...)

    Nur würde ich nie meine Daten auf einer Seite eingeben, die nicht schon auch verschlüsselt ist, denke andere User auch nicht - ist eher ein psychologisches Problem...

  • Zitat von MarvinTheRobot

    gut was is wenn ich von einem http:// form auf die https:// absende? is der kanal dann sicher oder is das eine lücke? (ich denk mir mal dass das ne lücke is, aber vielleicht überzeugt mich ja wer vom gegenteil...)

    Gesamter Workflow? Filz hat technisch gesehen zwar eh schon alles gesagt. Aber ich tät' die User vorher einloggen lassen (personalisierung, nicht Daten dauernd neu eintippen, etc.) und via login von http:// auf https:// wechseln. Siehe auch TUWIS...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!