Scripte Schützen

Ja, es gibt eine zuverlässige Methode. Sie ist gleichzeitig die einzige, die wirklich funktioniert.

Stelle keine Skripte ins Netz.

Wie darf ich das verstehen?

JavaScript wird im Browser verarbeitet, d.h. die Skripte werden in jedem Fall vollständig an den Benutzer übertragen, sonst würden sie nicht funktionieren.
Du kannst sie verschleiern, du kannst sie unlesbar machen, aber jeder, der sie haben will, wird sie bekommen.
Genaugenommen bekommen sie sogar Leute, die sie gar nicht dafür interessieren, weil eben jeder Browser sie vollständig bekommen muss.

Wenn du sie durch irgendeinen Obfuscator jagst, wird es schwerer, sie zu lesen und zu verstehen, aber das ist auch schon alles.

Da stimme ich Matthes zu,
Javascript wird übertragen, der Browser kann es lesen, der User auch.

Ein kleiner Trick:
generiere vor jede Funktion eine SessionVar oder so etwas ähnliches. Die Leute die zum kopieren kommen, kommen immer 2 mal. dann matchen die functionsnamen nicht mehr.

Alle variablen die nur in der Funktion gültig sind mit A B usw. umschreiben. Spätestens nach der 3.Funktion vergehts dem User da etwas zu verstehen.

Hallo Roman,

Obfuscation sollte man genau wie Komprimierung allerdings nicht persönlich vornehmen, es erschwert das Ãœberarbeiten des eigenen Codes.
Dafür gibt mittlerweile einige Tools, die das ziemlich gut hinbekommen. Die Originalversion sollte man aber behalten.

Hallo

Ich kann zwar nicht viel zur Lösung beitragen aber eine Frage hätte ich noch dazu.

Ist es denn nicht so das ich mit Javascript auch PHP einbinden kann und damit die Möglichkeit schaffen könnte ein PHP Skript häufiger aufzurufen und auf diesem Wege dann auch eine dynamische Seite erreichen kann.

Das ist doch das Prinzip dieser Ajax Technologie oder bin ich momentan auf einem total falschem Dampfer?

Gruß
Jörg

Ja, das trifft es schon ganz gut.

Es gibt die Möglichkeit, mit JavaScript einen Request abzuschicken und die Rückgabedaten zu verarbeiten. Bei WIkipedia wird das ganze gut erklärt: http://de.wikipedia.org/wiki/Ajax_(Programmierung)

Hallo Oskar,
danke für den Hinweis. Es gibt da grundsätzliche Ãœberlegungen.
1. Entwickelt wird local (da kann alles offen sein)
2. Getestet wird auf nem Testserver (da kann auch alles offen sein)
3. Produktion-Server da (hier sollte man die Bude vernageln und so kryptisch wie möglich/nötig machen).

Zum anderen halte ich die Versionierung für sinnvoll. So sind alle Entwicklungsstadien nachvollziehbar.

Soll heissen "nicht am Produktion Server coden".
Aus die Maus

--- Nachtrag für Jörg

xajaxproject.org/en/download/

Ja, da stimmen wir überein.

Ob man allerdings seinen JavaScript Code verschlüsseln muss, ist eine andere Frage. JS-Code ist selten so gut, dass ihn jeder kopieren und vermarkten will

Lol,

So denke ich auch. In der Regel sind die .js nicht größer als 20kb. Im Gegenzug dazu die PHP Projekte mit mehren MB.
Bei manchen Kleinigkeiten, lohnt es sich die JavasScripte ein wenig unleserlich zu machen.
Das hält die Hobby Hacker on the fly davon ab sich mit den .js Variablen auseinander zu setzen.