Coding verstecken

Coding verstecken

Re: Coding verstecken

migrationshansel hat geschrieben: Programmiere gerade an einem Tool herum, das Domäneninhalte umsetzen soll. Dafür brauche ich für eine bestimmte Funktionalität (Lizenzprüfung) Coding, welches im Debugger nicht sichtbar sein darf und das in diesem Zustand transportiert und beim Kunden eingespielt werden kann.

Ich hatte mal ein Stück Coding, ich glaube ZHIDE, mit welchem man das Coding für Programme die im Z- oder Y-Raum liegen, quasi "unsichtbar" machen konnte. Allerdings programmiere ich im Namensraum (/XXX/) und dort funktioniert der Codingschnipsel nicht.

Hat irgendjemand eine Source, mit dem man einen Report, besser ein Include, so verändern kann, das es zwar ausgeführt und transportiert wird, das Coding in der SE38/80 und im Debugger jedoch nicht sichtbar ist?

Ausserdem muss der ganze Prozess auch reversibel sein (damit ich den Quellcode auch auf unserem Entwicklungssystem wieder bearbeiten kann).

Ach ja, wenn jemand eine Möglichkeit kennt, eine Lizenzabfrage so zu gestalten, das diese vom Kunden nicht ausgehebelt werden kann, bin ich auch dafür dankbar.

Allerdings fällt mir dazu nichts rechtes ein, da alles was ich mir überlegt habe auch mit ABAP-Mitteln wieder ausgehebelt werden kann.

Und ja, ich weiss, das ich mir jetzt wieder anhören muss, das man Coding nicht versteckt

und ich ein schlechter Programmierer bin oder das es schlechter Stil ist und was weiss ich nicht noch alles. Ja, ihr habt recht (bis auf den schlechten Programmierer :P )

Aber mir fällt ausser dieser Möglichkeit keine andere ein, mit der ich ein lebenswichtiges Include vor Änderung schützen und in diesem auch noch die Lizenzprüfung unterbringen kann.

Ja, ich weiss auch, das es Vereinbarungen mit Kunden gibt aber jeder von euch, der mehr als nur ein halbes Jahr in dieser Branche tätig war, weiss, das, sobald man kein Zugriff mehr auf das Kundensystem hat, dieser damit tun und lassen kann, was er will

(und weiss auch von Fällen, wo genau das passiert ist. Leider kann ich es nicht beweisen, da ich keinen Zugriff mehr auf das System habe und auch nicht mehr bekommen werde).

Re: Coding verstecken

Frank Dittrich hat geschrieben:

migrationshansel hat geschrieben: Programmiere gerade an einem Tool herum, das Domäneninhalte umsetzen soll. Dafür brauche ich für eine bestimmte Funktionalität (Lizenzprüfung) Coding, welches im Debugger nicht sichtbar sein darf und das in diesem Zustand transportiert und beim Kunden eingespielt werden kann.

Und das Tool zum Umsetzen von Domäneninhalten (was auch immer Du da konkret "umsetzt", z.B. Feldinhalte in Tabellen, die mit Bezug auf die Domäne definiert sind) ist so toll, dass den Quelltext keiner sehen darf?

Hab ich das gesagt? Davon war nie die Rede. Hättest du genau gelesen, hättest du festgestellt, das es hier nicht um den Schutz vor "abgucken" sondern um das nicht umgehbare Abfragen eines Lizenzschlüssels geht (bzw. die Unbrauchbarmachung des Tools wenn jemand die Abfrage auskommentiert).

Und wer behebt dort die Bugs?
(Du willst noch mal kassieren? Du machst keine Fehler? Der Kunde kann ruhig warten, bis Du mal wieder Zeit hast?)

Danke für die Unterstellung. Die Wartung und Pflege für den Zeitraum der Lizenz bzw. des Projekte obliegt selbstverständlich mir oder unserem Unternehmen. Auch davon war in keinem meiner Posts die Rede.

Allerdings fällt mir dazu nichts rechtes ein, da alles was ich mir überlegt habe auch mit ABAP-Mitteln wieder ausgehebelt werden kann.

Eben. Auch wenn man nicht weiß, wie man den Quelltext-Schutz aufheben soll, kommentiert man eben die Lizenzabfrage aus.
(Oder Du musst allen Deinen Quelltext schützen.)

Da hätte ich schon eine Idee, wenn der Quelltext-Schutz funktionieren würde.Sonst hätte ich die Frage ja auch nicht gestellt.

Und ja, ich weiss, das ich mir jetzt wieder anhören muss, das man Coding nicht versteckt

Wenn Du das schon weißt, warum fragst Du dann?

Weil es, wie von dir, sowieso von irgendjemandem gekommen wäre.

Dass Du ZHIDE nicht sofort als einen Haufen Sondermüll erkannt hast, spricht jedenfalls nicht gerade für Dich. (Ein paar der Probleme sind Dir aber anscheinend aufgefallen, z. B. das mit den Includes/der Transportierbarkeit.
Das ist aber nur ein Bruchteil.)

Danke für die Blumen. Ich könnte dir auch noch ein paar nennen aber lassen wir das.

Aber mir fällt ausser dieser Möglichkeit keine andere ein, mit der ich ein lebenswichtiges Include vor Änderung schützen und in diesem auch noch die Lizenzprüfung unterbringen kann.

Es gibt auch keine brauchbare Möglichkeit.
Von wem Kommt denn die Anforderung.

Lies den dritten Post, dann weisst du es.

Ja, ich weiss auch, das es Vereinbarungen mit Kunden gibt aber jeder von euch, der mehr als nur ein halbes Jahr in dieser Branche tätig war, weiss, das, sobald man kein Zugriff mehr auf das Kundensystem hat, dieser damit tun und lassen kann, was er will

Manchmal musss er auch einfach Zugriff haben, um Fehler zu korrigieren.

Braucht er nicht, da der Kunde nur eine Projektlizenz erwirbt und er das Projekt eh nicht selber durchführt. Wenn er will, darf er das Tool gerne danach löschen (wenn es denn alle täten).

Und auch bei Deinem Programm kann ich mir die Notwendigkeit, Fehler beheben zu müssen, gut vorstellen.
Wenn Du nur die Tabelleninhalte für Felder anpasst, die sich auf die Domäne beziehen, ist ein Hauptproblem ja die Wiederaufsetzbarkeit.

Kein Problem

Insbesondere wenn der alte und neue Wertebereich sich überschneiden.
(Je nach SDOMA und Tabellen kann es auch noch um die Größe der Rollback Area, Sperren von Objekten, Änderungsbelege ... gehen.)

Kein Problem was die Grösse des Rollbacks bzw. das Sperren von Objekten und die Änderungsbelege betrifft. Überschneidungen des Wertebereiches sind eine Definitionssache des Kunden. Ich werde natürlich nicht Daten umsetzen, bei denen der Zielwert bereits vorhanden ist (wäre ja auch schwachsinnig). Sollte es dennoch zu Überschneidungen kommen (z.b. bei variablen Schlüsseln), so muss vorher zusammen mit dem Kunden festgelegt werden, wie in diesen Fällen verfahren werden soll.

Wenn Du aber auch noch Report-Varianten anpassen mussst, in denen Felder sich über DTEL auf die DOMA beziehen, komt man schnell in komplexere Abhängigkeiten, wo man durchaus Fehler machen kann.

Report-Varianten sind auch kein Problem. Erfordern zwar mehr Analyseaufwand aber auch das ist machbar.

Ebenso bei DDIC-Strukturen, die mit EXPORT ... TO DATABASE gesichert wurden.

Kein Problem solange der Kunde mir seine eigenen "Clustertabellen" und deren Aufbau mitteilt. Eine Umsetzung ist auch hier generisch möglich (Umsetzung von Tabellen wie PCL2, RFDT etc. ist schon mit der Standardauslieferung möglich).

(und weiss auch von Fällen, wo genau das passiert ist. Leider kann ich es nicht beweisen, da ich keinen Zugriff mehr auf das System habe und auch nicht mehr bekommen werde).

Ausserdem muss der ganze Prozess auch reversibel sein

Auch das ist mir klar. Aber ehrlich: welches kommerzielle Programm, d.h. gegen Geld erwerbbare Programm, hat keine Lizenzprüfung? Nenn mir nur ein einziges (Distributionen zählen nicht).

Aber wie gesagt, ich hab den Beweis nicht.