$_GET vs. $_POST

[timur]

Hallo,

es gibt ja bei PHP die Möglichkeit, mit GET und POST Formularfelder auf eine bestimmte Seite weiterzuübergeben.

POST verschickt alles versteckt. Das ist mir klar.
GET verschickt alles über die URL Leiste. Das ist mir auch klar.

Gibt es aber eine Möglichkeit nur bestimmte Formularfelder via GET an die URL weiterzugeben???

Bei GET ist es ja so, egal wo im Formular NAME steht, wird diser mitgesendet. Ich aber will bestimmte NAME weitergeben lassen, nicht alle.

Viele Grüße
Timur

[Beat]

es gibt ja bei PHP die Möglichkeit, mit GET und POST Formularfelder auf eine bestimmte Seite weiterzuübergeben.

POST verschickt alles versteckt. Das ist mir klar.
GET verschickt alles über die URL Leiste. Das ist mir auch klar.

Gibt es aber eine Möglichkeit nur bestimmte Formularfelder via GET an die URL weiterzugeben???

Ist deine Frage: Wie deaktiviere ich einzelne Formularfelder?
Verwende das dissabled Attribut.

mfg Beat

[timur]

hallo,

das mit disable ist keine gute idee, das ist so:

ich brauche einige Felder auf einer seite und einige felder auf der anderen seite.

die namen von den feldern zu entfernen hilft mir auch nicht.

Aber wie kann ich in einem formular zwei submits button unterkriegen? wenn man auf das eine klickt, soll dann seite a.php sich öffnen und in der url kann meinetwegen alles stehen und wenn man auf das andere submit button klickt soll sich b.php öffenen,

habe so was versucht hat aber nicht geklappt:

<form action="<?PHP if(isset($_GET['skript18'])){echo "a.php";}else{echo"b.php";}?>" method="get">

könnt ihr mir helfen?

[timur]

hallo,

ich habe es so gemacht:

<input type="submit" value="Abschicken" onClick="document.theForm.action='a.php'"

ist das vernünftig oder bullshit???

Gruß
Timur

[Beat]

ich habe es so gemacht:

<input type="submit" value="Abschicken" onClick="document.theForm.action='a.php'"

ist das vernünftig oder bullshit???

Kommt darauf an. Wenn du die Kacke eh schon gekauft hast...

Gib dem Submit-Button ein name="submit"
Dadurch kannst du dem Server testen ob $_POST['submit'] eq 'Abschicken'

PS: Ich finde Letzteres aber gerade in einer I18N Umgebung eher unvorteilhaft.

mfg Beat

[timur]

eine letzte frage habe ich noch.

ist es möglich leere felder nicht mit zusenden, ich meine dass in der adresszeile die einträge nicht auftauchen.

gruß
timur

[Beat]

eine letzte frage habe ich noch.

ist es möglich leere felder nicht mit zusenden, ich meine dass in der adresszeile die einträge nicht auftauchen.

verwende Post
oder entferne das name attribut
oder setze dissabled.

mfg Beat

[Malcolm Beck´s]

hi,

ist es möglich leere felder nicht mit zusenden, ich meine dass in der adresszeile die einträge nicht auftauchen.

Klar, eine etwas komplexere Variante wäre:

-- Formular per POST aufbauen
-- nach submit prüfen, welche Felder Leer sind, diese dann „unset()“ten
-- aus den restlichen Werten einen Query bauen: name=icke&amp;strasse=dortdrüben&amp;stadt=irgendwo
-- diesen Query dann einfach an ein header redirect übergeben und die Seite mit den gewünschten Parametern aufrufen

Vereinfacht:

$Query = ''; // initialsieren  
  
if (isset($_POST))  
{  
  foreach($_POST as $key => $val)  
  {  
    if (empty($val)) // wenn Variable Leer  
    {  
      unset($key);  // aus dem Array entfernen  
    }  
    else  
    {  
      $Query .= $key . '=' . $val . '&'; // escapen wird hier nicht berücksichtigt  
    }  
      $Query = rtrim($Query , '&');  // letztes „&“ entfernen  
  }  
  if (isset($_POST['submit']))  
  {  
    header("Location: http://" . $_SERVER['HTTP_HOST'] . $_SERVER['PHP_SELF'] . '?' . $Query);  
  }  
}

Ungetestet, sollte aber in die richtige richtung gehen.

mfg

[Tom]

Hello,

ist es möglich leere felder nicht mit zusenden, ich meine dass in der adresszeile die einträge nicht auftauchen.

Das ist teilweise sogar so.
Kontrollelemetne, wie Radio-Elemente, Checkboxen und Select-Elemente werden nur übertragen, wenn sie ausgewählt wurden.

Das ist aber gar nicht so praktisch, da man dann im Backend nicht so leicht sehen kann, dass man etwas wieder ausschalten / abwählen will. Das gilt natürlich auch für Textfelder. Angenommen, Du hast ein Affenformular gebaut und willst nun in einem Feld den Text wieder beseitigen. Dann hast Du dort das gleiche Problem, wie mit den Kontrollelementen.

Du kannst aber im Backend leicht abfragen, ob das Element benutzt wurde:

if (isset($_POST['element']) and strlen($_POST['element'] > 0)
    {
        ## Feld wurde benutzt
    }

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[Der Martin]

Moin,

Kontrollelemetne, wie Radio-Elemente, Checkboxen und Select-Elemente werden nur übertragen, wenn sie ausgewählt wurden.

ja, stimmt.

[...] Das gilt natürlich auch für Textfelder.

Nein.

<form action="" method="get">
   <input type="text" name="feld1">
   <input type="text" name="feld2">
   <input type="submit" name="submit" value="Und Ab!">
  </form>

Sendet man dieses Minimal-Formular ab, ohne in die Felder feld1 und feld2 etwas einzutragen, ergibt sich der Query-String

?feld1=&feld2=&submit=Und%20Ab!

Die beiden Textfelder werden also sehr wohl berücksichtigt, nur übermitteln sie halt -korrekterweise- Strings der Länge 0.
Danke übrigens für deinen anderen Beitrag, natürlich kann man das Vorhandensein eines bestimmten Submit-Buttons mit isset() abfragen, egal was draufsteht. Hab ich doch selbst schon oft gemacht. Ich war wohl gestern abend etwas neben der Kapp'.

Du kannst aber im Backend leicht abfragen, ob das Element benutzt wurde:

Was verstehst du hier unter "benutzt"?

if (isset($_POST['element']) and strlen($_POST['element'] > 0)
    {
        ## Feld wurde benutzt
    }

Der Kommentar sollte richtigerweise heißen: Feld enthält mindestens 1 Zeichen.
Die Prüfung auf strlen()>0 ist m.E. überflüssig. Auch mit einem Leerstring als Parameter ist isset() erfüllt, der Zugriff auf den entsprechenden $_POST- $_GET-Eintrag also ohne Fehler/Notice möglich und erlaubt.

Ciao,
 Martin

[Tom]

Hello,

[...] Das gilt natürlich auch für Textfelder.

Nein.

hey, hey! Nicht einfach verkürzt zitiren und den Sinn verdrehen!

Nochmal in extra-lang:
Das gilt auch für Textfelder, dass es unpraktische ist, wenn man nicht weiß, ob das Feld nun zurückgesetzt werden soll, oder ob es einfach "vergessen" wurde, zu übertragen, z.B. weil man im Formular einen Fehler/eine Änderung im Namen geamcht hat, aber das Backend nicht angepasst hat.

Du kannst aber im Backend leicht abfragen, ob das Element benutzt wurde:

Was verstehst du hier unter "benutzt"?

if (isset($_POST['element']) and strlen($_POST['element'] > 0)
     {
         ## Feld wurde benutzt
     }

Der Kommentar sollte richtigerweise heißen: Feld enthält mindestens 1 Zeichen.
Die Prüfung auf strlen()>0 ist m.E. überflüssig. Auch mit einem Leerstring als Parameter ist isset() erfüllt, der Zugriff auf den entsprechenden $_POST- $_GET-Eintrag also ohne Fehler/Notice möglich und erlaubt.

??? Den Satz verstehe ich nicht. Es ging doch gerade darum, festzustellen, welche Felder übertragen wurden und welche davon auch benutzt wurden. Wenn man nun unterschiedliche Formulare als Quelle hat und immer dasselbe Ziel, dann hat diese Abrage durchaus einen Sinn.

if (isset($_POST['element']) and strlen($_POST['element'] > 0)
        Element wurde übertragen            Elemetrn wurde benutzt

Das einzige, was hier wohl obsolete ist, die das trim($_POST['element']) vor dem strlen(), da dies von HTTP und PHP selber erledigt wird. Darum habe ich es hier weggelassen.

Üblicherweise prüft man das isset($_POST['element']) auch schon zu einem früheren Zeitpunkt, also dort, wo man den vorgeschriebenen Satzaufbau mit dem übermittelten des Formulares vergleicht.

Wenn das Form dann eine abweichende Anzahl Datenelemente liefert oder Kontrollelemente dabei sind, die gar nicht erwartet wurden, ist es gefaked. Übertagungsfehler kann man in dieser Schicht wohl schon ausschließen. Die würden schon auf IP-Schicht zum Fehler führen (oder doch erst in der TCP-Schicht?).

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[Der Martin]

Hallo,

»» > [...] Das gilt natürlich auch für Textfelder.
»» Nein.
hey, hey! Nicht einfach verkürzt zitiren und den Sinn verdrehen!

ich habe den Sinn genau so wiedergegeben, wie ich ihn verstanden hatte. Sorry, dann habe ich dich missverstanden. Du hattest noch das Affenformular erwähnt, und so dachte ich, du beschreibst die Situation, dass der User beim ersten Absenden etwas ins Textfeld eingetragen hat, es beim zweiten Absenden aber wieder löscht, und dass das dann leere Textfeld dann nicht mehr übertragen würde. Und das wäre falsch.

Nochmal in extra-lang:
Das gilt auch für Textfelder, dass es unpraktische ist, wenn man nicht weiß, ob das Feld nun zurückgesetzt werden soll, oder ob es einfach "vergessen" wurde, zu übertragen, z.B. weil man im Formular einen Fehler/eine Änderung im Namen geamcht hat, aber das Backend nicht angepasst hat.

Dann sprichst du von der Testphase, nicht vom produktiven Einsatz eines fertig ausgetesteten Formulars und seines Backends. Okay.

»» > Du kannst aber im Backend leicht abfragen, ob das Element benutzt wurde:
»» Was verstehst du hier unter "benutzt"?

Da du die Frage nicht beantwortet hast, mutmaße ich: Mit "benutzt" meinst du, dass ein Wert in dieses Feld eingetragen wurde?

»» Die Prüfung auf strlen()>0 ist m.E. überflüssig. Auch mit einem Leerstring als Parameter ist isset() erfüllt, der Zugriff auf den entsprechenden $_POST- $_GET-Eintrag also ohne Fehler/Notice möglich und erlaubt.
??? Den Satz verstehe ich nicht. Es ging doch gerade darum, festzustellen, welche Felder übertragen wurden und welche davon auch benutzt wurden. Wenn man nun unterschiedliche Formulare als Quelle hat und immer dasselbe Ziel, dann hat diese Abrage durchaus einen Sinn.

Sehe ich nicht so. Wenn das Formular, das abgesendet wurde, ein entsprechendes Textfeld enthält, dann wird es auch übertragen (unabhängig von seinem Inhalt). Also liefert isset($_REQUEST['feldname']) ohne Zweifel die Information: Formular enthält (k)ein Feld namens 'feldname'.
Mit der Abfrage auf strlen() prüfst du aber schon den *Inhalt* des Feldes, obwohl ein Leerstring ja in vielen Fällen auch ein gültiger Wert sein kann. Diese Prüfung sehe ich deswegen an der Stelle als unangebracht.

Das einzige, was hier wohl obsolete ist, die das trim($_POST['element']) vor dem strlen(), da dies von HTTP und PHP selber erledigt wird. Darum habe ich es hier weggelassen.

Daran habe ich jetzt nicht einmal gedacht.

Üblicherweise prüft man das isset($_POST['element']) auch schon zu einem früheren Zeitpunkt, also dort, wo man den vorgeschriebenen Satzaufbau mit dem übermittelten des Formulares vergleicht.

Ah, jetzt sind wir uns wieder einig.

Wenn das Form dann eine abweichende Anzahl Datenelemente liefert oder Kontrollelemente dabei sind, die gar nicht erwartet wurden, ist es gefaked. Übertagungsfehler kann man in dieser Schicht wohl schon ausschließen. Die würden schon auf IP-Schicht zum Fehler führen (oder doch erst in der TCP-Schicht?).

Kommt auf die Art der Fehler an.

So long,
 Martin

[Tom]

Hello,

Dann sprichst du von der Testphase, nicht vom produktiven Einsatz eines fertig ausgetesteten Formulars und seines Backends. Okay.

nein, ich spreche von der Praxis, dass sich unterschiedliche Leute, die unterschiedliche Backends benutzen, einfach auf einem gemeinsamen Backend "unterhalten" wollen. Das geschieht oft per "Post2Host", aber auch per eingener Formulare auf dem client und führt immer dann zu Problemen, wenn Änderungen nicht berücksichtigt oder wenigstens bemerkt werden.

Das "Anposten" eines fremden Backends muss nichts Böses sein und auch keinen Überfall (gwenannt: Hausdurchsuchung) durch die SST (Schäuble Sonder Truppe) rechtfertigen.

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[ChrisB]

Hi,

??? Den Satz verstehe ich nicht. Es ging doch gerade darum, festzustellen, welche Felder übertragen wurden und welche davon auch benutzt wurden. Wenn man nun unterschiedliche Formulare als Quelle hat und immer dasselbe Ziel, dann hat diese Abrage durchaus einen Sinn.

if (isset($_POST['element']) and strlen($_POST['element'] > 0)
        Element wurde übertragen            Elemetrn wurde benutzt

Wie kommst du darauf, ein Textfeld, für das ein Leerstring als Value übermittelt wurde, wäre "unbenutzt"?

Wenn ich aus meinem Online-Profil die Telefonnummer wieder rauslöschen möchte, deshalb das Feld leere - dann habe ich es sehr wohl "benutzt".
Und du würdest jetzt meinem Wunsch, das entsprechende Feld mit einem Leerstring zu updaten, nicht entsprechen wollen?

Das einzige, was hier wohl obsolete ist, die das trim($_POST['element']) vor dem strlen(), da dies von HTTP und PHP selber erledigt wird.

Das wäre mir neu.
Warum sollten HTTP oder PHP derart verfälschend in die Datenübertragung eingreifen?

MfG ChrisB

[Tom]

Hello,

Wie kommst du darauf, ein Textfeld, für das ein Leerstring als Value übermittelt wurde, wäre "unbenutzt"?

Wenn Du den Thread genau liest, wirst Du feststellen, dass es mir genau darum ging, die Definition von "unbenutzt" und ob und wie man sie umsetzen könnte.

Ich schrieb ja, dass man an einer recht frühen Stelle im Script den Vergleich anstellen sollte zwischen dem vorgegebenen "Datensatzformat" und den tatsächlich erhaltenen Parametern. Und wenn "Zwangsfelder" dann zwar da sind, aber leer, dann will man sicherlich damit kennzeichen, dass in Datenhaltung nachher (nach dem Update) auch nichts mehr drinstehen soll.

Leider funktioniert das mit Checkboxen, Radios, Selects, ... so nicht.

Der OP müsste also sowieso noch etwas darüber nachdenken, _was_ er eigentlich erreichen will, bevor er mit Aufwand am Client irgendwelche Elemente disabled, nur weil nichts drin steht...

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[Der Martin]

Hallo,

PS: Ich finde Letzteres aber gerade in einer I18N Umgebung eher unvorteilhaft.

wie gut, dass es Wikipedia gibt. Ich sehe das Kürzel "i18n" gerade zum ersten Mal, und ich könnte mir vorstellen, dass andere Mitleser ähnlich verständnislös reagieren wie ich gerade eben.

Aber zur Sache: Was hat die "Internationalisierung" damit zu tun, einzelne Formularfelder zu ignorieren, oder beim Absenden das Formularziel dynamisch neu zu definieren?

So long,
 Martin

[Rouven]

Hello,

wie gut, dass es Wikipedia gibt. Ich sehe das Kürzel "i18n" gerade zum ersten Mal, und ich könnte mir vorstellen, dass andere Mitleser ähnlich verständnislös reagieren wie ich gerade eben.

*lol* fast. Ich habs in den letzten Monaten mehrfach als Headernamespace unseres Webservice gesehen und mich immer gefragt, wer auf solche Namen kommen...

MfG
Rouven

[Beat]

Aber zur Sache: Was hat die "Internationalisierung" damit zu tun, einzelne Formularfelder zu ignorieren, oder beim Absenden das Formularziel dynamisch neu zu definieren?

Der value des Submit und Reset Buttons ist zugleich ein Label. Damit als operativer Value nicht wirklich brauchbar.
Du möchtest dein Programm nicht unnötig abhängig machen von der Sprache von Labels. Das geschieht aber, wenn der  Submit value "Abschicken" in englisch zu "Send" mutiert.

mfg Beat

[Der Martin]

Hallo,

»» Aber zur Sache: Was hat die "Internationalisierung" damit zu tun, einzelne Formularfelder zu ignorieren, oder beim Absenden das Formularziel dynamisch neu zu definieren?
Der value des Submit und Reset Buttons ist zugleich ein Label. Damit als operativer Value nicht wirklich brauchbar.

ah, jetzt verstehe ich. Daran hatte ich nicht gedacht.
Die Anzahl der unterschiedlichen Button-Beschriftungen dürfte aber im Normalfall endlich und relativ gering sein, so dass man das z.B. noch in einer switch-Anweisung abhandeln könnte.

Du möchtest dein Programm nicht unnötig abhängig machen von der Sprache von Labels. Das geschieht aber, wenn der  Submit value "Abschicken" in englisch zu "Send" mutiert.

Dem könnte man höchstens noch mit Javascript abhelfen, indem man beim Absenden das value-Attribut des verwendeten submit-Buttons oder auch eines dafür eingesetzten hidden-Felds verändert. Ich sehe die Schwachstelle ...

So long,
 Martin

[Tom]

Hello,

Dem könnte man höchstens noch mit Javascript abhelfen, indem man beim Absenden das value-Attribut des verwendeten submit-Buttons oder auch eines dafür eingesetzten hidden-Felds verändert. Ich sehe die Schwachstelle ...

*chmchm*
Was hindert Dich daran im Script

if(isset($_POST['formularname']['btn']['buttonname']))

oder es simpel zu halten im Form, wenn man Struktur nicht mag  und

if(isset($_POST['buttonname']))

zu fragen?

Da ist es ganz egal, welche Beschriftung der arme Button gerade hat.

Dass HTML etliche Ungeschliffenheiten und Absonderlichkeiten hat, also nicht durchgängig designed ist, das wissen wir doch. Wir werden das aber nicht mehr ändern, bis das Internet abgeschafft wird. (Da waren doch schon Stimmen laut geworden neulich.)

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[Der Martin]

Hallo,

[...] bis das Internet abgeschafft wird. (Da waren doch schon Stimmen laut geworden neulich.)

nun ja, es wird ja am Ende schon so langsam abgesperrt.

So long,
 Martin

[Tom]

Hello,

[...] bis das Internet abgeschafft wird. (Da waren doch schon Stimmen laut geworden neulich.)

nun ja, es wird ja am Ende schon so langsam abgesperrt.

Das war leider todernst gemeint. Es gab da neulich aus USA Stimmen aus irgendwelchen schleimigen Machtkreisen, die sagten "das Internet hätte nie erfunden werden dürfen" und es nun wieder abschaffen wollen.

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[Malcolm Beck´s]

hi Tom,

Das war leider todernst gemeint. Es gab da neulich aus USA Stimmen aus irgendwelchen schleimigen Machtkreisen, die sagten "das Internet hätte nie erfunden werden dürfen" und es nun wieder abschaffen wollen.

Ich glaub, ich weiss, was du meinst.

mfg

[Tom]

Hello,

Das war leider todernst gemeint. Es gab da neulich aus USA Stimmen aus irgendwelchen schleimigen Machtkreisen, die sagten "das Internet hätte nie erfunden werden dürfen" und es nun wieder abschaffen wollen.

Ich glaub, ich weiss, was du meinst.

Ja, ich glaube das war'a. Ich habe es nur auf n24 oder so gesehen.

Zitat aus den Bemerkungen zum Video:
There's a number of ways they can, just look at the DNS vunerabilities and the US could easily spoof DNS entries all over the world pointing to a non-existent address and effectively shut down the internet, not to mention the US controls most of the TLDs, root DNS servers, has the most physical lines layed that tie the internet together, as well as being in control of ALL IP addresses that are sold off.
#----

Ist das wirklich so leicht möglich für die Amis, den Nameservice platt zu machen?
Sollte es da nich inwischen in Europa und China eigene Zonenverwaltungen geben, die nicht einfach so alles übernehmen?

Liebe Grüße aus dem Cyberspace

Tom vom Berg

[Malcolm Beck´s]

hi,

Ist das wirklich so leicht möglich für die Amis, den Nameservice platt zu machen?
Sollte es da nich inwischen in Europa und China eigene Zonenverwaltungen geben, die nicht einfach so alles übernehmen?

Ich vermute mal, dass die Amis sich dort eine Hintertür offen gehalten haben; wer weiss.
Ich kann mir auch gut vorstellen, dass aufgrund der Terrorbekämpfung dass Internet nach und nach sich ins nichts auflösen wird, zutrauen kann man den Terrorbekämpfern ja mittlerweile alles.
Und die ersten Weichen werden ja Weltweit gelegt, Stichwort „Internet-Zensur“.

Diese Rede war wohl einfach nur einer der ersten Steine, die gelegt werden müssen, um die Menschheit auf die Zukunft der noch „freien“ Kommunikation vorzubereiten.

mfg

[Beat]

Ist das wirklich so leicht möglich für die Amis, den Nameservice platt zu machen?
Sollte es da nich inwischen in Europa und China eigene Zonenverwaltungen geben, die nicht einfach so alles übernehmen?

Ich vermute mal, dass die Amis sich dort eine Hintertür offen gehalten haben; wer weiss.
Ich kann mir auch gut vorstellen, dass aufgrund der Terrorbekämpfung dass Internet nach und nach sich ins nichts auflösen wird, zutrauen kann man den Terrorbekämpfern ja mittlerweile alles.

Es braucht keine Phantasie, sich vorzustellen, dass das ganze DNS System im Falle eines Kriegs ziemlich durcheinander geraten wird.
Da mag den USA nicht mal mehr ihr Klammern am root mehr helfen, denn das DNS-System ist primär eine Verschwörungssache.

Und die ersten Weichen werden ja Weltweit gelegt, Stichwort „Internet-Zensur“.
Diese Rede war wohl einfach nur einer der ersten Steine, die gelegt werden müssen, um die Menschheit auf die Zukunft der noch „freien“ Kommunikation vorzubereiten.

Ich sehe vor allem den Trend, dass Bandbreite für Webanbieter nicht mehr von Providern egalitär zugestanden wird, sondern irgendwann gekauft werden muss. Die Kommerzialisierung des Netzwerks wird dann den Todesstoss verleihen. Internetcafes werden dann wireder vermehrt zu Cafes umgerüstet und Verschwörungstheorien werden wieder mehr von ihrer lokalen Optik her verifiziert.

mfg Beat

[Malcolm Beck´s]

hi,

Es braucht keine Phantasie, sich vorzustellen, dass das ganze DNS System im Falle eines Kriegs ziemlich durcheinander geraten wird.
Da mag den USA nicht mal mehr ihr Klammern am root mehr helfen, denn das DNS-System ist primär eine Verschwörungssache.

Es geht ja hier nicht um Krieg, sondern um eine Informationsplattform, die von den Herrschern der Welt nicht kontrolliert werden kann. Das stinkt den Herrschaften gewaltig, daher wohl auch dieses Statement von diesem Rockefeller-Fuzzi.

Ich sehe vor allem den Trend, dass Bandbreite für Webanbieter nicht mehr von Providern egalitär zugestanden wird, sondern irgendwann gekauft werden muss. Die Kommerzialisierung des Netzwerks wird dann den Todesstoss verleihen. Internetcafes werden dann wireder vermehrt zu Cafes umgerüstet und Verschwörungstheorien werden wieder mehr von ihrer lokalen Optik her verifiziert.

Warum sollten die es sich unnötig schwer machen, einfach das Internet lahmlegen und damit war's das. Dabei spreche ich nicht mal davon, das Internet Wortwörtlich vom Netz zu nehmen, sondern um die Absolute Zensur, die jegliche Zweifel an den bestehenden Systemen auf der Welt verbietet und mit Strafen ahndet.
Wie gesagt, die Weichen werden schon seit Jahren gelegt und jetzt immer weiter verfeinert, bis wir am Ende auch im Internet nur noch dass zu sehen bekommen, was bestimmte Kreise wollen.

Das ist wie mit den Überwachungskameras, die langsam aber sicher überall in Deutschland einzug halten; damals noch ein streitthema, heute scheint es niemanden mehr zu jucken, dass immer mehr Kameras an öffentlichen stellen installiert werden.
Ich für meinen Teil finde es beunruhigend, überall sehe ich mittlerweile diese kleinen dinger; an Kreuzungen, Autobahnabfahrten, Strassen.
Was langsam begann, artet aus; so sehe ich die Zukunft des Internet; heute sind es Kinderporno seiten, schon morgen dann heisst es „Volksverhetzende[1]“ Seiten, bis das Internet nur noch ein einziger Haufen Müll ist.

mfg
[1] einige sprechen auch von Verschwörungstheoretikern

[Malcolm Beck´s]

hi,

... die Absolute Zensur, die jegliche Zweifel an den bestehenden Systemen auf der Welt verbietet und mit Strafen ahndet.
Wie gesagt, die Weichen werden schon seit Jahren gelegt und jetzt immer weiter verfeinert, bis wir am Ende auch im Internet nur noch dass zu sehen bekommen, was bestimmte Kreise wollen.

Sperre auch für legale Internetseiten  --  soviel zur Absoluten Zensur

Eventuell könnte man einen neuen Thread eröffnen, da dass sicherlich viele interessieren wird.

mfg

[ChrisB]

Hi,

habe so was versucht hat aber nicht geklappt:

Schon wieder ... du checkst es echt nicht, hm?

MfG ChrisB

[ChrisB]

Hi,

es gibt ja bei PHP die Möglichkeit, mit GET und POST Formularfelder auf eine bestimmte Seite weiterzuübergeben.

Nein, die gibt es bei HTTP.

Gibt es aber eine Möglichkeit nur bestimmte Formularfelder via GET an die URL weiterzugeben???

Per HTML höchstens die von Beat genannte.

Bei GET ist es ja so, egal wo im Formular NAME steht, wird diser mitgesendet.

Bei POST auch.

Ich aber will bestimmte NAME weitergeben lassen, nicht alle.

Dann pack' sie doch gar nicht erst ins Formular hinein.

MfG ChrisB

[Tom]

Hello,

Gibt es aber eine Möglichkeit nur bestimmte Formularfelder via GET an die URL weiterzugeben???

zusätzlich gibt es auch beim Arbieten mit Formularen noch die Möglichkeit, einige spezielle Parameter per GET und die übrigen per POST-Parameter zu übergeben. Ein POST-Request schließt den GET-Request mit ein.

<form action="mein-script.php?section=adressen&amp;id=123456" method="post">
      <input ...
      <input ...
      <input ...

</form>

und dann schau Dir mal im Script $_GET und $_POST an.

Liebe Grüße aus dem Cyberspace

Tom vom Berg