Nur eine einfache Benutzerauthentifizierungslösung innerhalb eines supereinfachen Framework-Skeletts, das sofort einsatzbereit ist (und mit einem automatischen Installer geliefert wird) und die zukunftssichere offizielle bcrypt-Passwort-Hashing-/Salting-Implementierung von PHP 5.5+ und mehr verwendet einige nette Funktionen, die die Zeit von der Idee bis zur ersten nutzbaren Prototypanwendung erheblich verkürzen werden. Mehr nicht. Der Schwerpunkt dieses Projekts liegt auf Hardcore-Einfachheit. Alles so einfach wie möglich, gemacht für kleinere Projekte, typische Agenturarbeit und schnelle Entwürfe. Wenn Sie umfangreiche Unternehmensanwendungen mit allen Funktionen moderner Frameworks erstellen möchten, dann werfen Sie einen Blick auf Laravel, Symfony oder Yii. Wenn Sie jedoch nur schnell etwas erstellen möchten, das einfach funktioniert, dann könnte dieses Skript für Sie interessant sein.
Die möglichst einfache Architektur von HUGE wurde von mehreren Konferenzvorträgen, Folien und Artikeln über riesige Anwendungen inspiriert, die überraschenderweise und absichtlich auf die Grundlagen der Programmierung zurückgreifen und prozedurale Programmierung, statische Klassen und extrem einfache Konstrukte verwenden, die nicht ganz trocken sind Code usw., während der Code äußerst lesbar bleibt (StackOverflow, Wikipedia, SoundCloud).
Einige interessante Schlagworte in diesem Zusammenhang: KISS, YAGNI, Feature Creep, Minimum Viable Product.
Um dieses Projekt stabil, sicher, sauber und minimal zu halten, habe ich beschlossen, die Entwicklung von HUGE auf ein Minimum zu reduzieren. Keine Sorge, das ist tatsächlich eine gute Sache: Neue Funktionen bedeuten normalerweise neue Fehler, viele Tests, Korrekturen, Inkompatibilitäten und für manche Leute sogar harten Update-Stress. Da es sich bei HUGE um ein sicherheitskritisches Skript handelt, sind neue Funktionen nicht so wichtig wie ein stabiler und sicherer Kern. Aus diesem Grund wird es verwendet. Das heisst:
Und ehrlich gesagt ist es auch nicht das, was ich dauerhaft tun möchte, wenn ich in meiner knappen Freizeit ein kostenloses Framework betreibe. :) :)
Abschließend noch eine kleine Anmerkung: Die PHP-Welt hat sich dramatisch weiterentwickelt. Wir verfügen über hervorragende Frameworks mit großartigen Funktionen und großen professionellen Teams im Rücken, sehr gut geschriebene Dokumentationen und große Communities. Es gibt also einfach keinen Grund, viel Arbeit in ein anderes Framework zu stecken. Bekennen Sie sich stattdessen bitte zu den gängigen Frameworks, dann wird Ihre Arbeit viel mehr Wirkung erzielen und von viel mehr Menschen genutzt werden!
Vielen Dank an alle, die an diesem Projekt beteiligt sind. Ich wünsche Ihnen eine wunderbare Zeit! XOXO, Chris
Im Jahr 2010/2011 gab es in der PHP-Welt keine brauchbaren Login-Lösungen, zumindest nicht für Nicht-Experten. Also habe ich den schlimmsten Fehler gemacht, den jeder junge Entwickler macht: Ich habe versucht, selbst etwas zu entwickeln, ohne eine Ahnung von Sicherheitsgrundlagen zu haben. Was es noch schlimmer machte, war (und ist): Das Internet war (und ist) voll von völlig kaputten Tutorials zum Aufbau von Benutzerauthentifizierungssystemen, selbst die größten Unternehmen der Welt haben das völlig falsch gemacht (wir sprechen hier von SONY, LinkedIn und Adobe) und Außerdem verwendeten viele wichtige Frameworks in allen großen Programmiersprachen (!) völlig veraltete und unsichere Technologien zum Speichern von Passwörtern.
Allerdings veröffentlichte der Sicherheitsexperte Anthony Ferrara 2012 eine kleine PHP-Bibliothek, die in PHP 5.3 und 5.4 ein äußerst sicheres, modernes und korrektes Hashing von Passwörtern ermöglicht, das von jedem Entwickler stressfrei und ohne Kenntnisse über Sicherheitsinterna genutzt werden kann. Das Skript war so großartig, dass es in den Kern von PHP 5.5 geschrieben wurde, es ist heutzutage der De-facto-Standard.
Als dies herauskam, habe ich versucht, diese nackte Bibliothek zu verwenden, um ein voll funktionsfähiges, sofort einsatzbereites Anmeldesystem für mehrere private und kommerzielle Projekte zu erstellen, und habe den Code auf GitHub gestellt. Viele Leute fanden das nützlich, haben zum Projekt beigetragen und Fehler behoben, Forks erstellt, kleinere und größere Versionen. Das Ergebnis ist dieses Projekt.
Bitte beachten Sie: Jetzt, im Jahr 2015, verfügen die meisten großen Frameworks standardmäßig über eine hervorragende Benutzerauthentifizierungslogik. Dies war vor Jahren noch nicht der Fall. Aus heutiger Sicht könnte es also klüger sein, für ernsthafte Projekte Laravel, Yii oder Symfony zu wählen. Aber probieren Sie HUGE gerne aus, der Auto-Installer startet innerhalb von Minuten und ohne Konfiguration eine voll funktionsfähige Installation.
Und warum der Name „RIESIG“? Es ist eine schöne Kombination zu TINY, MINI und MINI2, MINI3, die einige meiner anderen älteren Projekte sind. Superminimale Mikroframeworks für die extrem schnelle und einfache Entwicklung einfacher Websites.
Eine Live-Demo der älteren Version 3.0 finden Sie hier und die phpinfo()-Funktion des Servers finden Sie hier.
Hinter diesem Projekt steckt viel Arbeit. Ich könnte Ihnen Hunderte, vielleicht Tausende Arbeitsstunden ersparen (rechnen Sie das anhand der Entwicklerkosten). Wenn Sie also mit HUGE Geld verdienen, seien Sie fair und geben Sie etwas an Open Source zurück. HUGE ist für die private und kommerzielle Nutzung völlig kostenlos.
Unterstützen Sie das Projekt, indem Sie einen Server bei DigitalOcean mieten oder einfach bei BuyMeACoffee.com ein Trinkgeld für einen Kaffee geben. Danke! :) :)
Fühlen Sie sich auch frei, zu diesem Projekt beizutragen.
Lizenziert unter MIT. Völlig kostenlos für private oder kommerzielle Projekte.
Stellen Sie sicher, dass Sie die Grundlagen der objektorientierten Programmierung und MVC kennen, die Befehlszeile verwenden können und Composer bereits verwendet haben. Dieses Skript ist nichts für Anfänger.
Yo, vollautomatisch. Warum ? Weil ich es immer gehasst habe, Tage damit zu verbringen, herauszufinden, wie man etwas installiert. Das erspart Ihnen jede Menge Zeit und Nerven. Spenden Sie einen Kaffee, wenn Sie ihn mögen.
Wenn Sie Vagrant für Ihre Entwicklung verwenden, dann einfach
vagrant box add ubuntu/trusty64
vagrant up
in diesem Ordner.5 Minuten später haben Sie Ubuntu 14.04 LTS vollständig installiert. Der vollständige Code wird automatisch mit dem aktuellen Ordner synchronisiert. Das MySQL-Root-Passwort und das PHPMyAdmin-Root-Passwort sind auf 12345678 eingestellt. Standardmäßig ist 192.168.33.111 die IP Ihrer neuen Box.
Extrem einfache Installation auf einem frischen und nackten typischen Ubuntu 14.04 LTS-Server:
Laden Sie das Installationsskript herunter
wget https://raw.githubusercontent.com/panique/huge/master/_one-click-installation/bootstrap.sh
Machen Sie es ausführbar
chmod +x bootstrap.sh
Lass es laufen! Nehmen Sie sich ein paar Minuten Zeit, um alle Aufgaben zu erledigen. Und ja, du kannst mir später danken :)
sudo ./bootstrap.sh
Composer install
im Stammordner der Anwendung aus, um Abhängigkeiten zu installieren„E-Mail funktioniert nicht“? Siehe die Fehlerbehebung unten. TODO
Dies ist nur eine kurze Anleitung zur einfachen Einrichtung einer Entwicklungsumgebung!
Stellen Sie sicher, dass Sie Apache, PHP 5.5+ und MySQL installiert haben. Anleitung hier. Nginx wird sicher auch funktionieren, aber es sind noch keine Installationsrichtlinien verfügbar.
Bearbeiten Sie vhost, um saubere URLs zu ermöglichen und den gesamten Datenverkehr an den Ordner /public Ihres Projekts weiterzuleiten:
sudo nano /etc/apache2/sites-available/000-default.conf
und lassen Sie die Datei so aussehen
<VirtualHost *:80>
DocumentRoot "/var/www/html/public"
<Directory "/var/www/html/public">
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
Aktivieren Sie mod_rewrite und starten Sie Apache neu.
sudo a2enmod rewrite
service apache2 restart
Installieren Sie Curl (erforderlich, um Git zu verwenden), OpenSSL (erforderlich, um von GitHub zu klonen, da Github nur https ist), PHP GD, die Grafikbibliothek (wir erstellen Captchas und Avatare) und Git.
sudo apt-get -y install curl
sudo apt-get -y install php5-curl
sudo apt-get -y install openssl
sudo apt-get -y install php5-gd
sudo apt-get -y install git
Git-Klon RIESIG
sudo git clone https://github.com/panique/huge " /var/www/html "
Installieren Sie Composer
curl -s https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer
Gehen Sie zum Projektordner und laden Sie Composer-Pakete (--dev ist optional, Sie kennen das Problem).
cd /var/www/html
composer install --dev
Führen Sie die SQL-Anweisungen aus. Zum Beispiel über phpmyadmin oder über die Kommandozeile. 12345678 ist das Beispielpasswort. Beachten Sie, dass dies ohne Leerzeichen geschrieben wird.
sudo mysql -h " localhost " -u " root " " -p12345678 " < " /var/www/html/application/_installation/01-create-database.sql "
sudo mysql -h " localhost " -u " root " " -p12345678 " < " /var/www/html/application/_installation/02-create-table-users.sql "
sudo mysql -h " localhost " -u " root " " -p12345678 " < " /var/www/html/application/_installation/03-create-table-notes.sql "
Den Avatar-Ordner beschreibbar machen (auf den richtigen Pfad achten!)
sudo chown -R www-data " /var/www/html/public/avatars "
Wenn dies bei Ihnen nicht funktioniert, können Sie es auf die harte Tour versuchen und alternativ eine andere Einstellung vornehmen
sudo chmod 0777 -R " /var/www/html/public/avatars "
Entfernen Sie die Standard-Demodatei von Apache
sudo rm " /var/www/html/index.html "
Bearbeiten Sie die Konfiguration der Anwendung in application/config/config.development.php und geben Sie Ihre Datenbankanmeldeinformationen ein.
Letzter Teil (für einen ersten Test nicht erforderlich): Legen Sie Ihre SMTP-Anmeldeinformationen in derselben Datei fest und setzen Sie EMAIL_USE_SMTP auf „true“, damit Sie ordnungsgemäße E-Mails senden können. Es wird dringend empfohlen, SMTP für den E-Mail-Versand zu verwenden! Der native Versand über PHPs mail() funktioniert in fast allen Fällen nicht (Spam-Blockierung). Ich verwende SMTP2GO.
Überprüfen Sie dann die IP/Domäne Ihres Servers. Alles sollte gut funktionieren.
Dies ist ein ungetestetes NGINX-Setup. Bitte kommentieren Sie das Ticket, wenn Sie Probleme sehen.
server {
# your listening port
listen 80;
# your server name
server_name example.com;
# your path to access log files
access_log /srv/www/example.com/logs/access.log;
error_log /srv/www/example.com/logs/error.log;
# your root
root /srv/www/example.com/public_html;
# huge
index index.php;
# huge
location / {
try_files $uri /index.php?url=$uri&$args;
}
# your PHP config
location ~ .php$ {
try_files $uri = 401;
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/run/php-fastcgi/php-fastcgi.socket;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
Vielen Dank an Razuro für dieses tolle Setup: Legen Sie dies in Ihrem Stammordner ab, aber legen Sie keine web.config in Ihrem öffentlichen Ordner ab.
<?xml version="1.0" encoding="UTF-8"?><configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Imported Rule 1" stopProcessing="true">
<match url="^(.*)$" ignoreCase="false" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="public/index.php?url={R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Das Originalticket finden Sie hier.
Standardmäßig gibt es zwei Demo-Benutzer, einen normalen Benutzer und einen Admin-Benutzer. Weitere Informationen hierzu finden Sie im Abschnitt „Benutzerrolle“ im kleinen Dokumentationsblock in dieser Readme-Datei.
Normaler Benutzer: Benutzername ist demo2
, Passwort ist 12345678
. Der Benutzer ist bereits aktiviert. Admin-Benutzer (kann andere Benutzer löschen und sperren): Benutzername ist demo
, Passwort ist 12345678
. Der Benutzer ist bereits aktiviert.
Im Stammordner des Projekts befinden sich mehrere Dateien, die möglicherweise irritierend sind:
README und CHANGELOG sind selbsterklärend.
Eine echte Dokumentation ist in Vorbereitung. Schauen Sie sich bis dahin bitte den Code an und nutzen Sie die Code-Vervollständigungsfunktionen Ihrer IDE, um eine Vorstellung davon zu bekommen, wie die Dinge funktionieren. Dies ist ziemlich offensichtlich, wenn Sie sich die Controller-Dateien, die Modelldateien und die Darstellung der Daten in den Ansichtsdateien ansehen. Es tut mir sehr leid, dass es noch keine Dokumentation gibt, aber die Zeit ist knapp und wir alle machen das in unserer Freizeit kostenlos :)
Derzeit gibt es zwei Arten von Benutzern: Normale Benutzer und Administratoren. Es gibt genau die gleichen, aber...
Admin-Benutzer können andere Benutzer löschen und sperren, dafür gibt es in der Navigation einen zusätzlichen Button „Admin“. Admin-Benutzer haben im Datenbanktabellenfeld user_account_type
den Wert 7
. Sie können ihre Konten nicht upgraden oder downgraden (da dies keinen Sinn ergibt).
Normale Benutzer haben mit Sicherheit keine Admin-Funktionen. Aber sie können ihre Konten upgraden und downgraden (probieren Sie es über /user/changeUserRole aus), was im Grunde eine supereinfache Implementierung des Basic-User-/Premium-User-Konzepts ist. Normale Benutzer haben im Datenbanktabellenfeld user_account_type
den Wert 1
oder 2
. Standardmäßig sind alle neu registrierten Benutzer mit Sicherheit normale Benutzer mit Benutzerrolle 1.
Weitere Informationen finden Sie im Abschnitt „Testen mit Demobenutzern“ dieser Readme-Datei.
Es gibt auch einen sehr interessanten Pull-Request zum Hinzufügen von Benutzerrollen und Benutzerberechtigungen, der nicht in das Projekt integriert ist, da er zu fortgeschritten und komplex ist. Aber das könnte genau das sein, was Sie brauchen, probieren Sie es einfach aus.
Um CSRF-Angriffe zu verhindern, tut HUGE dies am häufigsten, indem es ein Sicherheitstoken verwendet, wenn der Benutzer kritische Formulare übermittelt. Das bedeutet: Wenn PHP ein Formular für den Benutzer rendert, fügt die Anwendung einen „zufälligen String“ in das Formular ein (als verstecktes Eingabefeld), der über Csrf::makeToken() (application/core/Csrf.php) generiert wird speichert dieses Token auch in der Sitzung. Beim Absenden des Formulars prüft die Anwendung, ob die POST-Anfrage genau das Formular-Token enthält, das sich in der Sitzung befindet.
Diese CSRF-Verhinderungsfunktion ist derzeit im Anmeldeformularprozess (siehe application/view/login/index.php ) und im Formularprozess zur Änderung des Benutzernamens (siehe application/view/user/editUsername.php ) implementiert. Die meisten anderen Formulare sind nicht sicherheitsrelevant. kritisch und sollte so einfach wie möglich bleiben.
Um dies also mit einem normalen Formular zu tun, gehen Sie einfach wie folgt vor: Geben Sie in Ihrem Formular vor der Schaltfläche „Senden“ Folgendes ein: <input type="hidden" name="csrf_token" value="<?= Csrf::makeToken(); ?>" />
Dann validieren Sie in der Controller-Aktion das mit dem Formular übermittelte CSRF-Token, indem Sie Folgendes tun:
// check if csrf token is valid
if (!Csrf::isTokenValid()) {
LoginModel::logout();
Redirect::home();
exit();
}
Ein großes Dankeschön an OmarElGabry für die Umsetzung!
Theoretisch: Ja, aber diese Funktion hat in meinen Tests nicht funktioniert. Da es sich um eine externe Funktion handelt, werfen Sie bitte einen Blick in das entsprechende Ticket, um weitere Informationen zu erhalten.
Es gibt einige tolle Features oder Feature-Ideen, die von tollen Leuten entwickelt wurden, aber diese Features sind zu speziell, um in die Hauptversion von HUGE aufgenommen zu werden, aber schauen Sie sich diese Tickets an, wenn Sie interessiert sind:
Die Idee dieses Projekts besteht darin, eine supereinfache Barebone-Anwendung mit einem vollständigen Benutzerauthentifizierungssystem bereitzustellen, die einwandfrei und stabil funktioniert. Aufgrund des stark sicherheitsbezogenen Charakters dieses Skripts bedeuten alle Änderungen viel Arbeit, viele Tests, das Erkennen von Randfällen usw., und am Ende habe ich 90 % der Zeit damit verbracht, neue Funktionen zu testen und zu reparieren oder bestehende Funktionen zu beschädigen Sachen, und das zu tun ist wirklich nicht das, was irgendjemand in der seltenen Freizeit kostenlos tun möchte :)
Um das Projekt stabil, sauber und wartbar zu halten, würde ich freundlicherweise das „Soft-End of Life“ für dieses Projekt bekannt geben, was bedeutet:
A. HUGE wird in Zukunft keine neuen Funktionen erhalten, aber ... B. Bugfixes und Korrekturen werden vorgenommen, wahrscheinlich über Jahre hinweg
Während HUGE in der Entwicklung war, gab es drei Hauptregeln, die mir (und wahrscheinlich auch anderen) dabei halfen, minimalen, sauberen und funktionierenden Code zu schreiben. Könnte auch für Sie nützlich sein:
Wie in der Einleitung dieser README-Datei erwähnt, gibt es auch einige leistungsstarke Konzepte, die Ihnen bei der Entwicklung cooler Dinge helfen könnten: KISS, YAGNI, Feature Creep, Minimum Viable Product.
Um unnötige Arbeit für uns alle zu vermeiden, würde ich jedem empfehlen, HUGE für einfache Projekte zu verwenden, die nur die bereits vorhandenen Funktionen benötigen. Wenn Sie wirklich eine RESTful-Architektur, Migrationen, Routing, 2FA usw. benötigen, ist es einfacher, sauberer und einfacher schneller, wenn man einfach Laravel, Symfony oder Zend verwendet.
Hier sind jedoch die von der Community vorgeschlagenen möglichen Funktionen, die aus vielen Tickets stammen. Fühlen Sie sich frei, sie in Ihre Forks des Projekts zu implementieren:
Es gab zwei (!) Support-Foren für Version 1 und Version 2 dieses Projekts (RIESIG ist Version 3), und beide wurden von Leuten zerstört, die nicht einmal die Readme-Datei und/oder die Installationsrichtlinien gelesen hatten. Die am häufigsten gestellte Frage war „Skript funktioniert nicht, bitte helfen Sie mir“, ohne nützliche Informationen anzugeben (wie Code oder Server-Setup oder sogar die verwendete Version). Während ich diese Zeilen schreibe, hat mich gerade jemand über Twitter gefragt: „Wie installiere ich ohne Composer?“ Sie wissen, was ich meine :) - 99 % der Fragen wären nicht notwendig, wenn die Leute die Richtlinien gelesen hätten, ein wenig selbst recherchiert hätten oder aufgehört hätten, die Dinge unnötig kompliziert zu machen. Und selbst als sie ausführliche Antworten schrieben, vermasselten die meisten es immer noch, was zu Tiraden und Beschwerden führte (für kostenlosen Support für eine kostenlose Software!). Es war einfach frustrierend, sich jeden Tag damit auseinanderzusetzen, vor allem wenn man davon ausgeht, dass es die Pflicht von Open-Source-Entwicklern ist , bei jeder „PLZ-Hilfe“-Anfrage detaillierten, kostenlosen und persönlichen Support zu leisten.
Deshalb habe ich beschlossen, jeglichen kostenlosen Support komplett einzustellen. Bei ernsthaften Fragen zu echten Problemen im Skript nutzen Sie bitte die GitHub-Problemfunktion.
Harte Worte, aber da heutzutage praktisch jedes öffentliche Internetprojekt von sehr seltsamen Leuten belästigt, zerstört und trollt wird, ist es notwendig: Ein paar einfache Regeln.
Respektieren Sie, dass dies nur ein einfaches Drehbuch ist, das von unbezahlten Freiwilligen in ihrer Freizeit geschrieben wurde. Dies ist KEINE Unternehmenssoftware, die Sie für 10.000 US-Dollar gekauft haben. Es gibt keinen Grund, sich (!) über kostenlose Open-Source-Software zu beschweren. Die Haltung gegenüber freier Software ist heutzutage wirklich frustrierend. Die Leute halten alles für selbstverständlich, ohne sich der Arbeit dahinter bewusst zu sein, und der Tatsache, dass sie seriöse Software völlig kostenlos erhalten und dadurch Tausende von Dollar sparen. Wenn es Ihnen nicht gefällt, dann verwenden Sie es nicht. Wenn Sie eine Funktion wünschen, versuchen Sie, an dem Prozess teilzunehmen, vielleicht bauen Sie sie sogar selbst und fügen Sie sie dem Projekt hinzu! Sei nett und respektvoll. Konstruktive Kritik ist natürlich immer willkommen!
Nicht verprügeln, nicht hassen, nicht spammen, nicht zerstören. Bitten Sie nicht um persönliche kostenlose Unterstützung, fragen Sie nicht, ob jemand Ihre Arbeit für Sie erledigen könnte. Bevor Sie etwas fragen, stellen Sie sicher, dass Sie die README-Datei gelesen, alle Tutorials befolgt, den Code noch einmal überprüft und versucht haben, das Problem selbst zu lösen.
Trolle und sehr nervige Personen werden dauerhaft gesperrt/gesperrt. GitHub verfügt über ein sehr leistungsfähiges Anti-Missbrauchsteam.
Bitte verpflichten Sie sich nur im Entwicklungszweig . Der Master -Zweig enthält immer die stabile Version.
Scrutinizer (Hauptzweig), Scrutinizer (Entwicklungszweig), Code Climate, Codacy, SensioLabs Insight.
Aufgrund der möglichen Konsequenzen, wenn Sie einen Fehler in einem öffentlichen Open-Source-Projekt veröffentlichen, bitte ich Sie, wirklich große Fehler an meine E-Mail-Adresse zu senden und diese nicht hier zu veröffentlichen. Wenn der Bug für Angreifer nicht interessant ist: Erstellen Sie gerne einen normalen GitHub-Issue.
Aktive Probleme finden Sie hier: https://github.com/panique/huge/issues?state=open
Interessantes Problem: Wenn ein Benutzer Ihre Website aufruft, fordert der Browser des Benutzers auch ein oder mehrere (!) Favicons (verschiedene Größen) an. Wenn diese statischen Dateien nicht vorhanden sind, beginnt Ihre Anwendung mit der Generierung einer 404-Antwort und einer 404-Seite für jede Datei. Dies verschwendet viel Serverleistung und ist auch nutzlos. Stellen Sie daher sicher, dass Sie immer über Favicons verfügen, oder behandeln Sie dies auf Apache/Nginx-Ebene.
HUGE versucht, damit umzugehen, indem es ein leeres Bild im Kopf der Ansicht/_templates/header.php sendet!
Weitere Informationen in diesem Ticket: Geben Sie den richtigen 404-Fehler für fehlendes favicon.ico, fehlende Bilder usw. zurück.
Mehr hier auf Stackflow: Wie kann man favicon.ico-Anfragen verhindern? Ist es nicht albern, dass ein kleines Favicon noch eine weitere HTTP-Anfrage erfordert? Wie kann man ein Favicon in ein Sprite integrieren?
Ich blogge auch bei Dev Metal .