Witam

Stworzyłem bibliotekę (pojedyncza klasa) zakodowana IonCube online.
W konstruktorze mam wlasną procedurę "sprawdzającą licencję użytkownika".

Reszta projektu nie jest zakodowana. Aby uniknać ze ktoś poprzez extends nadpisze konstruktor i wyłączy sprawdzanie licencji
mam dwa wyjścia:

1. dac final na moim konstruktorze
2. przenieść weryfikację licencji do głównej metody biblioteki.

Jakie rozwiazanie jest bardziej eleganckie? Teoretycznie w jednej instancji obiektu główną metodę można wywołać wiele razy
więć chyba nie ma sensu, aby za kazdym razem licencję sparwdzać (co troszke trwa) i zrobić to raz w konstruktorze?


Czyżby nikt nie wiedział, czy też moje pytanie było mało sensowne?

Bardzo proszę o cenne wskazówki

Obiekt można utworzyć bez wywołania konstruktora, a inne operacje niezwiązane ze sprawdzaniem licencji, które mogą się w nim znaleźć najprawdopodobniej dałoby się odwzorować przy pomocy mechanizmu refleksji. IIRC ionCube udostępnia jakieś narzędzia związane z licencjonowaniem, raczej z nich powinieneś skorzystać.

PS. Kod zaszyfrowany ionCubem o ile dobrze pamiętam da się rozkodować do całkiem przystępnej postaci. Może lepiej zainteresuj się jakimś rozwiązaniem opartym o architekturę SaaS?

Dziękuję za odpowiedź.

Słyszałem, że IONCube jest dość podatny na rozkodowanie, ale jak ktoś się już za to weźmie to znaczy, że jawnie i z "premedytacją" chce
złamać licencje biblioteki.
Tak więc chyba warto zakodować nawet niedoskonałym narzędziem niż zostawić w plain text gdzie ktoś "przez przypadek" mógłby złamać licencję.
Pozostawiam już kwestię czy w ogóle jest sens chronić moją bibliotekę

SaaS w tym przypadku odpada i nie chciałbym korzystać z licencjonowania IONCube tylko z własnych metod.

Reasumując
Jak rozumiem warto sprawdzanie licencji dodać w głównej metodzie (bez której biblioteka nie ma sensu), niż w konstruktorze
nawet z "final" bo nawet taki konstruktor się da ominąć przy tworzeniu obiektu?

Według mnie tracisz jedynie czas i co gorsza, tworzysz sobie fałszywe poczucie bezpieczeństwa. Wrzucenie zakodowanego fragmentu sprawdzającego licencję oraz ewentualnie wykonującego jakieś inne operacje będzie bardzo łatwe do ominięcia. Wszelkie "modyfikatory" OOP (pola/metody/klasy prywatne, finalne itp.) służą jedynie wygodzie programistów, nie stanowią żadnego zabezpieczenia.

Od lat firmy starają się tworzyć wymyślne zabezpieczenia swoich produktów, a jaki jest rezultat ich zmagań każdy wie. Jeżeli jednak faktycznie chcesz się jakoś zabezpieczyć (czy raczej utrudnić przechwycenie kodu) skorzystaj z rozbudowanych narzędzi firm, które się w tym specjalizują.