assoziativ array und $_POST

[Olaf]

Hallo,
ich versuche eine ausgefuellte assoziativ array in eine $_POST variable zu bekommen um sie dann spaeter auszulesen.

Sie kommt aber nicht richtig an.

Das Problem losgeloest von Sprachen:
a) es wird eine Seite aufgebaut auf der eine Tabelle aus einer Datenbank dargestellt (aufgelistet) wird.
b) rechts neben der Ausgabe habe ich einen link eingebaut ueber den der Benutzer eine Zeile aus der Tabelle loeschen kann.

Das Loeschen des Eintrags soll ueber das gleiche php-programm erfolgen - also ein sich-selbstaufrufendes programm.
Die Parameter moechte ich (oder muss ich) per post uebergeben (nicht ueber session) weil der benutzer verschiedene fenster / tabellen aufhaben kann.
Nun muss ich in den $_POST variablen die wichtigsten daten einpacken - um sie spaeter loeschen zu koennen.

• datenbank-name (string)
• tabellen-name (string)
• "der zu loeschende tabelleneintrag" (ein array bestehend aus "domain" => "inhalt", "domain2"=>"inhalt2", ...)

1. und 2) gehen gut. das gerufene programm kann $_POST auslesen und verarbeiten.
2. das array geht einfach nicht.

Hier das EINPACKEN von der dritten variablen:
echo '<input type="hidden" name="dsatz" value='.$dsatz.'>';

die variable $dsatz hat zu diesem Zeitpunkt folgenden Inhhalt:
array(21) { ["index"]=>  string(1) "1" ["Mitgliedsnr"]=>  string(3) "749" ["Name"]=>  string(5) "Name1" ["Vorname"]=>  string(7) "Vornam1" ["Block"]=>  string(1) "9" ["Strasse"]=>  string(4) "Weg1" ["PLZ"]=>  string(5) "12045" ["Ort"]=>  string(6) "Berlin" ["B07"]=>  string(0) "" ["B08"]=>  string(0) "" ["Telefon"]=>  string(0) "" ["email"]=>  string(0) "" ["Geburtstag"]=>  string(10) "1923-09-27" ["Hochzeitstag"]=>  string(10) "1949-07-02" ["Geburtsort"]=>  string(6) "Berlin" ["Beruf"]=>  string(12) "keine Angabe" ["Ehepartner"]=>  string(0) "" ["Geb-Ehep"]=>  string(10) "0000-00-00" ["Eintritt"]=>  string(10) "1980-10-01" ["Austritt"]=>  string(10) "0000-00-00" ["Kommentar"]=>  string(0) "" }
man sieht also die domain-namen und deren inhalt.
so will ich es auch empfangen.

Das AUSPACKEN:
$tableline = $_POST["dsatz"];

die variable $tableline enthaelt den inhalt (var_dump)string(5) "Array"
die folgenden funktionen gehen in's leere:
Warning: reset() [function.reset]: Passed variable is not an array or object in C:\Programme\xampp\htdocs\myweb2007\verschluesselt\mydata\tableselected.php on line 124

wie muss ich die variable entweder a) einpacken oder b) auspacken um an die Inhalte zu kommen?

Herzlichen Dank,
Olaf.

[Norbert]

Hallo Olaf,

zuerst mal ein bissel Grundlagen (sorry):

Die Variablen in $_POST sind immer Strings mit in URL's zulaessigen Zeichen.
Ergo, wenn man ein Array einer $_POST-Variablen zuordnen moechte muss man es
in einen URL-kodierten String umwandeln. Wie geht das:
1. mit serialize()
2. und mit addslashes()
3. abschliessend mit urlencodet() oder base64_encodet()

HTH

Gruss Norbert

[Sven Rautenberg]

Moin!

zuerst mal ein bissel Grundlagen (sorry):

Ok, dann mußt du dir die Grundlagen auch nochmal anhören.

Die Variablen in $_POST sind immer Strings mit in URL's zulaessigen Zeichen.

Falsch. In $_POST (also zu dem Zeitpunkt, wo PHP läuft) sind hierdrin absolut beliebige Zeichen möglich, alle Bytewerte von 0 bis 255. PHP hat die übermittelten (und dort u.U. url-codierten) Daten ja bereits dekodiert.

Ergo, wenn man ein Array einer $_POST-Variablen zuordnen moechte muss man es
in einen URL-kodierten String umwandeln.

Allgemein gesprochen hängt es vom konkreten Mechanismus ab. Bei der Übermittlung in einem versteckten Formularfeld liegst du aber falsch.

1. mit serialize()

Das ist korrekt.

2. und mit addslashes()

Absolut falsch.

3. abschliessend mit urlencodet() oder base64_encodet()

Vollkommen unnötig.

Was fehlt: htmlspecialchars().

- Sven Rautenberg

[Norbert]

Hallo Sven,

nix gegen Korrekturen Herr Lehrer, nur stimmen muessten sie dann schon.
Sieht sonst sehr bloed aus ...

1. mit serialize()
   Das ist korrekt.

wie gnaedig ... ;-)

2. und mit addslashes()
   Absolut falsch.

aha,
und was glaubst Du passiert mit diesem Feld:
<input type="hidden" name="A" value="Sven glaubt ohne "addslashes" auszukommen">

3. abschliessend mit urlencodet() oder base64_encodet()
   Vollkommen unnötig.

Schlaumeier,
lies doch mal in den RFC's nach, welche Zeichen bei der Datenuebertragung zulaessig sind.
Was vorher oder nachher PHP damit anstellt, ist dem http-Protokoll echt schnuppe!

Was fehlt: htmlspecialchars().

aha,
wenn Du meinst, ich habe es noch nie gebraucht ...
aber es schadet sicher auch nicht, ausser bei der Performace.

Gruss Norbert

[Cheatah]

Hi,

nix gegen Korrekturen Herr Lehrer, nur stimmen muessten sie dann schon.
Sieht sonst sehr bloed aus ...

na, man gut, dass diese Deine Befürchtung nicht zutrifft.

2. und mit addslashes()
   Absolut falsch.
   aha,
   und was glaubst Du passiert mit diesem Feld:
   <input type="hidden" name="A" value="Sven glaubt ohne "addslashes" auszukommen">

Der Wert des Eingabefeldes lautet 'Sven glaubt ohne '. Wenn Du noch addslashes() verwendest, lautet er 'Sven glaubt ohne '. Ich denke nicht, dass Dir damit viel geholfen ist.

3. abschliessend mit urlencodet() oder base64_encodet()
   Vollkommen unnötig.
   Schlaumeier,
   lies doch mal in den RFC's nach, welche Zeichen bei der Datenuebertragung zulaessig sind.

Lies Du noch mal nach, welche Kodierungen der Browser beim Versand eines Formulars vornimmt. Nebenbei könntest Du noch nachschlagen, wann die deutsche Sprache die Verwendung des Apostrophs vorsieht.

Was vorher oder nachher PHP damit anstellt, ist dem http-Protokoll echt schnuppe!

Da hast Du recht. Die Frage ist, warum Du dann mit PHP versuchst, das HTT-Protokoll zu unterstützen, bevor es verwendet wird.

Was fehlt: htmlspecialchars().
aha,
wenn Du meinst, ich habe es noch nie gebraucht ...

Tja, dann hast Du bisher definitiv etwas falsch gemacht.

aber es schadet sicher auch nicht, ausser bei der Performace.

Wahnsinnig geniale Erkenntnis: etwas falsch zu machen, weil es in etwa die selbe Rechenzeit verbrät wie der richtige Weg. Vielleicht solltest Du einen Grundsatz der Programmierung, der Informatik oder eigentlich sogar des Lebens erlernen:

Wenn man einen Wert in einen Kontext bringt, muss man ihn kontextspezifisch kodieren.

Kontextspezifisch. Nicht willkürlich.

Cheatah

[Sven Rautenberg]

Moin!

Hallo Sven,

nix gegen Korrekturen Herr Lehrer, nur stimmen muessten sie dann schon.
Sieht sonst sehr bloed aus ...

1. mit serialize()
   Das ist korrekt.
   wie gnaedig ... ;-)

2. und mit addslashes()
   Absolut falsch.
   aha,
   und was glaubst Du passiert mit diesem Feld:
   <input type="hidden" name="A" value="Sven glaubt ohne "addslashes" auszukommen">

Ein Slash ist NICHT das HTML-Escaping-Zeichen. Wenn du da addslashes() benutzt, kommt raus:
<input type="hidden" name="A" value="Sven glaubt ohne /"addslashes/" auszukommen">

Damit ist dir nicht geholfen.

Mit htmlspecialchars() kommt raus:
<input type="hidden" name="A" value="Sven glaubt ohne &quot;addslashes&quot; auszukommen">

Und das ist korrektes HTML.

3. abschliessend mit urlencodet() oder base64_encodet()
   Vollkommen unnötig.
   Schlaumeier,
   lies doch mal in den RFC's nach, welche Zeichen bei der Datenuebertragung zulaessig sind.

Die Datenübertragung interessiert zum Zeitpunkt der Erstellung eines versteckten Formularfeldes absolut überhaupt nicht. Das erledigt der Browser dann, wenn das Formular wieder abgeschickt wird - andernfalls kommt es nämlich zu unschöner Doppelcodierung, die man dann serverseitig wieder rückgängig machen müßte.

Was vorher oder nachher PHP damit anstellt, ist dem http-Protokoll echt schnuppe!

Was fehlt: htmlspecialchars().
aha,
wenn Du meinst, ich habe es noch nie gebraucht ...
aber es schadet sicher auch nicht, ausser bei der Performace.

Man kann sich natürlich auch anderweitig mit urlencode() und urldecode() was zusammenfummeln. Das funktioniert aber nur deshalb "zufällig" mit versteckten Inputfeldern, weil das Resultat von urlencode() keine Zeichen produziert, die in HTML Sonderbedeutung haben.

Also hast du Glück gehabt - aber nur, weil du zufällig nicht in die Falle getappt bist.

Aber wenn du bislang von htmlspecialchars() noch nie was gehört hast, hast du mit Sicherheit Scripte produziert, die für Cross-Site-Scripting anfällig sind. Keine schöne Sache, das...

- Sven Rautenberg

[Tom]

Hello,

Ein Slash ist NICHT das HTML-Escaping-Zeichen. Wenn du da addslashes() benutzt, kommt raus:
<input type="hidden" name="A" value="Sven glaubt ohne /"addslashes/" auszukommen">

Ist Dein PHP kaputt, oder warum fügt addslashes() bei Dir tatsächlich Slashes ein und nicht Backslashes?

Verflixte Fehlbezeichnungen bei den PHP-Funktionen. Die können einen ganz schön durcheinanderbringen - gelle?

http://de2.php.net/manual/en/function.addslashes.php

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

ich versuche eine ausgefuellte assoziativ array in eine $_POST variable zu bekommen um sie dann spaeter auszulesen.

Hier das EINPACKEN von der dritten variablen:
echo '<input type="hidden" name="dsatz" value='.$dsatz.'>';

Wenn $dsatz ein Array ist, wird eine Ausgabe dieser Variablen ohne Indexangabe immer den String "Array" liefert.

Wenn die Struktur weitergegeben werden soll, nutze serialize() und später unserialize(). Bedenke aber, dass serialize() ein Resultat im Plaintext-Kontext produziert - da du den Wert aber ja in HTML ausgeben willst, ist nachfolgend auch noch das passende Escaping durch htmlspecialchars() notwendig.

die variable $dsatz hat zu diesem Zeitpunkt folgenden Inhhalt:
array(21) { ["index"]=>  string(1) "1" ["Mitgliedsnr"]=>  string(3) "749" ["Name"]=>  string(5) "Name1" ["Vorname"]=>  string(7) "Vornam1" ["Block"]=>  string(1) "9" ["Strasse"]=>  string(4) "Weg1" ["PLZ"]=>  string(5) "12045" ["Ort"]=>  string(6) "Berlin" ["B07"]=>  string(0) "" ["B08"]=>  string(0) "" ["Telefon"]=>  string(0) "" ["email"]=>  string(0) "" ["Geburtstag"]=>  string(10) "1923-09-27" ["Hochzeitstag"]=>  string(10) "1949-07-02" ["Geburtsort"]=>  string(6) "Berlin" ["Beruf"]=>  string(12) "keine Angabe" ["Ehepartner"]=>  string(0) "" ["Geb-Ehep"]=>  string(10) "0000-00-00" ["Eintritt"]=>  string(10) "1980-10-01" ["Austritt"]=>  string(10) "0000-00-00" ["Kommentar"]=>  string(0) "" }
man sieht also die domain-namen und deren inhalt.

Bedenke, dass der Benutzer diese Daten beliebig manipulieren kann. Wenn dir deine Daten etwas wert sind, dann darfst du dich nicht darauf verlassen, dass das, was du dem Browser schickst, in identischer Form genauso wieder zurückkommt!!!

- Sven Rautenberg

[Olaf]

Moin!

Wenn die Struktur weitergegeben werden soll, nutze serialize() und später unserialize(). Bedenke aber, dass serialize() ein Resultat im Plaintext-Kontext produziert - da du den Wert aber ja in HTML ausgeben willst, ist nachfolgend auch noch das passende Escaping durch htmlspecialchars() notwendig.

Bedenke, dass der Benutzer diese Daten beliebig manipulieren kann. Wenn dir deine Daten etwas wert sind, dann darfst du dich nicht darauf verlassen, dass das, was du dem Browser schickst, in identischer Form genauso wieder zurückkommt!!!

• Sven Rautenberg

Hallo Sven, Hallo Alle,
vielen Dank - bin fast durch. Eure (allerseits) guten Hilfestellung haben mich fast an's Ziel gebracht.

habe nun folgendes (Problem steht unten)
einpacken (vor dem posten):
      $tmp=serialize($array);if (!$tmp){$tmp="hilfe";}
      echo '<input type="hidden" name="unique" value="'.htmlspecialchars($tmp,ENT_QUOTES).'">';
habe also
a) erst serialized dann
b) htmlspecialchars laufen lassen.
Ergebniss ist:
string(31) "a:1:{s:5:"index";s:2:"22";}"

FRAGE:
warum ist dort ein backslash drin und nicht das html-verklauselte???

AUSPACKEN:
if (isset ($_POST["unique"]))
  {
  $tmp=$_POST["unique"];
  $tmp2=stripslashes(htmlspecialchars_decode($tmp,ENT_QUOTES));
  echo __LINE__.' nach decode '.$tmp2.'<br>';
  $uniqueidents = unserialize($tmp2);
  if (!$uniqueidents){echo __LINE__.' unserialize nicht funk. Hilfe <br>';}
  }
ACHTUNG:
nach einem einfach "htmlspecialchars_decode" sieht der string absolut identisch aus (also mit den backslash) => ergebnis: das unserialize funkt. nicht!!!!
ich habe (mehr aus testzwecken) ein stripsslahes davorgeschaltet und nun tut's das ding.

2 Fragen:
A) warum enthaellt der string nach dem einpacken durch htmlspecialchars backslashs?
B) warum funktioniert das htmlspecialchars_decode nicht in soweit als dass das Ergebnis so aussieht wie der urspruengliche string?

PS:
vielleicht wichtig: ich teste local mit apache (kann es irgendwie daran liegen? - Ich denke nein, da wir ja hier ueber PHP-functions sprechen; aber wer weiss schon).

Ich hoffe, Ihr habt auch dazu eine Antwort.
fg,
Olaf.

[Sven Rautenberg]

Moin!

habe nun folgendes (Problem steht unten)
einpacken (vor dem posten):
      $tmp=serialize($array);if (!$tmp){$tmp="hilfe";}

Wozu das IF? Serialize liefert dir IMMER einen String. In dem String sind IMMER Zeichen drin. Selbst bei undefinierten Variablen kriegst du den String "N;" raus.

Also schmeiß dein IF raus, es wird den Vorgang nur stören.

echo '<input type="hidden" name="unique" value="'.htmlspecialchars($tmp,ENT_QUOTES).'">';

Das ist soweit OK.

habe also
a) erst serialized dann
b) htmlspecialchars laufen lassen.
Ergebniss ist:
string(31) "a:1:{s:5:"index";s:2:"22";}"

Das kann nicht das Ergebnis sein, weil du oben ein Echo mit der Ausgabe eines Input-Feldes hingeschrieben hast. Was kommt im Browser-Quelltext an?

FRAGE:
warum ist dort ein backslash drin und nicht das html-verklauselte???

AUSPACKEN:
if (isset ($_POST["unique"]))
  {
  $tmp=$_POST["unique"];

Man kann es mit dem Kopieren von Variablen auch übertreiben!

$tmp2=stripslashes(htmlspecialchars_decode($tmp,ENT_QUOTES));

Niemand hat davon geschrieben, dass htmlspecialchars_decode aufzurufen ist! Die htmlspecialchars() wird vom Browser rückgängig gemacht.

stripslashes() darf nur aufgerufen werden, wenn dein Server mit der Funktion get_magic_quotes_gpc() eine 1 zurückgibt (also "true")!

echo __LINE__.' nach decode '.$tmp2.'<br>';
  $uniqueidents = unserialize($tmp2);

Das sollte dann problemlos funktionieren.

if (!$uniqueidents){echo __LINE__.' unserialize nicht funk. Hilfe <br>';}

Diese Abfrage ist unsinnig. In $uniqidents kann nach der Wiederherstellung ja ein Wert enthalten sein, der nach "false" evaluiert, beispielsweise ein leeres Array.

}

2 Fragen:
A) warum enthaellt der string nach dem einpacken durch htmlspecialchars backslashs?

Unbekannt. Wie ist dein PHP konfiguriert? magic_quotes etc.

B) warum funktioniert das htmlspecialchars_decode nicht in soweit als dass das Ergebnis so aussieht wie der urspruengliche string?

Du darfst es dort ja nicht anwenden, weil der String kein HTML ist, sondern Plaintext.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Es ist anzumerken, dass der Datentransfer von Strings, die Zeilenschaltungen (\r oder \n) enthalten, genau dann SCHEITERT, wenn man das Formularfeld vom Typ hidden auf Typ text ändert, oder eine Textarea verwendet.

Der Grund: Die HTML-Interpretation des Quelltextes greift in die Darstellung der Zeilenschaltung ein, wenn der Textinhalt des Feldes sichtbar dargestellt werden soll.

Dieses Skript funktioniert bei mir in allen drei Browsern (Op, FF, IE):

  
<?php  
echo "<pre>";  
  
// ein komplexes Array  
$array = array('keytest' => 'val   "test"   ', 3=> "\r\n   \t\t\tdrei   spaces   ", array(1,2,3,4,5));  
echo "\n\nDas Array\n";  
var_dump ($array);  
  
$ser = serialize($array);  
echo "\n\nSerialisiert:\n";  
var_dump ($ser);  
  
echo "\n\nFormular\n";  
  
echo '<form action="" method="post"><input type="hidden" name="test" value="'.htmlspecialchars($ser,ENT_QUOTES).'" size="100"><input type="submit"></form>';  
  
if (isset($_POST['test']))  
{  
  echo "\n\nPOST-Daten:\n";  
  var_dump($_POST['test']);  
  
  echo "\n\nUnserialisiert:\n";  
  $var = unserialize($_POST['test']);  
  var_dump($var);  
  echo ($array === $var ? "identisch": "nicht identisch");  
}  
echo "</pre>";  
?>  

- Sven Rautenberg

[Olaf]

• Sven Rautenberg

Hallo Sven,

vielen Dank fuerdas script!!!

Wie soll denn Ergebnis aussehen? Ich vermute identisch.
Habe das script als test.php abgespeichert und laufen lassen.
Das Ergebnis bei mir:

POST-Daten:
string(137) "a:3:{s:7:"keytest";s:15:"val   "test"   ";i:3;s:24:"
      drei   spaces   ";i:4;a:5:{i:0;i:1;i:1;i:2;i:2;i:3;i:3;i:4;i:4;i:5;}}"

Unserialisiert:
bool(false)
nicht identisch

==> nicht identisch - wie bei meinem Problem.
Liegt vielleicht doch an meiner localen Umgebung? Kann das irgentwie sein?

Danke,
Olaf.

[Sven Rautenberg]

Moin!

Das Ergebnis bei mir:

POST-Daten:
string(137) "a:3:{s:7:"keytest";s:15:"val   "test"   ";i:3;s:24:"
      drei   spaces   ";i:4;a:5:{i:0;i:1;i:1;i:2;i:2;i:3;i:3;i:4;i:4;i:5;}}"

Dein PHP ist "schlecht" konfiguriert, es hat magic_quotes_gpc aktiviert. Und vermutlich auch noch andere Grausamkeiten wie register_globals und allow_url_fopen. Das solltest du mal alles deaktivieren in deiner php.ini.

Alternativ und speziell für deinen Fall:

  
if (get_magic_quotes_gpc()) { $_POST['test'] = stripslashes($_POST['test']); }  

Das in das "Formularabsende-IF" an erste Position sollte auch bei dir zum Erfolg führen.

- Sven Rautenberg

[Tom]

Hello Olaf,

ich habe mir den Thread mehrfach durchgelesen, und verstehe eigentlich die Agressivität nicht, die da aufkommt. Du fragst, weil Du es nicht weißt und nicht, weil Du Sozialhilfe beantragen willst. Viele der Amtsvertreter haben ungefähr den gleichen Ton drauf, wie einige hier im Thread! Meine Nachbarn berichten mir täglich davon. :-( Wer beim Antworten nicht freundlich bleiben will, sollte mal wieder schlafen gehen. Danach geht es wieder!

Also, auch wenn ich nun gleich die Schläge abbekomme:

Wenn Du statt htmlspecialchars() gleich base64_encode() und dann anders herum auch base64_decode() genommen hättest, dann wären die Probleme mit Magic_quotes usw. gar nicht erst aufgetaucht.

Du willst die Daten im Browser auch nicht HTML-gerecht darstellen lassen, sondern nur erreichen, dass sie HTTP-konform hin und zurück übertragen werden können, ohne an einer Stelle eine automatsiche Manipulation zu erfahren, oder den zulässigen Bereich zu verlassen. Auch eine Manipulation durch den User soll nicht provoziert werden.

Wenn Du nun eine Untermenge des Zeichensatzes benutzt, die diese Bedingungen erfüllt, bist Du genauso auf der sicheren Seite. Wer da jetzt kommen sollte und beahuptet, nur htmlspecialchars() wäre hier richtig, der hat vermutlich vor, den gesamten HTTP-Standard zu ändern. ;-)

Daten mit serialize() serialisieren
serialisierte Daten mit base64_encode codieren
  (damit sie überall innerhalb der Spezifikation liegen)
Response -> Daten übertragen
Request -> Daten zurücksenden
base64_encode() Daten wieder decodieren
unserialize() _mit_ Erfolgskontrolle.

Daten benutzten

An einem Hidden-Feld in der Darstellung nach einem Serialize() + htmlspecialchars() wird außerdem eher schon mal herumprobiert, als an einem mit base64_encode() verpackten. Das mag sich nach diesem Thread vielleicht ändern, aber bisher waran das die Erfahrungswerte :-)

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Wenn Du statt htmlspecialchars() gleich base64_encode() und dann anders herum auch base64_decode() genommen hättest, dann wären die Probleme mit Magic_quotes usw. gar nicht erst aufgetaucht.

Vom praktischen Standpunkt aus gesehen ist das eine brauchbare Lösung. Sie erhöht aber die zu übertragende Datenmenge. Das kann hier als vernachlässigbar gelten, weil es, kommt es wirklich auf sparsame Übertragung an, sicher bessere Lösungen gibt. Beispielsweise reicht im Allgemeinen die Übertragung der Datensatz-ID aus, um den zu löschenden Datensatz zu identifizieren.

Wenn diese Lösung verwendet wird, um Magic Quotes zu umgehen, dann ist das allerdings ein sehr schlechtes Argument. Magic Quotes stören überall, nicht nur in diesem Fall. Es wäre also sehr sinnvoll, das Magic-Quotes-Problem gleich richtig zu beseitigen.

echo "$verabschiedung $name";

[Tom]

Hello,

Wenn diese Lösung verwendet wird, um Magic Quotes zu umgehen, dann ist das allerdings ein sehr schlechtes Argument. Magic Quotes stören überall, nicht nur in diesem Fall. Es wäre also sehr sinnvoll, das Magic-Quotes-Problem gleich richtig zu beseitigen.

Ja, das wäre sinnvoll.
Und den User vorm Client-PC am besten gleich mit. Der will ja sowieso immer nur an den Daten rumspielen ;-))

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom