• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

[FRAGE] Object to Hash Funktion, bitte um Durchsicht

Elma

New member
Moin.
Ich habe eine Funktion erstellt, um einen Hash von einem Objekt zu erzeugen.

Die Funktion dient dazu, in meiner Anwendung (Browsergame) verschiedene Hashs zu erstellen, um Manipulationen durch den Spieler zu erschweren.

Erster Verwendungszeck:
Es werden diverse Informationen aus dem Objekt Navigator und dem Object Screen in einem neuen Objekt zusammengestellt, und damit ein Browserhash erzeugt, an den Server gesendet und in der Session hinterlegt. Wenn der Hash nicht mehr stimmt, wird der User ausgeloggt. Das soll einem eventuellen Session Stealing entgegenwirken.

Zweiter Verwendungszweck:
Jedes andere Spielrelevante Objekt wird mit einem Hash versehen. Wie zum Beispiel Item-Objekte. Oder auch das Spielerobjekt.
So soll soll der Hash eine zusätzliche Sicherheit gegen Manipulationsversuche schaffen. Zum Beispiel Geldbestand oder Itempreise faken.
Die Spiellogik ist zwar großteils Serverseitig, z.B. die Prüfung, ob sich ein Spieler ein bestimmtes Item überhaupt leisten kann, und der Abzug des Geldes.
Allerdings soll schon der Versuch einer Manipulation erkennbar sein, wenn jemand in der Entwicklerkonsole "Herummacht".

Hier die Funktion:

Code:
//Funktion zum Umwandeln eines Objektes in einen Hash
function objToHash (obj) {
	var resultstring="";
	var hash="";
	var iterations=1000; //Maximale Zahl von Iterationen
	var history=[]; //Array für bereits besuchte Objekte

	var iterator = function (obj) {
		var prop;
		var value;
		var res="";	
		var i=0;
		
		if (iterations == 0) {
			console.log("Iteration abort"); //Endlosschleife verhindern
			return;
		}
		iterations--;

		for (prop in obj) { 
				value=obj[prop]; //Wert
				if ((typeof(value)=="object") && obj.hasOwnProperty(prop) && (!!value)) {
					//Objekt verarbeiten
					if (history.indexOf(value) !== -1) return; //bei Circulation abbrechen
					//for (i=0; i < history.length; i++) {
					//	if (history[i] == value) {
					//		console.log("Circulation abort"); //bei Circulation abbrechen
					//		return;
					//	}
					//}

					history.push(value); //Objekt in history einfügen

					res=res+"Object: "+prop+" {\n"
					//Iteration
					res=res+iterator(value) +"}\n";
					
				} else if (typeof(value)=="function" && !!value ) {
					// Funktionen ausgeben
					res=res+"Function: "+prop+" {\n"+value+"\n}\n";

				} else if (!!value) {
					// Primitive Werte ausgeben
					res=res+(prop + ": "+value)+"\n";
				}
			}
			return res;
		}


		// Funktion zum Erzeugen eines Hashes
		var hashcode = function (str){
		var hash = 0;
		var i;
		var chr;
		str=String(str) || "";
		for (i = 0; i < str.length; i++) {
				chr = str.charCodeAt(i);
				hash = ((hash<<5)-hash)+chr;
				hash = parseInt(hash); // Convert to integer
		}
		// Umwandeln in Hex, Kein Negativwert
		hash=(hash >>> 0).toString(16);
		// Führende nullen einfügen, in String wandeln und zurückgeben
		return String(("0000000" + hash).slice(-8));
}


Ich würde mich freuen, wenn ihr mal drüber schaut, und mir sagt, ob das so in Ordnung ist.

LG
 
Hi.
Dass es das gibt, wusste ich bislang nicht. Nichts desto trotz war die Erstellung der Funktion eine sehr gute Übung für mich.
Werds mir aber mal runterladen und den Code ansehen.

Bei richtig aktuellen Browsern braucht man übrigens gar keinen Aufwand zu betreiben. JSON.Stringify nutzen und dann die Webcrypto API nutzen fertig ist die Laube.



Meine Funktion funktioniert, wenn man indexOf nicht verwendet und stattdessen die auskommentierte Schleife darunter nimmt, sogar noch auf alten IEs. Das würde es zumindest für das Hashen der aus dem Objekt navigator und Screen usw. gesammelten Browserinfos interessant machen.
Ein 32 Bit Hash ist zwar nicht wirklich was einzigartiges, aber um aus den Browserinfos einen kurzen Schlüssel zu machen, um Sessions ein zusätzliches Identifikationsmerkmal zu verpassen, wäre es doch ganz gut.
 
Bei richtig aktuellen Browsern braucht man übrigens gar keinen Aufwand zu betreiben. JSON.Stringify nutzen und dann die Webcrypto API nutzen fertig ist die Laube.
Wenn es dir darum geht die Werte eines Objektes über den Hash zu verifizieren, wird das nicht ausreichen, denn bereits eine andere Reihenfolge der Properties führt zu einem anderen Hashwert - auch wenn die Werte eigentlich korrekt sind:

PHP:
JSON.stringify({a: 1, b: 2}) !== JSON.stringify({b: 2, a: 1})

object-hash kümmert sich bereits darum: object-hash example.

Meine Funktion funktioniert, wenn man indexOf nicht verwendet und stattdessen die auskommentierte Schleife darunter nimmt, sogar noch auf alten IEs. Das würde es zumindest für das Hashen der aus dem Objekt navigator und Screen usw. gesammelten Browserinfos interessant machen.

Ein Auszug aus der object-hash Beschreibung:
Legacy Browser Support
IE <= 8 and Opera <= 11 support dropped in version 0.3.0. If you require legacy browser support you must either use an ES5 shim or use version 0.2.5 of this module.

Wozu man uralte Browser (insbesondere IEs) überhaupt supporten will, sei mal dahingestellt.
 
Wozu man uralte Browser (insbesondere IEs) überhaupt supporten will, sei mal dahingestellt.
bisschen offtopic, aber ich finde die aussage genau andersrum richtig: WENN man noch einen "uralten" browser supporten muss/will/soll/..., dann doch den IE...
 
bisschen offtopic, aber..
Ich geben trotzdem meinen Senf dazu :-D

ich finde die aussage genau andersrum richtig: WENN man noch einen "uralten" browser supporten muss/will/soll/..., dann doch den IE...
Zunächst muss man es schaffen eine relevante Masse an "Legacy-Browser"-Nutzern auf seine Seite zu kriegen um den Entwicklungsaufwand überhaupt zu rechtfertigen. Die Lösung sieht doch ganz einfach aus: User-Agents loggen und regelmäßig auswerten. Sobald diese User mal die 1% Marke knacken kann man einen angenehmen Upgrade-Hinweis (ggf. mit Conditional-Comments) basteln.

Im Firmenumfeld sind die Browser die unterstützt werden müssen meist bekannt. Da baut man dann ganz gezielt Kompatibilitätsweichen für die entsprechenden Browser ein.
 
Hi.

Im Hauptbereich wird alles älter als IE11 gar nicht mehr unterstützt. Nur das Browsercheck Script unterstützt noch alte Browser, um ggfs noch einen Hinweis ausgeben zu können, darum der Login beim betreffenden Browser gesperrt/ausgeblendet ist.

Der Hash muss bei alten Browsern allerdings auch nicht wirklich sein da dort eh keine Session abzusichern ist. Ich muss den Feature Check und die Ausgabe der Fehlermeldung nur vor das sammeln und Hashen der Browserinfos stellen. Dann kann ich auch object-hash einsetzen.
 
@rckd
Lässt du dann die alten Browser einfach so drauf los, auch wenn man dann nur ein "Trümmerfeld" serviert bekommt?
 
@rckd
Lässt du dann die alten Browser einfach so drauf los, auch wenn man dann nur ein "Trümmerfeld" serviert bekommt?
Nein. Das kommt auf die Masse der User an, die dieses Trümmerfeld wirklich zu sehen bekommen. Wenn im Monat von 100.000 Besuchern nur 3 ein Trümmerfeld erhalten - ja, dann kümmert mich das nicht. Wenn es aber 3.000 User sind, dann wird natürlich etwas dagegen getan.

Mir ging es aber eher um den Grundgedanken, dass alte Browser so gut wie ausgestorben sind. Sich um diese Browser Gedanken zu machen, macht erst Sinn, wenn es tatsächlich notwendig wird. Bspw. wenn plötzlich 10% deiner User mit einem IE6 aufschlagen (was ich stark bezweifle) -- Stichwort: User-Agents-Analyse.

Ich bin was das angeht sehr pragmatisch und versuche ganz nach dem Pareto-Prinzip mit 20% Aufwand 80% der Anwendungsfälle abzudecken. Erst wenn es nichts wichtigeres zu tun gibt und ich den ganzen Tag Däumchen drehe, kümmere ich mich vielleicht um die insgesamt 11 IE6-User die in den letzten 4 Monaten unter's Rad gekommen sind.
 
Hi.
Eigentlich nutzt kaum jemand einen alten Browser. Wenn doch, dann sind das eben die Leute, die aus der Firma "mal reinschauen" wollen.
Der JS Teil des Spiels ist übrigens gar kein Problem. Da bricht das Script mit einem Fehler ab, wenns nicht passt und es passiert einfach gar nichts mehr weiter.
Wenn LET nicht supportet wird, passiert das schon in den ersten paar Zeilen.

Wirklich lästig ist nur das CSS. Weil genau das eigentlich die Darstellungsprobleme verursacht. Das Layout ist leider anfällig dafür, insich zusammen zu fallen.

Habs noch nicht wirklich 100% zuverlässig hinbekommen, dass ältere Browser auf dem 1-Spalten Mobillayout landen. Das ist nämlich deutlich robuster und hat auch ohne irgendwelche Anpassungen keine Probleme mit Zusammenfallen. Das Mobillayout kann man sogar mit Firefox 3 oder IE5 noch lesen. Auch wenns vielleicht nicht mehr schick aussieht, aber man kann wenigstens noch die Sachen wie z.B. FAQ und "Systemanforderungen" lesen.
 
Das Mobillayout kann man sogar mit Firefox 3 oder IE5 noch lesen. Auch wenns vielleicht nicht mehr schick aussieht, aber man kann wenigstens noch die Sachen wie z.B. FAQ und "Systemanforderungen" lesen.
Dein Einsatz in allen Ehren, aber der IE5 taucht in öffentlichen Nutzungsstatistiken gar nicht mehr auf und selbst der IE6 liegt bei einem Marktanteil von unter 0.5%. Es sind einfach irrelevante Browser. Vergiss sie.

https://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0
 
Naja, ich hab die nur rein zum testen probiert um zu schauen wie es aussieht. Und dabei halt festgestellt, dass das Mobillayout auch ohne Apassungen relativ robust ist, während das 3 Spalten Layout schon ab ie10 abwärts problematisch ist. Anfangs lief es sogar auf dem ie11 nicht richtig, weil da Flexbox leicht anders als im aktuellen Firefox oder Chrome ist.
Den IE11 kann man derzeit aber leider noch nicht ignorieren. Das dauert wahrscheinlich auch noch ne weile, weil es der letzte MS Browser unter dem immer noch recht beliebten Windows 7 ist.

Immerhin war das alles eine relativ gute Übung. In den echten Praxiseinsatz geht das meiste von dem, was ich derzeit mache, ohnehin nicht. Es geht in erster Linie darum, Erfahrung zu sammeln oder mögliche Lösungswege zu erkunden.

Als nächstes werde ich ohnehin ein komplett neues Layout machen. Das erste gefällt mir gar nicht mehr so recht. Und ich will vom klassischen "Holy Grail" Layout für den Desktop abkommen und ehr was moderneres bauen. Da wollte ich dann mal die sogenannte Mobile First Strategie versuchen bzw gar keine festen Breakpoints mehr nutzten sondern ein richtig fluides Layout machen.
 
Findest mobile First nicht so gut?
Gut, so gesehen braucht man eigentlich gar keine besondere Strategie. Man kann auch einfach versuchen, sich gedanklich vom "Holy Grail" Layout zu lösen. Die klassischen 3-Spalter Layouts sind ohnehin nicht mehr so modern.
Und stattdessen dann ein schlankes 1-Spalten Layout anstreben. Die machen weniger Probleme, brauchen kaum spezielle mobile oder Desktop Unterscheidungen und sind zudem gerade modern.
Eine "aside" Box, die bei breiten Bildschirmen von unten nach links wandert, wäre natürlich trotzdem machbar.
 
Findest mobile First nicht so gut?
Der Mobile-Share legt in den letzten Jahren rasant zu und wächst immer weiter. Mobile First ist also absolut ratsam - aber nicht als blinde Vorgehensweise, sondern als Mindset. Man stößt oftmals auf Probleme wenn man ein Layout erst im Nachhinein versucht in ein Mobile-Device zu quetschen. Wenn dir von Beginn an klar ist wie sich dein Layout auf verschiedenen Auflösungen darstellen soll, dann ist die Art der Umsetzung nur noch Geschmackssache. Ich persönlich stehe total auf Mobile First.

Und stattdessen dann ein schlankes 1-Spalten Layout anstreben. Die machen weniger Probleme, brauchen kaum spezielle mobile oder Desktop Unterscheidungen und sind zudem gerade modern.
Eine "aside" Box, die bei breiten Bildschirmen von unten nach links wandert, wäre natürlich trotzdem machbar.
Ganz so einfach ist es dann doch nicht :)
 
Zurück
Oben