geloescht_JesterDay

function insertText(source, target) { target.value = target.value + source.value; } . . . . <textarea name="Text" id="target_text"> Guten Tag </textarea> <select name="Anrede" onchange="insertText(this, document.getElementById('target_text'))" > <option value="Herr">Herr</option> <option value="Frau">Frau</option> </select> ungetestet!

<input type="button" name="component" value="Continue" onclick="self.location.href='http://meinServer.tld/meineSeite.html'" />

Hab mit FP keinerlei Erfahrung, aber wenn er 404 bringt würd ich mal sagen, die Action in deinem Formular verweisst nicht auf die richtige Seite. Was hast du denn da drinstehen?

Hab heute wieder die "perfekte Welle" im Radio gehört. Die Zeit der "Verbannung" scheint wohl vorbei zu sein... Oder ist der "Schiedrichterskandal" mittlerweile wichtiger? Was sagt uns das? Erst groß Mittleid und Betroffenheit heucheln (muss ich einfach so sagen, sollte keiner pers. nehmen und ich kann ja nicht für alle sprechen bzw. alle meinen) und kurze Zeit später ist alles wieder "as usual". And now for something completely different...

procedure SplitString(const St, DelimitedBy: string; var Substr1, Substr2: string); var I: Integer; S : string; begin // Zwischenkopie um überschreiben von St zu verhindern S:= st; I:= Pos(DelimitedBy, S); if I > 0 then begin Substr1:= Copy(S, 1, I-1); Substr2:= Copy(S, I+Length(DelimitedBy), Length(S)); end else begin Substr1:= S; Substr2:= ''; end; end; Eigentlich nichts anderes, als davor schon beschrieben.

Naja, eigentlich brauchst du nix anderes als einen Datei-Upload, allerdings nicht als Datei Sprich: Du brauchst ein Programm, dass ausserhalb vom Webserver läuft und das Clipboard überwacht. Im Clipboard wird ja die zu kopierende Datei abgelegt mit einem Kenner um was es sich handelt. Dein Programm müsste einfach den Inhalt vom Clipboard nehmen (wenn es sich um ein Bild handelt) und ihn als Text wieder ins Clipboard schreiben. Dann geht ein CTRL+V in ein Textfeld deines Formulars. Dein Programm auf dem Server wiederum muss diesen "Text" dann in eine DB speichern oder eine Datei. Der Benutzer sieht halt vom Bild nich viel. Das müsste so irgendwie gehen, hab es aber in der Art noch nie probiert. Ist nur ne Idee. Mir fällt grad nochwas ein... wenn du eh ein Programm dafür schreibst (oder schreiben lässt o.ä.) kann dieses das Bild auch "direkt" an den Server senden. Wäre noch einfacher und der Nutzer könnte dann auch das Bild sehen bevor er es losschickt. EDIT: Innerhalb des Browsers seh ich direkt keine Möglichkeit für sowas.

Wie Enrico sagte liegt es wohl daran, dass die PHP-Datei schon durch den Parser geht, bevor sie bei dir ankommt. D.h. du kannst aber dann auch PArameter mitgeben: include ("http://server/Datei.php?msg=Fehlermeldung"); Link siehe oben

http://de2.php.net/include/ Es gibt aber auch die Möglichkeit, das include auf bestimmte Ordner zu beschränken. Du solltest mal in der php.ini nachsehen ob das der Fall ist. Ansonsten sollte es kein Problem sein. Stimmt der Variablenname im includierten Formular? Bzw. wird das Formular aus der externen Datei überhaupt angezeigt? Ansich sollte das so gehen.

Was du verhindern willst ist ja, dass der Browser an bestimmte Ziele im Internet, die du aber nicht kennst, Daten schickt. Wie du wohl schon siehst, ist das eher unmöglich. Der Browser ruft nur eine neue Seite vom Server ab und übergibt vielleicht noch einen Text aus einem Formularfeld. Die neue "Seite" benutzt dieses Feld dann, um es an irgendjemand zu schicken aber ohne das du auch nur das geringste davon mitbekommst (ausser, die Seite zeigt eine Bestätigung an). Eine Möglichkeit das zu verhindern ist aber: Ein großer Zettel am Bildschirm mit dem Inhalt: "Bitte keine Mails über irgendwelche Webseiten ausser GMX, WEB.de o.ä. versenden" und vertrauen in die Benutzer des Rechners.

Es sind 400 Bilder, 51 Pixel breit und 38 Pixel hoch (geh mal davon aus, dass alle so sind). Das macht 1 bild mit 1200 Px Breite und 760 Px Höhe. Geschätzt sind die 300 kB groß zusammen. Ein JPEG mit der Auflösung und 300kB Größe kannst du (da bin ich mir 99% sicher) ohne sichtbaren Qualitätsverlust auf gut 1/3 der Größe reduzieren. Ausserdem bedeutet jedes bild eine neue Anfrage an den Server. Also 1 Bild mit 500kB wird bestimmt schneller übertragen als 100 Bilder mit 5kB. Ausserdem sieht es mit dieser Zerstückelung IMHO grausig aus. Dann lieber ein JPEG im Progressiv Mode speichern. Das wird zuerst unscharf dargestellt und je mehr Daten übertragen sind, desto schärfer wird das Bild.

Nimm position:absolute in der Klasse Karte raus, dann ist die Karte zentriert.

Also du kannst nichts mehr erkennen, für ein Programm ist es aber kein Problem ASCII-Zeichen auszuwerten. Natürlich kann ein Spambot theoretisch auch Javascript auswerten (oder auch Flash o.ä.) Eigentlich ist nichts sicher, solange es beim Browser ankommen soll. Ist wie der Kopierschutz bei CDs Ich hab es bei mir aber so gemacht: <script type="text/javascript"> <!-- var name = "name"; var domain = "domainp.de"; document.write('<a href=\"mailto:' + name + '@' + domain + '\">'); // --> </script> <img src="images/mail.gif" width="200" height="60" alt="mail" /> <script type="text/javascript"> <!-- document.write('<\/a>'); // --> </script>

Ein 401 ist nichts anderes, als der Server schickt, wenn in der config oder einer .htaccess Datei eine authorisierung vorgesehen ist. Ok, da es sich um eine einzelne Seite handelt ginge das hier wohl, sobald aber mehr als eine Seite im spiel ist nicht mehr (bzw. mit einer Anmeldung auf jeder Seite). War ein Fehler von mir.

Mir ist nichts derartiges bekannt. Um dies zu erreichen, muss das ganze ja beim Rendern der Seite geschehen. Es gibt zwar ne Menge "Erweiterungen" für den IE (AdvancedBrowser, T-Online-Browser etc.) aber die setzen alle auf der IE-Rendering DLL auf. Also sie nutzen den IE, bauen aber ne eigene Oberfläche drumrum. Da man aber an die DLL selber (den Quelltext bzw. das was sie zur Laufzeit tut) nicht rankommt, seh ich da auch wenig Möglichkeiten. Was heisst, du bist auf den IE angewiesen? Dass alle im Unternehmen den IE verwenden und du deine Seiten darauf abstimmen musst ist ja eine Sache, das heisst ja aber nicht, dass du zum Entwickeln nicht ein geeigneteres Werkzeug nehmen kannst (kostet nochdazu ja nichts). Musst halt immer im IE gegentesten (sollte man eh tun). Oder kannst du das auch nicht (den FF + WebDeveloper-Extension auf deinem Rechner installieren)?

Er sagte aber, dass htaccess ausscheidet. Also kann er dem Webserver seinen "Realm" (den Bereich, der geschützt ist) garnicht mitteilen (denke mal er wird dann auch keinen Zzugriff auf die Serverkonfiguration haben). Ausserdem kann er auch kein htpasswd angeben und auch nicht, was für User für diese Authentifizierung gültig sind. HTTP-Authentisierung schön und gut, aber hier wohl eher fehl am Platz.

Du packst die Logindaten in eine PHP-Datei, die du ausserhalb des Webpfades ablegst. Also so, dass du über den Webserver keinen zugriff darauf hast. z.B. <?php $dbhost = "localhost"; $dbname = "test"; $dbname = "dblogin"; $dbpasswd = "12345"; ?> [/php] In deiner Datei bindest du die Datei dann per include ein. PHP hat Zugriff auf die Datei (wenn die Berechtigung stimmt) aber sonst keiner.

funktioniert so leider nich Man gekommt damit nur den Inhalt der Parameter. Aber anlehnend an diese Idee hab ich jetzt ne Function gemacht: function SetQueryString($arReplace) { foreach($arReplace as $key => $val) $_GET[$key] = $val; $result = ""; foreach($_GET as $key => $val) $result .= $key."=".$val."&"; return $result; } ... $QString = SetQueryString(array("ac" => "edit", "id" => $user_t["id"])); [/php]

hab es jetzt so gelöst: $QString = ""; foreach($_GET as $key => $val) { if ($key != "ac" && $key != "id") $QString .= $key."=".$val."&"; } // Action und ID setzen $QString .= "ac=edit&id=". $user_t["id"]; [/php] bin noch am überlegen ob und wie ich das vielleicht in eine function umwandel... EDIT: Die 2te Idee von Enrico hört sich auch interessant an, werd das mal probieren.

Die Erfahrung hab ich noch nicht gemacht. Kannte nur die Möglichkeit, bei PHP in der config anzugeben, dass die Session-ID immer automatisch in der URL mit übergeben werden soll.

Hallo, ich habe folgendes Problem: In einer PHP Seite gibt es Links, die die Seite selbst wieder aufrufen, allerdings mit geänderten Parametern. Also: das erste mal: seite.php?page=user 2tes mal: seite.php?page=user&id=2 3tes mal: seite.php?page=user&id=4 Den link dynamisch zu erstellen ist nicht das Problem. gibt es aber eine Möglichkeit, den Querystring direkt zu ändern? Also so ungefähr: $_GET["id"] = 4 und dann mit self.location.href=\''.$_SERVER["PHP_SELF"]."?".$_SERVER["QUERY_STRING"].'\'" / >'; den "richtigen" string dastehen zu haben? Oder kann ich das nur machen, indem ich den String jedesmal "von Hand" wieder aufbaue?

Aber nur, wenn die Sesion-ID in der URL übergeben wird. Dann besteht aber die "Gefahr", dass ein User z.B. die URL kopiert und per Mail an jemanden schickt oder als Bookmark mitsamt der Session-ID speichert. So würde immer wieder dieselbe Session benutzt werden, da die Chance, dass die Session gelöscht wird standardmäßig nur 1:100 ist (bei jedem session_start(); wenn die session länger als 1440 sek nicht genutzt wurde). EDIT: Eine Session benutzt normalerweise auch cookies. Der Unterschied ist, dass die relevanten Daten bei der Session auf dem Server bleiben und das Cookie eben beim Client liegt und manipuliert werden kann.

Ja, das kannst du mit PHP machen. Du musst nur deine Seite "MailHighScore.php" aufrufen und den Punktestand übergeben, also z.B.: http://MeinServer.tld/MailHighScore.php?score=100 Wie du siehst läßt du damit aber alle Türe für Manipulation offen. Ich würde dir also raten, das ganze irgendwie zu codieren. In der phpSeite würde dann ung. sowas stehen: mail("HighScore@MeinServer.tld", "Neue Score", $_GET["score"]); [/php] Kenne mich mit Flash nicht aus, aber: Wenn du schon PHP nutzt, wieso schreibst du die score dann nicht gleich in eine Datei und liest die in deinem Spiel jedesmal ein?

Glaub ich eher nicht. Auch der IE sucht ja bei eingaben ohne Protokoll (http://, ftp://, file:// ...) alle Protokolle ab. Aber wenn das als Link in einer Seite steht geht jeder Browser erstmal vom aktuellen Pfad aus und sucht dort den Unterpfad/die Datei. Ein Link auf eine 2te Seite geht ja auch mit ... href="Seite2.html" und keiner würde auf die Idee kommen, da ein http:// davorzuhängen

Als md5-Hash ist es schon sicherer, weil dann keiner das PW lesen kann, auch wenn er Zugirff auf den Server hat. Der Fall oben (der ja fast deiner ist) ist ansich auch ok, es kann aber schon möglichkeiten geben, in der das PW dann ausgelesen werden kann. Normalerweise geht eine solche Seite ja immer durch den PHP-Interpreter und der gibt den PHP-code nicht aus. Was aber, wenn nach irgendeiner Änderung am Server das nicht mehr wie gewollt funktioniert? Dann wäre es (zumindest für kurze Zeit vielleicht) u.U. Möglich das PW auszulesen. Daher solltest du das PW eher in einer eigenen (php-)Datei ausserhalb des Webpfades ablegen und dann per Include einbinden. Die md5-Variante wäre dem aber vorzuziehen.