$GLOBALS / Sicherheit / globale Variable

[Netti]

hi,

Frage eins

ich programmiere derzeit ein Forum selber. Mein Hauptargument mir diese Arbeit zu machen liegt in der "Unsicherheit" von vorhandenen Lösungen wie phpbb usw. als auch der mir zu kompakte Quelltext.

Die Benutzerkennung incl. Berechtigungen will ich in der Art:

$GLOBALS['SECURE']['SECURE_RECHTE']

lösen.

Irgendwo im Hinterkopf habe ich noch immer den Gedanken das die Verwendung von $GLOBALS unsicher ist. Von daher meine Frage zur Sicherheit globaler Variablen im Quelltext.

Zweite Frage:

Hier geht es um die Suchmaschinen welche bestimmte bereiche des Forums nicht erreichen sollen.

Mein Gedanke dazu:

Der Google Boot nimmt cookies nicht an (zumindest war es mal so) also dürfte ausreichend sein:

empty($_COOKIE["jssession"]) zu prüfen ob der Fingerprint vorhanden ist

Grüße Netti

[dedlfix]

Tach!

Die Benutzerkennung incl. Berechtigungen will ich in der Art:

$GLOBALS['SECURE']['SECURE_RECHTE']

lösen.

Irgendwo im Hinterkopf habe ich noch immer den Gedanken das die Verwendung von $GLOBALS unsicher ist. Von daher meine Frage zur Sicherheit globaler Variablen im Quelltext.

Formuliere sie bitte. Sicherheit ist kein absolutes Kriterium. Die Frage ist immer, gegen welche Szenarien etwas gesichert sein soll.

Hier geht es um die Suchmaschinen welche bestimmte bereiche des Forums nicht erreichen sollen.

Mein Gedanke dazu:

Der Google Boot nimmt cookies nicht an (zumindest war es mal so) also dürfte ausreichend sein:

empty($_COOKIE["jssession"]) zu prüfen ob der Fingerprint vorhanden ist

Bist du da sicher? Was ist mit anderen Suchmaschinen? Reicht es nicht, diese Bereiche in der robots.txt auszuklammern? Ist es nicht schon damit getan, dass Nutzer angemeldet sein müssen sowie eine bestimmte Berechtigung brauchen, um diese Bereiche zu sehen? Die Suchmaschine ist nur ein Werkzeug, das nicht mag, wenn es andere Inhalte zu Gesicht bekommt, als die Nutzer / Kunden dieses Werkzeuges.

dedlfix.

[Netti]

Formuliere sie bitte. Sicherheit ist kein absolutes Kriterium. Die Frage ist immer, gegen welche Szenarien etwas gesichert sein soll.

Naja, mein Versuch ist eine Seite zu bauen die online die gleich niedrige Verwundbarkeit aufweist als ob sie offline währe ;o)

wenn der Quelltext nicht offen vor einen liegt ist es schon mal schwieriger eine Lücke zu finden... $GLOBALS sind global im Geltungsbereich. gelingt es diese zu manipulieren ist die Seite offen... Ich denke es ist quatsch was ich schreibe, bitte streichen!

@Die Suchmaschine ist nur ein Werkzeug, das nicht mag, wenn es andere Inhalte zu Gesicht bekommt, als die Nutzer / Kunden dieses Werkzeuges.

Na, klar doch aber in bestimmten Bereichen hat sie nichts zu suchen. Ich glaube ich mache das so, es ist eine einfache Lösung. sensible Bereiche sind ohnehin nur per Session zu erreichen.

[dedlfix]

Tach!

wenn der Quelltext nicht offen vor einen liegt ist es schon mal schwieriger eine Lücke zu finden...

Jein. Wenn man die üblichen Lücken sucht, findet man leider viele davon, ohne irgendwelchen Code zu kennen. Injections aller Art und missbrauchbare Mailformulare stehen da ganz oben auf der Liste. Also, zumindeste denke ich mir das, aufgrund der Häufigkeit mit der ich solche Fehler sehe.

$GLOBALS sind global im Geltungsbereich. gelingt es diese zu manipulieren ist die Seite offen... Ich denke es ist quatsch was ich schreibe, bitte streichen!

Früher, als wir noch register_globals hatten, da war das wirklich ein Problem bei unsauberer Programmierweise. Sprich: Wenn man Variablen vor der Erstbenutzung keinen definierten Wert zuwies, sondern das System machen lies. Beides zusammen konnte Variablen ungewünscht vorbelegen.

Ich gehe mal nicht davon aus, dass $GLOBALS auf einfache Weise manipulierbar ist, solange da nicht irgend ein PHP-Code dies tut.

dedlfix.

[Netti]

Früher, als wir noch register_globals hatten, da war das wirklich ein Problem bei unsauberer Programmierweise. Sprich: Wenn man Variablen vor der Erstbenutzung keinen definierten Wert zuwies, sondern das System machen lies. Beides zusammen konnte Variablen ungewünscht vorbelegen.

ok, das war es DANKE !!! habe das letzte mal vor 8 Jahren programmiert ... bzw. diese Forum aktiv genutzt
das ist eine Ewigkeit von der Steinzeit in die Neuzeit

Jein. Wenn man die üblichen Lücken sucht, findet man leider viele davon, ohne irgendwelchen Code zu kennen. Injections aller Art und missbrauchbare Mailformulare stehen da ganz oben auf der Liste. Also, zumindeste denke ich mir das, aufgrund der Häufigkeit mit der ich solche Fehler sehe.

Hm, Habe mich für HTMLPurifier entschieden um Benutzereingaben zu validieren GET und POST laufen mit regex oder $id = intval($_GET['id']);

Bleiben noch die Bilder...

			$finfo = @finfo_open(FILEINFO_MIME_TYPE);	// Gib den MIME Typ zurueck
			if ($finfo !== FALSE && !empty($finfo) > 0){
				$dateiformat = @finfo_file($finfo, $_FILES['file']['tmp_name']);
				@finfo_close($finfo);
			}
			else
			{
				@header("HTTP/1.0 440 (Fehler Nr. 102)");
				exit('Error: Fehler Nr. 102');
			}

meine Ajax Lösung:

 function check_spam_user()
{
	if(empty($_SESSION['TIME']) or !preg_match("/^[0-9]*$/", $_SESSION['TIME']))
	{
		if($_SESSION['TIME']< 1)
		{
			return 1;
		}
	}

	if(!preg_match("/^[a-zA-Z0-9\.-]*$/",$_SERVER["HTTP_HOST"]))
	{
		return 2;
	}

	if(strpos($_SERVER["HTTP_HOST"],$_SERVER["SERVER_NAME"]) === false)
	{
		return 3;
	}

	if(strpos($_SERVER["HTTP_REFERER"],$_SERVER["SERVER_NAME"]) === false)
	{
		return 4;
	}

	if(!$_SERVER["REQUEST_METHOD"])
	{
		return 5;
	}

	if(empty($_SESSION) OR !preg_match("/Benutzername/",  strip_tags(@implode(",", array_keys($_SESSION)))))
	{
		return 6;
	}
}
  

if(check_spam_user())
{
	header("HTTP/1.0 440 (Fehler Nr. 100)");
	exit('Error: Fehler Nr. 100');
}
  

---

Ob es reicht werde ich sehen

[chorn]

paar Sachen die total super sind um sicher zu arbeiten:

• kein $GLOBALS benutzen, kein 'global $var' benutzen, kein $_REQUEST benutzen, möglichst keine Variablen umschreiben ($mail = $_POST['mail']), sondern Variablen immer nachvollziehbar halten, das hält deinen Code sauber und nachvollziehbar = verständlich = sicher(er)

• kein @ benutzen, Fehler nicht einfach unterdrücken und wegignorieren, sondern beheben! finfo_open wirft nichtmal einen Fehler, mach dir also das Leben nicht selber schwer. Erwarte alles, traue niemandem.

• Dateitypen aus finfo etc. auch validieren - also bei einem Bildupload auch nur Bilder berücksichtigen. Sonst kommt noch jemand auf die Idee 'meinbild.jpeg.php' auf deinem Server auszuführen

• Wenn du was vor Suchmaschinen verstecken willst: robots.txt. Wenn du was vor unautorisierten Benutzern verstecken willst: Session.

[dedlfix]

Tach!

• kein $GLOBALS benutzen, kein 'global $var' benutzen,

Warum nicht? Was ist daran problematisch aus sicherheitstechnischen Aspekten? Dass man globalen Status aus anderen Gründen meiden möchte, steht auf einem anderen Blatt.

kein $_REQUEST benutzen,

Warum nicht, wenn man einen Anwendungsfall dafür hat? Meist ist es wohl sinnvoll, solche Anwendungsfälle zu vermeiden, in denen nicht klar ist, ob ein Wert aus $_GET oder $_POST oder $_COOKIE kommt. Aber sicherheitstechnisch ist es doch aus Sicht der Anwendung irrelevant, über welchen Weg die Nutzereingabe aufschlägt.

dedlfix.

[chorn]

Ich finde schlecht wartbarer Code an sich ist gefährlich, alles was nicht eindeutig nachvollziehbar ist, ist schlecht verständlich, und das lässt wieder mehr Raum für Nachlässigkeit und damit für Fehler, was ausserdem die Zeit zum debuggen erhöht - ein Paradebeispiel ist hier alles was mit GLOBAL zu tun hat. Ich beanspruche bei der Liste aber weder Vollständigkeit noch die absolute Wahrheit, sind alles nur Vorschläge mit denen man sich mMn auseinandersetzen sollte.

[dedlfix]

Tach!

Ich finde schlecht wartbarer Code an sich ist gefährlich, alles was nicht eindeutig nachvollziehbar ist, ist schlecht verständlich, und das lässt wieder mehr Raum für Nachlässigkeit und damit für Fehler, was ausserdem die Zeit zum debuggen erhöht - ein Paradebeispiel ist hier alles was mit GLOBAL zu tun hat.

Gut, also mit anderen Worten, eine direkte Gefahr geht von $GLOBALS (und anderen globalen Variablen) nicht aus. Es sind aber die von mir angedeuteten anderen Gründe, warum man globalen Status meidet. Als da zum Beispiel wäre: Man sieht einer Funktion nicht an, dass sie anderswo Werte erwartet oder gar ändert, wenn man lediglich den Aufruf sieht. Es ist besser, alles was die Funktion benötigt, als Parameter zu übergeben und von ihr heraus keine eigenständigen Zugriffe zu unternehmen. Aus Sicht des globalen Wertes betrachtet, kann es jederzeit sein, dass der sich ändert, ohne dass man das sieht, wenn man nicht alle Aufrufe verfolgt.

Das Prinzip, Abhängigkeiten hineinzureichen, statt von drinnen auf irgendwas zuzugreifen, nennt sich Dependency Injection. Dazu gibt es auch Frameworks, die dabei helfen, Abhängigkeiten aufzulösen, doch das reine Prinzip kann man auch ohne ein solches im eigenen Code berücksichtigen.

dedlfix.

[Netti]

paar Sachen die total super sind um sicher zu arbeiten:

Dank Dir

• kein $GLOBALS benutzen, kein 'global $var' benutzen, kein $_REQUEST benutzen, möglichst keine Variablen umschreiben ($mail = $_POST['mail']), sondern Variablen immer nachvollziehbar halten, das hält deinen Code sauber und nachvollziehbar = verständlich = sicher(er)

Warum keine Globals? Eine verständliche Erklärung fehlt mir irgendwie... habe das auch im Hinterkopf GLOBALS = gefährlich

• kein @ benutzen, Fehler nicht einfach unterdrücken und wegignorieren, sondern beheben! finfo_open wirft nichtmal einen Fehler, mach dir also das Leben nicht selber schwer. Erwarte alles, traue niemandem.

Naja, das ist ein Ajax _REQUEST läuft also im Hintergrund PHP Fehlermeldungen sind eine Einladung wenn der _REQUEST per Console abgefangen wird..
also error_reporting(0); plus @

• Dateitypen aus finfo etc. auch validieren - also bei einem Bildupload auch nur Bilder berücksichtigen. Sonst kommt noch jemand auf die Idee 'meinbild.jpeg.php' auf deinem Server auszuführen

kann nicht geschehen bild bekommt eine andere Bez. mit Endung

• Wenn du was vor Suchmaschinen verstecken willst: robots.txt. Wenn du was vor unautorisierten Benutzern verstecken willst: Session.

ok Session werden es werden

[Julius]

Hallo Netti,

• kein @ benutzen, Fehler nicht einfach unterdrücken und wegignorieren, sondern beheben! finfo_open wirft nichtmal einen Fehler, mach dir also das Leben nicht selber schwer. Erwarte alles, traue niemandem.

Naja, das ist ein Ajax _REQUEST läuft also im Hintergrund PHP Fehlermeldungen sind eine Einladung wenn der _REQUEST per Console abgefangen wird..
also error_reporting(0); plus @

Das ist m. E. der falsche Weg:
Du unterdrückst die Fehlermeldung, willst aber eigentlich bloß das Anzeigen der selbigen verhindern (was ja auch sinnvoll ist), was durch das Anpassen der Konfigurationsoption display_errors erreichen lässt (am besten natürlich in der php.ini):

<?php
ini_set('display_errors','');
?>

Sobald du auf Probleme im Betrieb des Systems stößt, wirst du froh sein, wenn du das Log hast...

Gruß
Julius

[Julius]

Hallo chorn,

paar Sachen die total super sind um sicher zu arbeiten:

• […]
• Dateitypen aus finfo etc. auch validieren - also bei einem Bildupload auch nur Bilder berücksichtigen. Sonst kommt noch jemand auf die Idee 'meinbild.jpeg.php' auf deinem Server auszuführen

Nur zur Klarstellung:
Ein PHP-Script sollte aber von finfo unabhängig vom Dateinamen als text/plain o.ä. erkannt werden und nicht als image/jpeg (um beim Beispiel zu bleiben) – Meinst du den Dateinamen, den man durch einen eigenen ersetzen sollte (Nettie hat das wohl auch so interpretiert)?

Gruß
Julius

[Julius]

Hallo Netti,

	header("HTTP/1.0 440 (Fehler Nr. 100)");

• besser keine eigenen Statuscodes definieren, und wenn dann ein 9XXer, dafür sind die da
• nutze $_SERVER["SERVER_PROTOCOL"] statt HTTP/1.0, das kann sonst Probleme bereiten

	exit('Error: Fehler Nr. 100');

Was soll ein Nutzer damit anfangen (wenn du eine Fehlermeldung sendest, kannst du davon ausgehen, dass die sich auch mal irgendjemand anschaut)? Beschreibe lieber in (auch für Laien) verständlicher Sprache:

• was grob passiert ist
• was der Nutzer tun soll (noch mal versuchen/ warten/ Melden?)
• Kontaktmöglichkeiten

Gruß
Julius

[Netti]

• besser keine eigenen Statuscodes definieren, und wenn dann ein 9XXer, dafür sind die da
• nutze $_SERVER["SERVER_PROTOCOL"] statt HTTP/1.0, das kann sonst Probleme bereiten

Hi Julius,

Danke für Deine Antworten!

header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found"); kannte ich so noch nicht!

wenn die Funktion: function check_spam_user() { .... } greift handelt es sich nicht um einen Nutzer mit "guten Absichten" ...

Sinnvoll könnte aus meiner Sicht sein diesen gesamten Funktionsblock in einer .htaccess auszulagern um php nicht bemühen zu müssen.
Derzeit fehlt mir das technische Verständnis um die RewriteRule zu formulieren.

   $.ajax({
        url: 'template/load/ajax.php',
        data: data,
                     processData: false,
                      contentType: false,
        type: 'POST',
        success: function ( data ) {

                        if(data.indexOf("Upload-ok:") != -1)
                        {
                                $("#my_error_string" ).html('<span class="alert-success">erfolgreich hochgeladen!</span>');
........
                        else if(data.indexOf("Error:") != -1)
                         {
                                $("#my_error_string" ).html('Fehler beim hochladen!');

in wie weit es möglich ist mit Hilfe von $.ajax data "Schadcode" einzuschleusen kann ich nicht beurteilen. Theoretisch wird indexOf in der Funktion die Rückgabe von data als String untersuchen.

Da ich alle Ajax php files in das Verzeichnis load lege macht ein einfacher Schutz Regex auf Cookie in einer htaccess Sinn.

Deinen Denkanstoß Fehlerunterdrückung php werde ich aufnehmen meine Lösung könnte so aussehen

        set_error_handler('myHandler');
         #  Code für den eigenen Handler
        
        function myHandler($code, $msg, $file, $line) {
           file_put_contents.....
        }

Grüße Netti

[dedlfix]

Tach!

wenn die Funktion: function check_spam_user() { .... } greift handelt es sich nicht um einen Nutzer mit "guten Absichten" ...

Wenn man das mit hinreichender Genauigkeit feststellen kann (z.b. Zeilenumbrüche in eigentlich einzeiligen Eingabefeldern), dann lohnt es sich kaum, einen ordentlichen Statuscode mitzusenden. Der Spamer wird ihn nicht auswerten. Wenn, dann wäre auch eher ein Forbidden oder ähnliches angebracht.

dedlfix.

[Julius]

Hallo Netti,

Sinnvoll könnte aus meiner Sicht sein diesen gesamten Funktionsblock in einer .htaccess auszulagern um php nicht bemühen zu müssen.
Derzeit fehlt mir das technische Verständnis um die RewriteRule zu formulieren.

…ist bei mir oft nicht anders – ich versuche so viel wie möglich mit php zu erledigen, das ist in den allermeisten Anfragen sowieso schon involviert und sollte daher keinen (Performance-)Unterschied machen. Diese Vorgehensweise erspart auch größere Anpassungsarbeiten an andere verbreitete Webserver neben dem Apache wie nginx oder den IIS von MS, die wieder anders formulierte RewriteRules erfordern.

Gruß
Julius

[Netti]

Hi,

Wie ich schon geschrieben habe ist meine Zeit wo ich in php programmiert habe schon etwas länger her... Also habe ich mich sozusagen "updaten" müssen.

Dabei sind mir folgende Fragen aufgekommen:

1.) Als Db möchte ich weiterhin Mysql benutzen oder gibt es zwischenzeitlich leistungsfähigere Datenbanksysteme die eine Volltextsuche optimal unterstützen? Datenbankgröße ca. 5 GB

2.) mit mysqli_real_escape_string bzw. mit mysqli_stmt_bind_param arbeiten habe das noch nicht ganz verstanden.

3.) welche PHP Version benutzen in Richtung DEPRECATED (veraltet)

[dedlfix]

Tach!

1.) Als Db möchte ich weiterhin Mysql benutzen oder gibt es zwischenzeitlich leistungsfähigere Datenbanksysteme die eine Volltextsuche optimal unterstützen? Datenbankgröße ca. 5 GB

MySQL (oder MariaDB) sind immer noch aktuell und haben die vermutlich größte Nutzerbasis im Zusammenspiel mit PHP.

Wenn MySQL/MariaDB, dann wäre die Frage, ob mysqli oder PDO als Datenbankschnittstelle in Frage kommt. PDO ist etwas anwenderfreundlicher, mysqli ist notwendig, wenn es ans Eingemachte geht (z.B. Stored Procedures). Ein Vergleich der Schnittstellen in PHP.

2.) mit mysqli_real_escape_string bzw. mit mysqli_stmt_bind_param arbeiten habe das noch nicht ganz verstanden.

Was genau? Dass man den Kontextwechsel beachten muss, wenn man Statements mit Einfügen der Werte erstellt, und dass bei Prepared Statements dieser Kontextwechsel prinzipbedingt nicht stattfindet?

3.) welche PHP Version benutzen in Richtung DEPRECATED (veraltet)

Die aktuellste auf dem Zielsystem verfügbare.

dedlfix.

[Netti]

hallo,

vielen Dank für Deine Antwort!

@mysqli oder PDO hm, das ist die Frage... mysqli, so glaube ich gelesen zu haben, erreicht in der Volltextsuche bessere "Geschwindigkeits-Werte"

Was genau? Dass man den Kontextwechsel beachten muss, wenn man Statements mit Einfügen der Werte erstellt, und dass bei Prepared Statements dieser Kontextwechsel prinzipbedingt nicht stattfindet?

Klasse Artikel ich hab's endlich verstanden ;o)

3.) welche PHP Version benutzen in Richtung DEPRECATED (veraltet)

Die aktuellste auf dem Zielsystem verfügbare.

hm 2016, schreiben wir ... meine Seite läuft derzeit im Cluster ich glaube 4-5 Server für http bzw. einen separaten Datenbankserver

um den Datenbankserver zu entlasten hatte ich damals einen Teil des Rams der Cluster als DB-Cache missbraucht .. was natürlich beim Server-Verbund suboptimal ist, der eine Ram wusste vom anderen nichts ;o) welche Möglichkeit besteht Memcache "Serverübergreifend" zu nutzen, wenn es dann eine gibt...

welches cache System ist sinnvoll für dieses kleine Cluster?

function memconect()
{
	$memCache = new Memcache();
	$memCache->addServer(MEM_SERVER_IP, MEM_SERVER_PORT);
	$stats = @$memCache->getExtendedStats();
	$con   = @$memCache->connect(MEM_SERVER_IP, MEM_SERVER_PORT);

	if ((@count($stats[MEM_SERVER_IP.':'.MEM_SERVER_PORT]) > 1) and !empty($con))
	{
		return $memCache;
	}
	return false;
}

[Rolf b]

Die Volltextsuche macht die Datenbank an Hand eines Volltextindex, das sollte vom gewählten API unabhängig sein. Möglicherweise verhalten sich PDO und mysqli beim Handling größerer Resultsets unterschiedlich. Das hast Du aber auch ein wenig selbst in der Hand, PDO bietet unterschiedliche Wege der Ergebnisbereitstellung.

Zum Thema Cluster sag ich nichts, habe noch keinen MySQL Cluster verwendet...

Rolf

[Netti]

Hallo Rolf,

Danke für Deine Antwort. Das Cluster ist wie ich schrieb nur http Anfragen. Alles Server nutzen einen gemeinsamen Datenbankserver. Selber traue ich mir nicht zu einen öffentlichen Server zu warten, also gemanagt vom Provider. Die Nutzung des Rams der Cluster als cache hat auch gut funktioniert. Jedoch gibt es bestimmt bessere Lösungen die ich so noch nicht kenne. Gut Mysql-Cache wird ebenfalls verwendet.

Die Volltextsuche macht die Datenbank an Hand eines Volltextindex, das sollte vom gewählten API unabhängig sein. Möglicherweise verhalten sich PDO und mysqli beim Handling größerer Resultsets unterschiedlich.

Der Mysql-server bereitet mir immer wieder Probleme obwohl ich die Abfragen damals optimiert habe.

[Rolf b]

Hast Du Probleme mit der Antwortzeit bestimmter Queries? Oder geht der Server bei einer bestimmten Nutzerzahl einfach in die Knie? Verwendest Du MyISAM oder InnoDB?

Hat dein Provider Tools, die Dir dabei helfen können, Hotspots in deinen DB Zugriffen zu finden? Wenn nicht - eine Eigenmessung mit microtime() ist lästig und nicht sehr genau, gibt Dir aber immerhin einen Anhalt.

Wenn Du das Lastprofil deiner Datenbank nicht kennst, weißt Du nicht zuverlässig, was Du optimieren musst. Möglicherweise cachst Du an einem Ende, das in der Realität gar nicht der Knackpunkt ist, und hast dafür am anderen Ende Queries laufen, die Tablescans über Millionen Zeilen machen. bloß weil ein geeigneter Index fehlt. MyISAM ist bei vielen Usern ebenfalls kritisch, weil es keine Row-Locks kennt, nur Table Locks.

Rolf

[Netti]

Hast Du Probleme mit der Antwortzeit bestimmter Queries? Oder geht der Server bei einer bestimmten Nutzerzahl einfach in die Knie? Verwendest Du MyISAM oder InnoDB?

mysql wird verwendet. Ja, das Problem ist und war die hohe Anzahl der gleichzeitigen Abfragen ... irgendwann crasht die Datenbank. ich muss sie dann manuell reparieren ... wie gesagt ich arbeite jetzt an einer neuen Seite für mobile Endgeräte ;o) evtl. gibt es auch ein App mal sehen

Hat dein Provider Tools, die Dir dabei helfen können, Hotspots in deinen DB Zugriffen zu finden? Wenn nicht - eine Eigenmessung mit microtime() ist lästig und nicht sehr genau, gibt Dir aber immerhin einen Anhalt. Wenn Du das Lastprofil deiner Datenbank

das was ging habe ich damals optimiert ... jetzt geht's darum möglichst ein schnelle Anwendung zu programmieren mit den Software Möglichkeiten welche 2016 bietet. Facebook / Google nutzen auch den shared memory Bereich für ihre Systeme ... ich frage mich wie sie das im Cluster machen ?

[Rolf b]

Verwendest Du MyISAM oder InnoDB? mysql wird verwendet.

Du weißt aber, dass MyISAM und InnoDB zwei Storage Engines von MySQL sind? Und InnoDB für viele parallele Zugriffe besser ist (weil es zu Row-Locking und Transaktionen fähig ist, MyISAM aber nicht)?

Facebook / Google nutzen auch den shared memory Bereich für ihre Systeme ... ich frage mich wie sie das im Cluster machen ?

Caching und Cluster ist aufwändig, weil du den Cache ggf. auch clustern musst (allein schon zur Ausfallsicherheit). Und dann müssen sich die Instanzen untereinander verständigen. Aber bei den von Dir genannten Web-Dinos ist genug Geld, um dafür geeignete Produkte auszuwählen. Ich muss an der Stelle das Handtuch werfen.

Rolf

[Camping_RIDER]

Aloha ;)

Zweite Frage:

Hier geht es um die Suchmaschinen welche bestimmte bereiche des Forums nicht erreichen sollen.

Mein Gedanke dazu:

Der Google Boot nimmt cookies nicht an (zumindest war es mal so) also dürfte ausreichend sein:

empty($_COOKIE["jssession"]) zu prüfen ob der Fingerprint vorhanden ist

Das würde ich lassen. Nicht alles was auf den ersten Blick funktioniert ist auch sinnvoll gelöst. Dir wurde schonmal die Frage gestellt, was mit anderen Suchmaschinen ist - die wirst du sicher nicht sinnvoll beantworten können so.

Es gibt eigentlich zwei Arten von Suchmaschinen: "Seriöse" Suchmaschinen, die die Angaben der 'robots.txt' auswerten, ernst nehmen und respektieren (nach dem Kriterium gehört hier auch Google dazu) und "unseriöse" Suchmaschinen, die sich über diese Angaben hinwegsetzen.

Du möchtest Google davon abhalten, die Seite aufzusuchen - dazu genügt die robots.txt oder die dazu äquivalente Verwendung der entsprechenden META-Angabe in betroffenen HTML-Dokumenten. Wenn du diese statt deiner selbstgestrickten Lösung verwendest hast du damit einerseits nicht nur Google, sondern auch jede andere seriöse Suchmaschine von Zugriff abgehalten und andererseits erzielst du den gewünschten Effekt damit auch dann noch, wenn der Google-Bot in Zukunft irgendwann beschließt, auf einmal doch Cookies anzunehmen.

Die Suchmaschinen, die unter unseriös fallen, kannst du so oder so nicht abhalten - auch nicht und gerade nicht mit deiner selbstgestrickten Lösung, da du von diesen Suchmaschinen noch weniger weißt, ob sie nicht doch ein Cookie annehmen.

Es ist sogar noch eher so, dass deine selbstgestrickte Lösung dich in dem Fall in einer falschen Sicherheit wiegt. Wenn ein Feature eine gewagte Annahme oder zukunftsunsichere Annahme (nicht-annehmen von Cookies) benötigt, um sicher zu sein, dann ist es nicht sicher. Dann sich doch lieber gleich eingestehen, dass man die Suchmaschinen nur bitten kann, da weg zu bleiben, und auf Mithilfe so oder so angewiesen ist.

Wenn es dir wirklich sehr wichtig ist kannst du deine Cookie-Lösung zusätzlich verwenden. Ich mahne aber zur Vorsicht: wenn es dir so wichtig ist, dass dir die freiwillige Mithilfe der Suchmaschinen nicht ausreicht, dann spricht das sehr stark dafür, dass du da einen Konzeptfehler gemacht hast und die betroffenen Inhalte lieber hinter einer tatsächlich sicheren Auth-Lösung verstecken möchtest statt quasi-willkürlich einzelne Clients (die ohne Cookie-Annahme) auszufiltern.

Grüße,

RIDER

[Netti]

hallo,

der Google-Bot in Zukunft irgendwann beschließt, auf einmal doch Cookies anzunehmen.

ich war mir nicht sicher ob er das nicht schon macht ...

ansonsten ja klar META-Angabe machen natürlich Sinn und stellen keinen Aufwand dar ;o)

Danke