Autor: GregorWendland

Veröffentlicht am

Textfelder mit verschwindendem Standardtext bei Klick – so hat man das Früher gemacht

In manchen Website-Designs ist es nötig, die beschreibenden Felder von Textfeldern in Formularen in den Feldern selbst unterzubringen. Heute benutzt man dazu das placeholder Attribut. Zu Zeiten des IE 6/7/8/9 habe ich mich eines anderen Mittels bedient:
Ich habe damals Standardtexte realisiert , die verschwinden, sobald in das Textfeld geklickt wird. Mit folgendem JavaScript (Voraussetzung ist die Einbindung von jQuery), hatte ich dies umgesetzt.

HTML-Code:

<div id="divbox"><input type="text" value="Suchen ..." /></div>

 

JavaScript-Code:

// Such-Eingabefeld Standardtext (bei Klick ausblenden)
stdSearchText = $("#divbox input[type=text]").val();
$("#divbox input[type=text]").click(function(){
	if($(this).val() == stdSearchText) {
		$(this).val("");
	}
});
 
$("#divbox input[type=text]").focusout(function(){
	if($(this).val() == "") {
		$(this).val(stdSearchText);
	}
});

 

Zur Erklärung:
Der oben gezeigte Code-Schnipsel muss auf die Beschaffenheit Ihres Codes angepasst werden und in den Bereich $(document).ready(function(){ ... }); Ihres JavaScript-Codes eingefügt werden. Dieses Beispiel funktioniert nur für ein bestimmtes Textfeld, ließe sich aber einfach generalisieren, sodass er für beliebig viele Textfelder funktioniert.

Veröffentlicht am

WordPress Plugin WP GDPR bis Version 1.4.2 unsicher

Als ich am Samstag mal wieder die Zeit hatte, die Heise News zu lesen, stand an erster Stelle gleich der Artikel, Schwerwiegende Schwachstelle in DSGVO-Plugin für WordPress.
Ich selbst habe das Plugin bei Kunden nicht eingesetzt, weiß aber, dass es einige Betroffene gibt, die schleunigst ein Update des Plugins machen sollten. Denn beim Programmieren des Plugins hat sich offensichtlich ein gravierender Fehler eingeschlichen, der es leicht macht, volle Kontrolle über die Website zu bekommen, indem man sich selbst einen Benutzer anlegen kann, den man wiederum zu Administrator der Website erklären kann. Details hat Mikey Veenstra von Wordfence in einem Blog-Beitrag aufgeschrieben.
Diese weit offen stehende Hintertür kann durch die Aktualisierung des Plugins geschlossen werden – der Entwickler hat immerhin dafür gesorgt, dass das Problem in der neuen Version des Plugins nicht weiter besteht.

Ich bin der Meinung, dass so wenig Plugins wie möglich im Einsatz sein sollten – grundsätzlich – unabhängig vom eingesetzten Basis-System.

Wenn mit Bord-Mitteln möglich, sollte man Anforderungen ohne Plugins lösen.  Denn egal ob WordPress, TYPO3, OXID eShop oder Shopware (…), jede Erweiterung beinhaltet grundsätzlich Code der potentiell unsicher sein kann. Das bedeutet wiederum ausdrücklich nicht, dass viele Plugins auf jeden Fall eine Unsicherheit bedeuten – das Risiko erhöht sich aber.

Sie können sich das ein bisschen so vorstellen, als ob man viele Medikamente nehmen muss – je mehr verschiedene Medikamente man nimmt, desto größer ist die Gefahr von unerwünschten Wechselwirkungen und Nebenwirkungen.

Update 14.11.2018:

Heute habe ich die erste Website gerettet, die von dem Fehlerhaften und noch nicht aktualisierten Plugin WP GDPR 1.4.2 betroffen war. So konnte ich eimal sehen, wie die Lücke unter anderem ausgenutzt wird. In dem Fall waren die Auswirkungen relativ harmlos. Es wurden zwei Administrator-Accounts in der WordPress-Installation angelegt. So konnte der Hacker einen Ordner in den Theme-Ordner einschleusen in dem er wiederum Schadcode versteckt hatte. Der führte dazu, dass wenn man die Website aufrief auf irgendeine scheinbar willkürliche Webiste weitergeleitet wurde. Es war in diesem Fall glücklicherweise keine Porno-Website oder ähnliches.

Ich bin gespannt, ob in den nächsten Tagen die nächsten Website-Betreiber Alarm schreien.

Veröffentlicht am

Sichere Passwörter

Ich sage meinen Kunden oft, “Wenn Sie sich das Passwort merken können, ist es kein gutes Passwort”. Das gilt im Prinzip für alle Passwörter, außer für das “Hauptpasswort”.

Um die Frage, was ein sicheres Passwort ist, zu beantworten, gibt es viele verschiedene Gesichtspunkte zu betrachten. Bei Interesse lesen Sie über Brute Force Passwort (Wikipedia-Eintrag) oder Wörterbuchangriff (Wikipedia-Eintrag) nach, das sollte Ihnen einen guten Einstieg in die Tiefen des Themas geben.

Machen wir es doch einfach kurz:

  • verwenden Sie immer unterschiedlich Passwörter für die verschiedene Dienste (z.B. E-Mail, Twitter, PayPal usw.)
  • verwenden Sie mindestens 15 Zeichen
  • Buchstaben – große und kleine
    • wenn’s geht dann bitte auch Sondernzeichen und Zahlen
  • verwenden Sie einen Passwort-Manager, wie Last Pass, 1Password
    • für das jeweilige Hauptpasswort reihen Sie einige Worte, die Sie sich merken können aneinander – z.B. Tischfarbe, Ihr Lieblingsobst, Ihr Geburtsjahr mal 3, den Namen Ihrer Deutschlehrerin und irgendwas lateinisches
    • Trennen Sie die Worte nicht mit einem Leerzeichen sondern mit einem Sondernzeichen, dass Ihnen gut gefällt. Wie wär’s mit einem Sternchen (*)?
Veröffentlicht am

Telefonnummer validieren

Hier ein if-Konstrukt, deren Inhalt dann ausgeführt werden würde, wenn keine gültige Telefonnummer übergeben wurde:

1
2
3
4
5
6
7
8
9

if(
   0==preg_match(
      "^((\+?[0-9]{2,3})|(\(?[0-9 ]+\)?|[0-9 \-])[0-9 \-]*)^",
      $zeichenkette)
   || empty($zeichenkette)
) {
        echo "In der Zeichenkette ".$zeichenkette.
             "ist keine gültige Telefonnummer enthalten.";
}
Veröffentlicht am

WordPress 3.2 erscheint in Kürze – keine Untersützung für den Internet Explorer 6

“Sind Sie bereit für WordPress 3.2?”

Bald ist es soweit – die neue Version 3.2 der populären Blog-Software WordPress erscheint in Kürze! Was mich daran besonders freut, ist der Auslaufende Support für den alten Internet Explorer 6. Jeder Browser hat seine Zeit, die des schon 10 Jahre alten IE6 sind in meinen Augen (und ich bin sicher nicht der Einzige) gezählt. Für meine Begriffe ein Schritt in die richtige Richtung seitens WordPress.
Laut der Website www.ie6countdown.com nutzten im Juni 2011 10,7% der Internetnutzer noch den IE6 – eine erfreuliche Zahl, die scheinbar auch immer kleiner wird – gut so, denn dieser “out-of-date web browser” erschwert nicht nur Webentwicklern die tägliche Arbeit enorm, sondern mindert auch das Erlebnis “im Internet surfen” für alle, die gezwungen sind diesen Browser zu nutzen.
Dass WordPress, mit über 24 Millionen Nutzern, diesen Schritt geht, ist ein Fingerzeig in die richtige Richtung. So wird hier und da sicherlich der richtige Druck ausgeübt, um auf einen modernen Webbrowser umzusteigen.

Neben dem ändern sich auch die Serveranforderungen für des neue WordPress. PHP in der Version 5.2.4 und MySQL 5.0 sind nur die Hauptvoraussetzung, um WordPress nutzen zu können.

Passender Newsartikel bei wordpress.org:
Are You Ready for WordPress 3.2?

Veröffentlicht am

Datum um ein Jahr erhöhen – Vorsicht Schaltjahr

Im Internet findet man diverse Lösungen, um ein Datum programmiermäßig zu erhöhen. Leider wird dabei oft nicht auf die wenigen Sonderfälle eingegangen, die trotz ihrer Seltenheit natürlich trotzdem auftreten können.

Im folgenden eine Funktion, die ein Datum im Format 0000-00-00 00:00:00 um ein Jahr erhöht. Hierbei ist es wichtig zu beachten, dass an einem 29. Februar (Schaltjahr) die Jahreszahl des Datum nicht einfach um 1 erhöht werden kann, da das Folgejahr naturgemäß keinen 29. Februar hat.
Es wird davon ausgegangen dass die Funktion einen validen Datums-String im genannten Format übergeben bekommt. Sollte das Datum dem Standardwert entsprechen, wird false zurückgegeben.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

function get_one_year_later($time_string="0000-00-00 00:00:00") {
	if($time_string != "0000-00-00 00:00:00") {
		if(date("m", strtotime($time_string)) ==
		  "2" && date("d", strtotime($time_string)) == "29") {
			return date("Y-m-d H:i:s",
			  strtotime((date("Y", strtotime($time_string))+1).
			   date("-m-28 H:i:s", strtotime($time_string)))
			);
		} else {
			return date("Y-m-d H:i:s",
			  strtotime((date("Y", strtotime($time_string))+1).
                            date("-m-d H:i:s", strtotime($time_string)))
			);
		}
	}
	return false;
}
Veröffentlicht am

E-Mail-Adressen validieren

Das Validieren von E-Mail-Adressen ist des Webprogrammierers täglich Brot. In der Fachliteratur und im Internet finden sich diverse Beispiele, wie man sicherstellen kann, dass eine Benutzer-Eingabe einer formal gültigen E-Mail-Adresse entspricht. Allerdings sind die Lösungen teils lückenhaft oder es wird nicht ausreichend auf die geltenden Standards geachtet.

Hier ein if-Konstrukt, deren Inhalt dann ausgeführt werden würde, wenn keine gültige E-Mail-Adresse übergeben wurde:

1
2
3

if( 0==preg_match("/^[a-zA-Z0-9._%+-ÄÖÜäöü]+(@){1}([a-zA-Z0-9.-ÄÖÜäöü]+)\.[a-zA-Z]{2,}$/i", $zeichenkette) || empty($zeichenkette) ) {
	echo "In der Variable " . $zeichenkette . "ist keine gültige E-Mail-Adresse enthalten.";
}
Veröffentlicht am

print_rr

Hier ein kleiner Codeschnipsel. Ich benutze ihn bei kleineren Webanwendungs-Projekten für Debug-Ausgaben, die man während der Entwicklungszeit öfter mal gebrauchen kann.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/**
* Gibt mithilfe von print_r HTML-formattierte Daten aus
* @param mixed $dataToDisplay zu verarbeitende Daten
* @param boolean $outputVar Daten ausgeben (true) oder zurückgeben (false)
* @return string HTML-fomatierter String der die
		 übergebenen Daten enthält, falls $outputVar true ist
*/
function print_rr($dataToDisplay, $outputVar=false) {
	if($outputVar) {
		return print_r("<div class=\"debug\" style=\"white-space: -pre-wrap;\">"
			.$dataToDisplay."</div>", true);
	} else {
		echo "<div class=\"debug\" style=\"white-space: -pre-wrap;\">";
		print_r($dataToDisplay);
		echo "</div>";
	}
}