nicht angemeldet
<a href...> als POST senden?
0 0 0
<a href...> als POST senden?
Hallo zusammen,
ich steh grad etwas auf dem Schlauch.
Ich möchte einem Link, der per <a href=...> definiert ist, Variablen übergeben. Wenn ich das in der Form ?var1=xxx&var2=yyy mache, dann werden die Daten ja per GET gesendet, und sind in der Adresszeile des Browsers sichtbar.
Kann ich das auch so machen, dass die Variablen als POST gesendet werden (wie bei Formularen mit method=POST), so dass sie in der Adresszeile des Browsers nicht sichtbar sind?
Der HTML-Code wird übrigens von einem PHP-Script erzeugt und enthält sehr viele dieser Links, deshalb möchte ich nicht für jeden Link ein Formular definieren.
Danke für eure Hilfe,
Gruß, André
-
Moin,
Ich glaube du erliegst einem Mißverständnis.
Ein Link der per Post gesendet wird wiederspricht dem Gedanken eines Links.
Vielleicht schilderst Du mal warum Deine Daten nicht in der Adresszeile sichtbar sein dürfen.
Dann können wir Dir vielleicht effizent helfen.
TomIRL-
Hallo!
Hat jetzt nicht unbedingt damit zu tun. Aber werden bei einer HTTPS Verbindung die GET Parameter verschlüsselt oder unverschlüsselt übertragen?
Da sie ja Teil der URL sind, tippe ich mal drauf, dass sie unverschlüsselt übertragen werden. Ist das richtig?mfg
frafu-
Moin!
Hat jetzt nicht unbedingt damit zu tun. Aber werden bei einer HTTPS Verbindung die GET Parameter verschlüsselt oder unverschlüsselt übertragen?
Da sie ja Teil der URL sind, tippe ich mal drauf, dass sie unverschlüsselt übertragen werden. Ist das richtig?Falsch. SSL sichert die TCP-Verbindung, über den der HTTP-Verkehr abgewickelt wird. Ein Außenbeobachter kann lediglich feststellen, dass ein Kontakt zum Server hergestellt wird, und dass Daten übertragen werden, aber nicht deren Inhalt.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hallo Sven!
Das stimmt, aber je nach Serverlogfile, kann ein User der darauf Zugriff hat, dort die Daten an Hand der per GET übertragenen URL auslesen. Das wäre bei Post nicht der Fall.
Schönen Gruß
Afra
-
Moin!
Das stimmt, aber je nach Serverlogfile, kann ein User der darauf Zugriff hat, dort die Daten an Hand der per GET übertragenen URL auslesen. Das wäre bei Post nicht der Fall.
Wer in der Lage ist, Zugriff auf das Serverlogfile zu nehmen, der ist auch in der Lage, Zugriff auf den Apache-Prozess zu nehmen und die POST-Daten dort abzufangen, oder auf die weiterverarbeitenden und speichernden Prozesse wie Datenbanken, in denen die POST-Daten vermutlich landen werden.
Da sich aber SSL und Shared Hosting gegenseitig ausschließen, bedürfte es da schon der Überwindung gewisser Grenzen.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hi,
Da sich aber SSL und Shared Hosting gegenseitig ausschließen,
Wie funktioniert das die Shared Hoster, die SSL automatisch mitanbieten - selbst bei Billigstpaketen - natürlich ohne offizielle Zertifizierung?
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Moin!
Da sich aber SSL und Shared Hosting gegenseitig ausschließen,
Wie funktioniert das die Shared Hoster, die SSL automatisch mitanbieten - selbst bei Billigstpaketen - natürlich ohne offizielle Zertifizierung?
Es gilt: Pro IP und Port kann nur ein einziges SSL-Zertifikat existieren. Und dieses Zertifikat gilt für entweder eine exakte Domain oder ein Domainbündel (mit Wildcard).
Shared Hosting ist also nur möglich, indem man alle Subdomains einer gemeinsamen Domain auf dem Server zusammenfaßt. Verschiedene Second-Level-Domains in ein Zertifikat packen funktioniert nicht.
Deshalb setzen Hoster bei sowas gerne SSL-Proxys ein. Die haben dann ein unterschriebenes Zertifikat, werden aber für sämtliche SSL-Nutzer des Hosters genutzt, und haben den Nachteil, das SSL nur vom Client bis zum Proxy benutzt wird, vom Proxy bis zum Server wird innerhalb des Providernetzes nur HTTP benutzt. Zweiter Nachteil: Die eigentliche Domain wird nicht genutzt, sondern alles unter der Domain des Proxys abgewickelt (https://secureserver.tld/www.example.org/pfad/ziel.html).
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hi,
soweit, so klar. Aber ...
Zweiter Nachteil: Die eigentliche Domain wird nicht genutzt, sondern alles unter der Domain des Proxys abgewickelt (https://secureserver.tld/www.example.org/pfad/ziel.html).
... das kann ich bei den Shared Hostern, wo ich das bemerkt habe (ich probiere es immer aus ;-)) nicht nachvollziehen. Ich hatte in diesen Fällen immer meine normale Domain - nur eben mit https:// statt http://.
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Moin!
... das kann ich bei den Shared Hostern, wo ich das bemerkt habe (ich probiere es immer aus ;-)) nicht nachvollziehen. Ich hatte in diesen Fällen immer meine normale Domain - nur eben mit https:// statt http://.
Welche Fehlermeldung kommt denn bei der Kontaktaufnahme?
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hi,
Welche Fehlermeldung kommt denn bei der Kontaktaufnahme?
Wie zu sehen?
Eine Domain wäre z.B. www.exekutive.org
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Moin!
Welche Fehlermeldung kommt denn bei der Kontaktaufnahme?
Wie zu sehen?
Eine Domain wäre z.B. www.exekutive.org
Bei mir kommen da zwei böse Warnmeldungen:
1. Opera warnt mich, dass das Zertifikat für die Domain "www.smartmin.com" ausgestellt ist, und nicht für www.exekutive.org. Das bedeutet: Selbst WENN das Zertifikat von einer autorisierten CA unterschrieben wäre, würde diese Fehlermeldung immer signalisieren: "Hallo, irgendwas ganz ganz böses läuft hier ab, du (Besucher) redest NICHT mit dem Server, der für www.exekutive.org wirklich zuständig wäre (denn der hätte ja kein Zertifikat für die falsche Domain)."2. Außerdem ist das Zertifikat seit 2004 abgelaufen.
Der Datenverkehr wird zwar verschlüsselt - aber alle sonstigen Mechanismen, die man in SSL eingebaut hat, um sicherzustellen, dass die verschlüsselten Daten auch wirklich bei dem landen, mit dem man glaubt, zu sprechen - die versagen allesamt!
Wenn du tatsächlich WEISST, dass deine Domain auch per SSL erreichbar ist, dann ist das schön für dich - und gefährlich, denn wenn tatsächlich mal jemand den DNS deiner Domain umstellt auf SEINEN Server, dann bemerkst du das nicht, und sendest deine Daten wohlmöglich an einen fremden Server.
Als Businesslösung für Shops etc. verbietet sich so eine kaputte SSL-Konfiguration sowieso.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hi,
- Opera warnt mich, dass das Zertifikat für die Domain "www.smartmin.com" ausgestellt ist, und nicht für www.exekutive.org. Das bedeutet: Selbst WENN das Zertifikat von einer autorisierten CA unterschrieben wäre, würde diese Fehlermeldung immer signalisieren: "Hallo, irgendwas ganz ganz böses läuft hier ab, du (Besucher) redest NICHT mit dem Server, der für www.exekutive.org wirklich zuständig wäre (denn der hätte ja kein Zertifikat für die falsche Domain)."
Ja klar.
Der Datenverkehr wird zwar verschlüsselt - aber alle sonstigen Mechanismen, die man in SSL eingebaut hat, um sicherzustellen, dass die verschlüsselten Daten auch wirklich bei dem landen, mit dem man glaubt, zu sprechen - die versagen allesamt!
Auch klar. Nur darum ging es mir ja nicht!
Ist halt ein Billigpaket bei einem beliebigen Shared Hoster, wo ich die Domain ohne weiteres zutun auch via HTTPS erreichen kann - über die eigentliche Domain, nicht über deine Variante mittels SSL-Proxy und einem anderen URL!
Wenn du tatsächlich WEISST, dass deine Domain auch per SSL erreichbar ist, dann ist das schön für dich - und gefährlich, denn wenn tatsächlich mal jemand den DNS deiner Domain umstellt auf SEINEN Server, dann bemerkst du das nicht, und sendest deine Daten wohlmöglich an einen fremden Server.
Also wenn ich Daten an meinen Server schicke (egal ob verschlüsselt oder nicht) und sie kommen nicht an, merke ich das *sofort*. ;-)
Als Businesslösung für Shops etc. verbietet sich so eine kaputte SSL-Konfiguration sowieso.
Daß ich *damit* keine kommerzielle Site betreiben würde, das steht auf einem *anderen* Blatt und versteht sich, jedenfalls was mich angeht, ja auch von selbst. =:-)
Wie gesagt: Es ging mir ums Prinzip, bzw. deine Aussage, daß sich Shared Hosting und SSL gegenseitig ausschließen. Diese Konfiguration mit "kaputtem SSL" wird bei einer populären Shared-Host-Verwaltungsoftware (nicht Confixx, die andere - man, mein Alzheimer =;->) IIRC als Standard eingerichtet.
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
-
-
-
Moin!
Welche Fehlermeldung kommt denn bei der Kontaktaufnahme?
Bei 1und1 geht das auch mit den Businessdomains.
Die werden dann genau für eine IP und genau eine Domain mit genau einem Port gemacht.
Thomas Giesau-
Hi,
Bei 1und1 geht das auch mit den Businessdomains.
Ja, aber wir reden hier ja *explizit* von Shared Hosting bei Billiganbietern - also vieeele Domains auf einem Server/einer IP.
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hi,
Bei 1und1 geht das auch mit den Businessdomains.
Ja, aber wir reden hier ja *explizit* von Shared Hosting bei Billiganbietern - also vieeele Domains auf einem Server/einer IP.
Ja..
Businesspackeet sind shared hosting.
Und ich finde 10EUR im Monat auch billig.-
Hi,
Businesspackeet sind shared hosting.
Und ich finde 10EUR im Monat auch billig.Ja, das klingt überzeugend. :-)
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
-
-
-
-
-
-
-
-
-
-
-
-
-
Hi,
Der HTML-Code wird übrigens von einem PHP-Script erzeugt und enthält sehr viele dieser Links, deshalb möchte ich nicht für jeden Link ein Formular definieren.
Packe die Parameter trotzdem in den URL. Wenn JavaScript vorhanden ist, laß es ein POST-Formular erzeugen, die Parameter bei einem onClick auslesen, ins Formular schreiben, und statt dem Link zu folgen, machst Du dann ein submit() des Formulars.
Ist JS nicht aktiv, geht's halt normal über GET.
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"! -
Hallo,
ich ahne, was Du vorhaben könntest.
WEnn Du mit einer Session arbeitest, dann braucht du die ausgewählten Werte gar nicht erst an den Client zu senden, sondern kannst sie in der (über-)nächsten Seite direkt auf dem Server in den Link einbauen.
LG
Chris