Abou Chleih

{the magic lies between the brackets}

Menü Schließen

Kategorie: Server (Seite 1 von 2)

ASP.NET Core App via Apache bereitstellen #2 – Konfiguration Apache

Um eine weitere Apache Instanz zu erstellen, gibt es bereits ein Skript, welches einem einige Arbeit abnimmt.
Die grundsätzliche Idee dahinter ist jedoch einfach: Man kopiert die originale Instanz (apache2) , also Konfigurationsdateien, Binaries, etc. in einen zweiten Ordner (apache2-xxx).

Je nach System findet sich das Skript in
/usr/share/doc/apache2.2-common/examples/setup-instance xxx
oder
/usr/share/doc/apache2/examples/setup-instance xxx

xxx ist hierbei der Name der Instanz, die erstellt werden soll: /usr/share/doc/apache2/examples/setup-instance netcore

Dies erstellt also die entsprechenden Verzeichnis und Dateien /etc/apache2-netcore, /etc/logrotate.d/apache2-netcore, /var/log/apache2-netcore sowie das Init-Skript für den Boot /etc/init.d/apache2-netcore.

Um die entsprechenden Links zu aktivieren, also apache2-netcore als Service verfügbar zu machen. Führen wir nun ein update-rc.d apache2-netcore defaults aus.
Dies verlinkt die executables in /etc/rcX.d/, also dem entsprechenden Runlevel für den Boot Prozess.

Nun können wir den Service mit init.d oder service starten: /etc/init.d/apache2-netcore start oder service apache2-netcore start

Nun können wir uns an die Konfiguration de Apache2 Instanz NetCore machen. Dazu navigieren wir ins Verzeichnis /etc/apache2-netcore/sites-available/ und bearbeiten das file 000-default.conf (HTTP) oder default-ssl.conf (HTTPS).

Diese Dateien haben folgenden Aufbau (in diesem Beispiel hört die ASP.NET Core Application auf localhost:5000):

<VirtualHost *:8080>
     ServerName sub.mydomain.com 
     ErrorLog ${APACHE_LOG_DIR}/errorNetCore.log 
     CustomLog ${APACHE_LOG_DIR}/accessNetCore.log combined 
     ProxyPass / http://localhost:5000/ 
     ProxyPassReverse / http://localhost:5000/ 
     ProxyPreserveHost On
</VirtualHost>

ServerName: Hört auf Aufruf von sub.mydomain.com
ErrorLog: Schreibt Error Log in entsprechendes File, (Apache bspw. PHP Fehler kommen hier rein)
CustomLog: Schreibt alle Aufrufe in File (=AccessLog Config)
ProxyPass: Forward Proxy Config, leitet alle Anfragen von http://sub.mydomain.com:8080/ an http://localhost:5000/ weiter
/ steht hier für das Top Directory, ProxyPass /sub/ http://localhost:5000/ würde bspw. http://sub.mydomain.com:8080/sub/ an http://localhost:5000/ weiterleiten
ProxyPassReverse: Reverse Proxy, leitet Response um. Schreibt alle Urls in der Rückantwort um, bspw. sollte http://localhost:5000 zu http://sub.mydomain.com:8080 umgeschrieben werden.
ProxyPreserveHost: Header bleibt erhalten

Nun speichern wir die Seite und aktivieren sie mit a2ensite sub.mydomain.com und starten die Instanz neu service apache2-netcore restart.

Anschließend starten wir die ASP.NET Core Applikation: dotnet PFADZURDLL

ASP.NET Core App via Apache bereitstellen #1 – Compiling & Vorbereitung

Mit .NET Core ist es seit einiger Zeit problemlos möglich cross-plattform Applikationen zu erstellen.
Darunter fallen auch ASP.NET Core Web-Anwendungen.
Um diese Anwendungen allerdings allgemein bereitzustellen, müssen wir diese zuerst für den allgemeinen Zugriff aus dem Internet freigeben.
Dies geschieht auf Grund der Plattformunabhängigkeit natürlich ohne Microsoft IIS. In diesem Beispiel wird ein Apache2 Webserver in der Standardkonfiguration genutzt.
Voraussetzung sind daher ein installierter Server mit funktionaler Apache2 Installation und natürlich eine ASP.NET Core Anwendung.

Was werden wir hier nun genau machen?

  • Compilen der ASP.NET Core Anwendung
  • Konfigurieren einer eigenen Apache Instanz, die als Reverse Proxy fungiert
  • Bereitstellen der Applikation

Um die ASP.NET Anwendung bereitzustellen, müssen wir diese zuerst compilen, dies mache ich bevorzugt auf meiner Entwicklungsmaschine (hier: Windows).
Wir gehen als in das Projektverzeichnis ({Solutionpath}\src\{Projectpath}) und öffnen dort eine Kommandozeile oder PowerShell.

Mit dem Befehl dotnet publish -c Release (-c = –configuration) starten wir nun den Build Prozess (im Release Modus).
Sollten nun Fehler kommen, dass „bower“ nicht gefunden werden kann, so kann dies an zwei Dingen liegen.

  • Bower nicht installiert
  • Path-Variable nicht korrekt

Um Bower zu installieren, geben wir in der PowerShell einfach npm install bower ein, das entsprechende Node.js Projekt wird dann geladen und installiert.
Anschließend installieren wir noch Gulp via npm install gulp, eine weitere Abhängigkeit.

Sollte der Fehler immer noch erscheinen, so müssen wir die Path-Variable auf das Web Verzeichnis unserer Visual Studio Installation verweisen lassen:
PowerShell: $env:path = $env:path + ";C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External"
Die VS Version entsprechend anpassen (hier: VS 2015).

Nun sollte das Projekt compilen und die lauffähige Version unter {Solutionpath}\src\{Projectpath}\bin\Release zu finden sein.

Diesen Ordner jetzt auf den Linux Server laden.

Um die Applikation jetzt ausführen zu können, benötigen wir die .NET Core Runtime auf dem Server (hier: Debian).
Um diese zu installieren, laden wir uns das Archiv (tar.gz) herunter und entpacken es:
Die Befehle dazu finden sich auf der entsprechenden Microsoft-Website:

Für v1.0.3:
sudo apt-get install curl libunwind8 gettext
curl -sSL -o dotnet.tar.gz https://go.microsoft.com/fwlink/?linkid=847105
sudo mkdir -p /opt/dotnet && sudo tar zxf dotnet.tar.gz -C /opt/dotnet
sudo ln -s /opt/dotnet/dotnet /usr/local/bin

Für v2.0.0:
deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-trusty-prod trusty main" > /etc/apt/sources.list.d/dotnetdev.list
apt-get update
apt-get install dotnet-sdk-2.0.0

Anschließend sollte man das Projekt starten können, zum Testen reicht hier: dotnet {Projektname}.dll im Pfad {App}\publish\.

Check_MK Überwachungs-Skript für EMC VNXe Maschinen (Unisphere CLI)

Zur Überwachung von VNXe Storage Systemen (NAS) innerhalb von Check_MK gab es keine ordentlichen Funktionen.
Im Netz findet man auch nicht viel zu diesem Thema.
Allerdings bieten die VNXe Systeme eine Remote Möglichkeit zur Konfiguration via Shell, die sog. Unisphere CLI; kurz: UEMCLI.
Diese wird für die verschiedensten Systeme angeboten, allerdings für Linux Systeme nur in Form ein .rpm Datei (Red Hat Package).
Auf Debian Systemen steht man jetzt etwas blöd da, also konvertierte ich das Paket mit alien in das .deb Format.

faviconunispherecli-linux-64-x86-en-us_3.0.0.1.16-2_amd64.deb

Nach der Installation finden sich die Binaries der uemcli im Pfad /opt/emc/uemcli/bin.

vnxe_check

Das Skript, welches wir in Check_MK aufrufen werden, müssen wir nun in einen für den Check_MK user verfügbaren Pfad packen (hier: /opt/omd/sites/monitor/local/share/check_mk) und via chmod -x ausführbar machen. Die Rechte müssen evtl. auch angepasst werden.
Im Anschluss können wir einen Legacy oder Classical Check in Check_MK anlegen, welcher das Programm ausführt.
Davor allerdings noch die Security Level der UEMCLI via /opt/emc/uemcli/bin/setlevel.sh -l auf low setzen, damit die Zertifikate nicht mehr manuell akzeptiert werden müssen.

Nun können wir das Programm mit folgendem Befehl ausführen: /opt/omd/sites/monitor/local/share/check_mk/vnxe_check <HOST> <USER> <PW> <PATH> <COL> <OPTIONAL REGEX>
Es gibt die entsprechenden Codes zurück. Die Fehlercodes von Degraded/Minor failure/Major failure werden als CRITICAL angezeigt (Returnvalue 1), bei einem Programmfehler oder leerer Response (timeout) wird UNKNOWN zurückgegeben (Returnvalue 2), bei einem Fehlercode OK_BUT wird WARNING angezeigt (Returnvalue 2)

First parameter: IP/Domainname
Second parameter: username and domain in the following structure: <DOMAIN>/<USER>
Third parameter: password
Fourth parameter: directory or file which is queried (see manual inside the bash file)
Fifth parameter: column index of health status (see manual inside the bash file)
Sixth parameter is optional: grep filter which looks for the beginning of a line and returns the whole line  | grep \“.*$6.*\“

Der letzte Parameter wird von mir verwendet, um einzelne Geräte innerhalb eines Arrays anzusprechen, bspw. eine einzelne Platte im Disk Array

Migration von bestehender Check_MK Installation auf OMD

Da die Repositories von Debian nicht die aktuelle Version von Check_MK beinhalten, aber nur diese die Funktion besitzt SNMP Traps zu empfangen und auswerten, musste ich einen Server von einer manuellen Installation auf die OMD Installation umstellen und bestehende Daten migrieren.
Die Migration ist eigentlich sehr einfach.
Man nimmt die Daten aus dem Verzeichnis /etc/check_mk/ des alten Servers und kopiert diese auf den neuen in den Ordner /opt/omd/sites/{SITE}/etc/check_mk.
Danach überprüft man die Rechte und weist als Eigentümer (rekursiv) den Sitenamen {SITE} zu.
Danach sollten die Daten für das System beschreibbar sein.

Nun kann man sich einloggen, wird aber kurz darauf feststellen, dass die Rechte nicht stimmen. So ist der omdadmin bzw. sind die bestehenden User zwar existent, aber nicht in den richtigen Gruppen.
Also gehen wir in das Verzeichnis /opt/omd/sites/monitor/etc/check_mk, öffnet die Datei multisite.mk und fügt in der Zeile admin_users = [ ... ] den Punkt ,"omdadmin" zu.
Nun kann man die bestehenden User anpassen und die Rechte zuweisen.

Fertig! Die groben Einstellungen sind nun importiert. Dienste oder Spezialabfragen über Plugins müssen allerdings, falls versch. Nagios Versionen, neu geschrieben/installiert werden.

Pluginsverzeichnis für Check_MK ist /usr/lib/nagios/plugins. Die eigenen Plugins in diesem Verzeichnis müssen nun in das Verzeichnis von OMD kopiert werden /opt/omd/versions/1.20/lib/nagios/plugins.

Nun muss man noch die Rulesets in Check_MK entsprechend den neuen Verzeichnissen anpassen bspw.:

bash /usr/lib/nagios/plugins/my_Check_bla -H $HOSTADDRESS$ -C public -v 2c -t raid -w 90 -c 95

bash /opt/omd/versions/1.20/lib/nagios/plugins/my_Check_bla -H $HOSTADDRESS$ -C public -v 2c -t raid -w 90 -c 95

Nun sollte der Server wie gewohnt funktionieren.

Falls nicht, liegt es daran, dass der Server die alten, gecacheden Daten als valide ansieht und die neuen, da evtl. neuer Syntax, als invalide.
Beheben lässt es sich, indem man die Hosts neu prüfen lässt:

omd$mysite: check_mk -u
omd$mysite: check_mk -I {host}
omd$mysite: check_mk -v {host}

{host} ist optional, sollte das Argument nicht genannt werden, so wird der Task auf alle Hosts ausgeführt.

Natürlich müssen noch eventuell Freigaben bezüglich der Domänennamen oder IPs berücksichtigt werden. Bspw. SNMP Freigabe nur auf IP x.

Erste Schritte: Installation und Erstkonfiguration von Nagios3/Check_MK auf Debian 7.0

Um meine Windows Server 2008 R2 Server, sowie meine Virtualisierungsinfrastruktur (auf VMWare ESXI) zu monitoren, suchte ich nach einer einfachen, aber auch umfangreichen Lösung.
So stieß ich auf das sehr verbreitete Nagios Softwarepaket, welches allerdings erst mit vielen Plugins ausgestattet werden muss, um vernünftig zu funktionieren.
Daraufhin habe ich meine Suche fortgeführt und bin auf die Open Monitoring Distribution (kurz: OMD oder OMDistro) gestoßen, welche die wichtigsten Plugins und Softwarepakete in einem Paket zusammenfasst, die da wären:

  • Check_MK (umfangreiche Erweiterung auf Nagios)
  • Nagios3
  • NagVis (Visualisierungsplugin)
  • Thruk (WebInterface)
  • Icinga (WebInterface)

Ich habe mich jetzt hier aber für Check_MK und Nagios3 (logischerweise) entschieden.
Die Installation auf einem Grundsystem (hier: Debian 7.0) ist sehr einfach.

Eine statische IP Adresse muss in der network configuration gesetzt sein!

Zu aller erst lädt man sich die Distribution als .deb-Paket auf der offiziellen Website herunter und verbindet sich per SSH auf den Server.
Ich nutze im folgenden für den Datenverkehr auf den Server winSCP, welches auf SSH basiert.
Via winSCP kann man die Datei in das Verzeichnis „/usr/local/“ kopieren – natürlich sind auch andere Pfade möglich – und führt den Befehl zur Installation via gdebi aus:
gdebi /usr/local/omd-0.43_0.43lucid1_amd64.deb
Anschließend folgt man den Anweisungen, setzt die Kennwörter und konfiguriert das System.
Nach der Installation muss man noch überprüfen, ob das Modul „HTTP Redirects/Proxy“ aktiviert ist.
a2enmod proxy_http
Danach aber noch schauen, ob die Einstellungen in /etc/apache2/mods-enabled/proxy.conf richtig und sicher sind (Zugriff von außen blockieren).
Nun können wir die OMD starten, indem wir zuerst den Pfad noch festlegen, hier http://<IP>/Monitoring/:
omd create Monitoring
omd start

Nun navigiert man zu folgender Seite http://<IP>/Monitoring und sieht alle o.g. Funktionen.
Man navigiert nun zu Check_MK und geben die Admin Daten (Standarduser: omdadmin, PW: omd) ein.
Hier kann nun über die Schaltfläche Hosts, neue Hosts anlegen:

wato_hostscheckmk_newhost

 

Anschließend gibt man die Daten des Servers ein und wählt den Agent Type SNMP, wenn man SNMP nutzen möchte. Anschließend definiert man noch die Community und klickt dann auf „Safe & Go To Services“.
Hier bekommt man dann eine Fehlermeldung, dass keine Rückmeldung via SNMP stattfand

snmp_error

 

Man muss nun also noch SNMP auf dem Windows Server aktivieren.
Dazu verbindet man sich via RDP auf den Server, öffnet den Server Manager und navigiert zu Features und Feature hinzufügen.
Anschließend wählt man den SNMP-Dienst aus und lässt diesen installieren.
Nach der Installation öffnen wir die services.msc und navigieren zum Dienst „SNMP-Dienst“. Hier klicken öffnet man nun die Eigenschaften und definiert den Agent, sowie die die Community und akzeptierte Hosts:
snmp_1 snmp_2
Community ist hier: Check_MK (Rechte: NUR LESEN), die IP-Adresse des Nagios3-Servers ist 192.168.178.128, Kontakt und Standort kann man frei wählen.
Anschließend quittieren wir alles mit Übernehmen und OK.

In Check_MK können wir nun nochmals den Service-Scan ausführen und bekommen einige Infos über SNMP zugeschickt
checkmk_services

Jetzt speicher man alles und lässt die Änderungen aktiv werden:

activate_changes

Fertig! Der Server wird nun monitored und über das Dashboard lassen sich nun die Hosts überwachen.

Installieren und Konfigurieren von OpenWRT auf dem TP-Link WR710N

Der TP-Link WR710N war für kleine WLAN-Netze gut zu gebrauchen, ansonsten aber sehr langsam und instabil.
Da ich gute Erfahrungen mit meinem WR841N auf OpenWRT gemacht hatte, habe ich mich kurzerhand entschlossen auch den WR710N auf OpenWRT „umzurüsten“.
Dies ging leider nicht so einfach via Plug&Play.
Nun aber von Anfang an:

Achtung: Die Hardwareversion des TP-Link WR710N ist sehr wichtig, hier ist nur von der Version (EU) v1.1 die Rede!
Funktionalität von anderen HW-Versionen kann man hier erfahren.

Über das Repository kann man den aktuellsten Softwarestand herunterladen, in unserem Fall ist das  die openwrt-ar71xx-generic-tl-wr710n-v1-squashfs-factory.bin.

Über die Upgradefunktion der Weboberfläche unseres Routers wird die Binary-Datei, als das Update, nun aufgespielt.
Dies kann nun etwas dauern. Im Nachhinein ist der Router nur über TELNET (vorher als Putty herunterladen) über die IP 192.168.1.1 verfügbar.
Grundsätzlich ist kein root-Kennwort gesetzt und man gelangt direkt ins Terminal. Hier gleich ein sicheres (!) Passwort für den Root vergeben:
passwd

Nun muss man erstmal (sollte man ein eigenes Netz schon in Betrieb haben) die IP-Konfiguration vornehmen.
Dazu im Terminal die Datei /etc/config/network mit dem Editor vi bearbeiten.
vi /etc/config/network

Hier nun das Interface „lan“ wie gewünscht einstellen, also:
(Per ‚a‘ kommt man in das Bearbeitungsmenü, per ESC wieder ins Kommandomenü, zum Löschen einer Zeile ‚d‘ im Kom-Menü drücken)

option ipaddr 'x.x.x.x'
option gateway 'x.x.x.x'
option dns 'x.x.x.x'

Nun speichern wir per ESC + wq + Enter.

Anschließend startet man den Router per „Strom-Weg“ neu. (Der Init-Befehl  läuft bei mir leider immer in eine Boot-Schleife).
Nun kann man den Router per definierter IP-Adresse erreichen.
Will man jetzt die Weboberfläche Luci installieren, muss man opkg update ausführen.
Bei mir waren die Links in der opkg.conf veraltet, wodurch das Update bei allen Repos mit einem 404-Error abbrach.
Also muss man die /etc/opkg.conf wieder mit vi bearbeiten:
vi /etc/opkg.conf
und die Links mit diesen hier ersetzen, bsp:

src/gz barrier_breaker_base http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base

Wichtig ist der aktuelle Link: http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages

Danach nochmals opkg update ausführen.

Jetzt sollten alle Repos aktualisiert sein und man kann mit der Installation von Softwarepaketen beginnen.
So installiert man nun die Weboberfläche mit:
opkg install luci
Alle Dependencies werden hierbei direkt mitinstalliert.
Also noch den http-Server via /etc/init.d/uhttpd start starten und anschließend kann man das Webinterface besuchen, indem man die IP-Adresse per Webbrowser aufruft.
Optional, damit der HTTP-Server immer beim Booten startet:
/etc/init.d/uhttpd enable

Das war’s! Nun hat man einen vollständigen und stabilen Router mit VLAN-Fähigkeit, Firewall, VPN etc.

Internet Explorer 8 und 11 Group Policies (GPOs, Gruppenrichtlinien) definieren

Um Benutzern in einem Unternehmen vordefinierte Regeln und Rechte einzuräumen gibt es im Active Directory die sog. Group Policy Objects (GPOs) oder zu deutsch Gruppenrichtlinien.
In diesen kann man Usereinstellungen, wie Redirects von lokalen Dateien auf ein Fileshare und Ähnliches veranlassen.
Weiterhin kann man Richtlinien für den Internet Explorer definieren. Darüber geht es hier nun heute.

Im weiteren Verlauf werden die englischen Bezeichnungen der Programme verwendet

Grundsätzlich kann man Gruppenrichtlinien über das „Group Policy Management“.
Nach dem Öffnen klickt man auf den Forest und dann auf die entsprechende Domain, für welche die GPO gelten soll.
Im Ordner „Group Policy Objects“ sind alle GPOs gespeichert. Mit einem Rechtsklick auf diesen Ordner, kann man über die Schaltfläche „New…“ eine neue GPO erstellen.
Neue GPO erstellen

Sobald wir eine GPO erstellt haben, wird diese gelistet und kann mit einem Rechtsklick -> „Edit…“ bearbeitet werden.
Nun gibt es grundsätzlich zwei Wege, wie man Berechtigungen und Einstellungen setzen kann. Einmal computerbezogen und einmal userbezogen.
Ich bevorzuge letztere Variante.

Grundsätzliche Einstellungen für den IE8 (teils veraltet):
Für den Internet Explorer 8 kann man die Einstellungen über Policies -> Administrative Templates -> Windows Compontens -> Internet Explorer definieren.
Die wichtigsten Einstellungen im Unternehmensumfeld sind wohl Restriktionen in Sachen Windows Update und Feedback, sowie Einstellungen in Sachen Proxy und Kompatibilität.
Im Punkt „Browser Menus“ kann man die Feedback Option von Microsoft deaktivieren.
Im Punkt „Internet Control Panel“ kann man die verschiedenen Reiter im Punkt „Internet Optionen“ ein- bzw. ausblenden lassen.

  • Im Unterpunkt „Advanced Page“ kann man die Windows Updates unterbinden, dazu den Punkt „Automatically check for Internet Explorer updates“ auf Disabled setzen
  • Im Unterpunkt „Security Page“ kann man nun Einstellungen für die verschiedenen Zonen im IE definieren:
    • Generell kann man aber beim Punkt „Site to Zone Assignment List“ Seite zu den verschiedenen Zonen hinzufügen.
      Es gilt: (1) Intranet , (2) Trust Site, (3) Internet, (4) Restricted Site
      Damit die Option greift, muss man den Punkt auf Enabled setzen
    • Damit die gesetzten Optionen in den entsprechenden Unterpunkten bspw. Internet Zone greifen, muss man die Punkte „XY“ Zone Template auf Enabled setzen

Erweiterte Einstellungen für den IE11 (neuer Weg):
Generell werden bei einem Update alle Einstellungen des Users auf den neuen Internet Explorer migriert.
Sollte jedoch ein Profil neu erstellt werden, so ziehen nicht mehr alle Einstellungen (im o.g. Punkt IE8). Microsoft hat hier einen neuen Punkt erstellt, welche die Einstellungen vereinfachen sollen.
Dazu einfach auf Preferences -> Control Panel Settings -> Internet Settings gehen und per Rechtsklick einen neuen Eintrag für die jeweiligen IE Version erstellen.
Der Rest sollte sich von selbst erklären 😉

gpo_pref

[PHP] Nutzung eines CAPTCHA Bildes

Wir erstellten ein CAPTCHA Bild im vorigen Beitrag.
Nun wollen wir dieses natürlich auch nutzen.
Zuerst benötigen wir die PHP-Datei (im folgenden Beitrag generatecaptcha.php).

Diese binden wir nun ein.
Wir erstellen eine simple HTML-Datei (hier jetzt: index.html).
Da die php-Datei eine Bilddatei ausgibt, können wir das Bild einfach per HTML einbinden.
Dazu benutzen wir den HTML Image-tag:

<img id="captcha" title="Captcha-Code" alt="" src="generatecaptcha.php" /> 

Dem Image weisen wir nun noch eine ID zu. Wieso? Dazu kommen wir noch.
Ein Feld, in welches wir das CAPTCHA eintragen können und einen Button, welcher die Daten absendet, benötigen wir nun noch:


CAPTCHA Abfrage

 <img id="captcha" title="Captcha-Code" alt="" src="generatecaptcha.php" />

<form action="checkcaptcha.php" method="POST"><input type="text" name="captcha_solve" />
 <input type="submit" /></form>

Nun gehen wir noch einmal in die generatecaptcha.php:

Denn wie soll der Server wissen, welches CAPTCHA wir generiert haben bzw. welcher Text der richtige ist?
Wir benötigen sogenannten Session-Variablen.
Diese sehen wie folgt aus:

 $_SESSION['mySessionVar'] 

Es ist zu beachten, dass diese Session-Variablen immer global zugänglich sind. Sie müssen also nicht per Schlüsselwort global definiert werden.
Bevor man solche Variablen jedoch nutzt, muss man eine Session auf dem Server starten, dazu folgende Funktion aufrufen:

session_start();
unset($_SESSION['captcha_spam']);

Hier resette ich gleich die Session-Variable captcha_spam, um sicher zu gehen, dass diese nicht mehr gefüllt ist (unnötig, aber sicher ist sicher.)

Nun erstelle ich das Bild in der generatecaptcha.php und schreibe den Text in die Sessionvar:

 $_SESSION['captcha_spam'] = $text; 

Die generatecaptcha.php ist nun fertig, zurück zur index.html.
Hier verweisen wir im form-Tag auf die checkcaptcha.php.
Diese erstellen wir nun:
Da wir in der HTML-Datei die Daten per POST übergeben und der Name des Feldes captcha_solve lautet, holen wir die wie folgt aus dem HTTP-Paket:

 $_POST['captcha_solve'] 

Die Sessionvar holen wir, wie oben beschrieben, per

 $_SESSION['captcha_spam'] 

Sollten der Text in der $_POST-Var und der in der $_SESSION-Var identisch sein, so hat der User den richtigen CAPTCHA-Text eingegeben:

session_start();
if($_SESSION['captcha_spam'] == $_POST['captcha_solve']){
	echo 'RIGHT';
        //TODO HERE
}else{
	echo 'WRONG';
       //FALSCHER CAPTCHA EINGEBEN
}

Jetzt nochmal zu der vorhin genannten ID des Image-Tags.
Will man jetzt noch, dass das CAPTCHA erneuerbar ist, falls es nicht lesbar sein sollte, so sollte dieser Code genügen. Er erneuert das Bild und gibt es aus (ein simpler refresh):

 <img style="cursor: pointer;" onclick="document.getElementById(&quot;captcha&quot;).src = &quot;generatecaptcha.php?r=&quot;+Math.random();" alt="" src="refresh.png" />

Das Math.Random() war nötig, da der Internet Explorer nur Links aufruft/aktualisert, welche sich ändern.

Den vollständigen Sourcecode findet ihr auf GitHub

[PHP] Erstellen eines CAPTCHA Bildes

Um Spam zu vermeiden, gibt es viele Möglichkeiten.
Eine der bekanntesten ist das Captcha Bild, in welchem ein Text zu finden ist. Diesen muss man dann einfach in ein Textfeld eintragen.
Aber wie erstellt man ein einfaches Captcha Bild? PHP bietet dafür einige Funktionen, die sogenannten Image-Funktionen.

Als erstes braucht man für ein Bild natürlich eine Größe, bestehend aus der vertikalen Höhe und horizontalen Breite des Bilds:

$width = 150;
$height = 60; 

Da ein Captcha eher in die Breite als in die Höhe geht, wird das Bild natürlich breiter als hoch.

Nun müssen wir erstmal ein (leeres) Bild erstellen, bzw. den Speicher dafür bereitstellen.
Dazu bietet PHP die Funktion:

 $image = imagecreatetruecolor ($width, $height);
$colorbg = imagecolorallocate ( $image, 243, 243, 243 );

Diese nimmt die Höhe und Breite des Bildes als Parameter.
Danach setzen wir die Hintergrundfarbe des Bildes (hier ein Grauton).

Nun zeichnen wir einfach mal einen Text in das bestehende Bild:

$color = imagecolorallocate ( $image, 10, 36, 106 );
imagestring ($image, 5,30, 70, 'This is my text', $color);
//$image = Referenz auf das Bild
//5 (zweiter Parameter) = Der Font
//30 (dritter Parameter) = horizontaler Abstand
//70 (vierter Parameter) = vertikaler Abstand 

Das Ergebnis sieht in etwa so aus:
captcha_mytext_easy

Nun müssen wir es den Bots etwas schwerer machen:
Einen einfach String zu zeichnen und diesen auszugeben ist zwar einfach, aber jedes halbwegs gute AntiCaptcha Programm würde das sofort auslesen können, zumal ständig der gleiche dastehen würde.

Deshalb fügen wir dem Bild noch einige Verzerrungen hinzu.
Lasst uns zuerst mit dem Hintergrund anfangen. Diesen zeichne ich jetzt völlig random Pixel für Pixel.
Dazu durchlaufen wir das Bild einfach Pixel für Pixel (ein Bild ist ja nichts weiter als ein zweidimensionales Pixelarray).
Setzen einen Pixel in einer random ausgewählten Farbe und laufen zum nächstenPixel

 for($y = 1; $y <= $height; $y++) {
    for($x= 1; $x <= $width; $x++) {
        $r = mt_rand(0,255);
        $g = mt_rand(0,255);
        $b = mt_rand(0,255);
        $color = imagecolorallocate ($image, $r , $g , $b);
        imagesetpixel($image,$x - 1 , $y - 1, $color);
    }
}

Das Ergebnis könnte dann so aussehen:
captcha_randombg

Nun machen wir es nochmals schwerer:
Wir zeichnen einfach noch ein paar Striche durch’s Bild.

 for($ctr = 1; $ctr <= 4; $ctr++){
	imagesetthickness($Image, rand(0,10));
	imageline($image, rand(0,$width),rand(0,$height),rand(0,$width), rand(0,$height),imagecolorallocate ( $image, rand(0,255), rand(0,255), rand(0,255) ));
}

Hier werden 4 Striche gezeichnet, welche irgendwo durch das Bild verlaufen und eine Dicke von 0 – 10 haben.
Die Farbe ist auch wieder random.
Die Funktion dafür lautet:

imageline($image, $startposx, $startposy, $endposx, $endposy , $farbe);

Ergebnis:
captcha_bgstripes

Nun zum wohl wichtigsten Part des Bildes, dem Text:

 function generateRandomString($length) {
    $characters = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
    $randomString = "";
    for ($i = 0; $i < $length; $i++) {
        $randomString .= $characters[rand(0, strlen($characters) - 1)];
    }
    return $randomString;
}

Hier generieren wir einen String mit der Länge x (als Parameter).
Dazu erstellen wir solange einen String aus den oben gelisteten chars, bis wir die Länge erreicht haben.
Auch ist es wichtig zu wissen, dass wir einfach auf den einzelnen char im string zugreifen können, da ein string ein Array von chars ist (char[]).
Nun weisen wir diesen Text einer Variable (für die Übersichtlichkeit) und erstellen die Farbe des Strings auf dem Bild:

$text = generateRandomString(5); //Random String mit der Länge 5 erstellen
$color = ImageColorAllocate($image, rand(64,255),  rand(128,255) , rand(128,255)); //Farbe des Strings 

Nun nutzen wir, anders als vorhin, eine andere Funktion, um den Text auf das Bild zu schreiben:

 imagettftext($im, $ttfsize, $angle, $x, $y, $color, $ttf, $text); 

Diese bietet einige Vorteile gegenüber

imagestring ($image, $font, $x , $y , $color);

Zum einen kann man einen Winkel definieren, den Text als schräg stellen, zum anderen kann man einen eigenen Font einbinden.
Der Text wird also noch etwas verzerrter dargstellt, bspw.:
captcha_imagestringttf

Fügt man nun all die Funktionen zusammen, die wir in diesem Post behandelt haben, bekommt man ca. folgenden Code (+ einige Anpassungen).
Das Ergebnis sieht wie folgt aus:
captcha_fullcaptcha

Vollständiger Code

 

Wie man dieses CAPTCHA Bild nun nutzt, steht im nächsten Beitrag.

[WordPress] Integrieren des WordPress-Blog in die eigene Homepage #2 Suchfunktion

Integrierung des eigentlichen Blogs findet hier in Part1.

Nun haben wir den Blog mit all seinen Posts eingefügt. Es fehlen allerdings noch ein paar essentielle Features eines jeden Blogs.
Beispielsweise die Suchfunktion, um welche es in diesem Post gehen wird.

Um eine Suche starten zu können benötigen wir natürlich zuerst einmal ein Suchfeld.
In HTML werden Eingabefelder (Textboxen, …) mit <input …>-Tags erstellt.
In unserem Fall einem Textfeld sieht dies folgendermaßen aus:

 <input name="s" type="text" size="20" maxlength="20"> 

Der Bezeichner des Parameters ist hier „s“ (ist bei WordPress Pflicht!!), der Typ ist „text“ also Textfelder und die maximale Eingabelänge beträgt 20 Zeichen.
Nun benötigen wir noch einen Button, welcher eine Aktion (hier: die Suche) auslösen soll.
Dafür gibt es in HTML den Typ „submit“:

 <input type="submit"> 

Sobald man nun auf den Knopf drückt, passiert … nichts.
Wieso? … Man muss dem Browser noch sagen, was beim Drücken des Knopfes passieren soll, welche Aktion also ausgeführt werden soll.
In meinem Beispiel soll die search.php-Seite aufgerufen werden.

 <form action="search.php"> input tags here </form>

Nun wird beim Drücken des Buttons die search.php aufgerufen und der Parameter (hier: s), als Post-Parameter (also in der Browserleiste) übergeben.
Das Ergebnis sieht so aus:

http://www.meineDomainHier.de/search.php?s=MeinSuchtext

Nun zum eigentlichen Part, der Such-Page search.php.
Der Aufbau ähnelt sehr stark dem eigentlich Blog. Auch hier wird die Loop verwendet.

  <?php if (have_posts()) : ?>
         <p class="info">Deine Suchergebnisse f&uuml;r '<strong><?php echo $s ?></strong>'</p> <-- Deine Suchergebnisse fuer XYZ --!>
		 <br/>
         <?php while (have_posts()) : the_post(); //The Loop ?> 

In dieser Loop kann man dann wieder, wie im Blog, die einzelnen Daten, welche man benötigt abrufen.
Ich beschränke mich jetzt hier mal auf den Titel und den Inhalt bzw. eine Vorschau dessen.
Die Ausgabe erfolgt hier per PHP wie folgt:

 <?php the_title();
<?php the_excerpt(); // Vorschautext oder the_content(); ?>

Nun schließt man die while-Schleife noch:

 <? endwhile; ?> 

Sollte kein Ergebnis gefunden worden sein, so wird der else-Zweig der if-have-post-Abfrage ausgeführt:

  <?php else : ?>
         <p class="info">Leider wurde f&uuml;r den Suchbegriff '<strong><?php echo $s ?></strong>' nichts gefunden</p>
      <?php endif; ?> 

Damit ist die Suchfunktion fertig.

© 2018 Abou Chleih. Alle Rechte vorbehalten.

Thema von Anders Norén.