'Kodowanie' kodu PHP

[Maximus Marius]

z tego co widac w wynikach wyszukiwarki to konkurencje Ioncube ma, wiec nie wiem czy bedzei łatwo sie przebić

slawek22 - nie wiem czy działa bcompiler pod php5, jak potrzebujesz to sprawdz, projekt chyba dawno nie jest rozwijany ale jak komuś zależy i bedzie umiał to może sobie napisze coś na jego bazie, choc pewnie nie bedzie łatwo bo by każdy sobie sam napisał.

Co do pisania modułu to na c świat sie nie kończy , można napisać przecież moduł w czym tam sie umie co by nie strzelać po pamieci gdzie popadnie jak cżłowiek boi sie używać C, zreszta nie ma co popadać w paranoję, jak by tak sie człowiek bał tych bledów to by nie mogł używac PHP które tez jest napisane w C.

To czy ktoś zainstaluje nasz moduł to już inna para kaloszy, nie wszyscy robią "stronki" które mają działać na współdzielonym hostingu. Ja przytaczam rozwiązania nie dla wszystkich, co nie znaczy ze niektóre nie są bez wad , to już czytający musi decydować co wybiera.

Jakimś tam utrudnieniem może tez być eval(base64.... zależy co kto potrzebuje.

[slawek22]

Ogólnie to z tą konkurencją jest tak, że albo od lat nie rozwijana albo kiepska (tzn. dekoder nie w oddzielnym modułem).

slawek22 - nie wiem czy działa bcompiler pod php5, jak potrzebujesz to sprawdz, projekt chyba dawno nie jest rozwijany ale jak komuś zależy i bedzie umiał to może sobie napisze coś na jego bazie, choc pewnie nie bedzie łatwo bo by każdy sobie sam napisał.

Będzie ciężko - koszmarny kod. Tak tylko piszę że nie warto sobie zawracać głowy projektami, które "żywot" skończyły 3 lata temu.

Co do pisania modułu to na c świat sie nie kończy

Ogólnie może być ciężko napisać moduł do apache w czymś innym niż C. Nie wydaje mi się, żeby to w ogóle było możliwe (znaczy możliwe to wszystko jest, tak jak np. robienie hostingu WAMP na windows, tylko, że dobrze to działać nie będzie i większego sensu to nie ma).

zreszta nie ma co popadać w paranoję, jak by tak sie człowiek bał tych bledów to by nie mogł używac PHP które tez jest napisane w C.

Tylko, że jest pisane przez ludzi którzy się na tym znają (a nie przez gościa który chciałby napisać mega wypasiony moduł w tydzień a doświadczenia nie ma żadnego). Takie projekty są rozwijane LATAMI, ludzie łatają bugi, testują, wydają poprawki kompatybilne z kolejną wersją PHP... Wystarczy sobie prześledzić historię enkoderów, żeby zobaczyć ile z tym pracy.

To czy ktoś zainstaluje nasz moduł to już inna para kaloszy, nie wszyscy robią "stronki" które mają działać na współdzielonym hostingu.

Stworzyłeś moduł dekodera PHP do instalacji na serwerze jako natywne rozszerzenie PHP? Abstrahując już od błędów, problemów z bezpieczeństwem i padów serwera jakie to może wywołać to jeśli użytkownik takiego enkodera będzie musiał uaktualnić apache lub PHP to jeśli dekoder nie będzie dalej rozwijany to zostanie z ręką w nocniku. Albo zabugowana wersja PHP w któej wykryto lukę... albo straci możliwość uruchamiania kodu. Standardowy problem z DRM (pliki przestają działać, kiedy dostarczyciel certyfikatów / technologii dostępu bankrutuje).

Wiesz ja sam piszę w PHP, wcześniej pisałem w C. Problem z C jest taki, że trzeba dbać o szczegóły w PHP pisać może absolutnie każdy idiota. PHP to nie jest wolniejsza wersja C.

Eval może być utrudnieniem, tylko że to się ma do pisania prawdziwego enkodera tak jak przedszkole do studiów wyższych i nie ma nawet co pisać o tym w jednym poście... Z resztą czy ja piszę, że takie rozwiązanie jest złe. 100x lepsze niż próba pisania modułów apache/php - bo to zupełny idiotyzm i w warunkach domowych taki moduł któy nadawałby się na produkcję NIGDY nie powstanie.

[Inco]

Sławku drogi zgadam się z tobą że pisanie własnego modułu by zakodować jeden projekt( chyba ze bardzo duży i ze szczególnymi wymaganiami), nie ma żadnego sensu. Jednak chciałem ci przypomnieć że większość open sourcowych projektów miało swój początek, tak jak to nazwałeś, w warunkach domowych. Proponuję byś nie dyskredytował ludzi, którzy nie koniecznie pracują w ogromnych firmach, nie koniecznie zarabiają kupę kasy, a jednocześnie potrafią i tworzą oprogramowanie dobrej jakości, po prostu mają inne priorytety niż ty.

[Maximus Marius]

ja tam piszę moduły do php w delphi ale platforma tylko windows,

pewnie jakby sie uparł, a budżet był odpowiedni to dało by sie to i pod freepascal skapitulować jak by ktoś sie uparł na kompilacje pod linuxa

Czyli w skrócie da sie napisać nie tylko w C. Z tym że to dobrze działać nie bedzei to też bym polemizował , bo z punktu widzenia jądra php nie ma róznicy w czym jest skapilowany załadowowany moduł, działać będzie tak samo.

W sumie sam sie zastanawiam dlaczego nie ma bytecode w standardowym PHP, było by sympatycznie,

ktoś coś wie czy kiedyś bedzie w standardzie ?

[slawek22]

Jednak chciałem ci przypomnieć że większość open sourcowych projektów miało swój początek, tak jak to nazwałeś, w warunkach domowych.

Przecież tego nie neguję, jest wiele dobrych projektów które powstały w domowych warunkach. Ci którzy je tworzyli to ludzie wybitni, dopóki nie widzę niczego oprócz postu na forum (który w dodatku mówi jakie to jest wszystko, łatwe i proste, niemal do zrobienia od zaraz) - to będę raczej sceptyczny. Bo te projekty powstawały latami.

Po prostu odnoszę się do przydatności i możliwości stworzenia takiego czegoś w warunkach domowych dzisiaj przez "przeciętnego programistę". Nikomu bym nie polecił instalacji takiego modułu bez wsparcia jako części php czy apache. Czy to jest dyskredytacja? Możemy się czarować i stwierdzić, że każdy może przed obiadem napisać rewolucyjny moduł do apacza, po obiedzie wrzucić to na serwer i będzie super

Druga sprawa - to kiedy patrzę na praktycznie każdy projekt (nie tylko OS) widzę niekończącą się listę problemów, bugów i hacków które sprawiają że się to trzyma jakoś kupy i działa. Tutaj 0 problemów Nie mamy 500PLN na enkoder - to go napiszmy od zera Nie ma 300 na windows - zróbmy sobie system operacyjny - lekko, łatwo i przyjemnie Więc albo jesteśmy najgenialniejszym narodem świata, albo po prostu (skłaniam się ku tej opcji) to tylko takie gdybanie.

bo z punktu widzenia jądra php nie ma róznicy w czym jest skapilowany załadowowany moduł, działać będzie tak samo.

Co do modułów dla apache - na localhost/windows zawsze wszystko zadziała. Problemy są na produkcji. Od takiego modułu na windows napisanego w Delphi który dobrze działa na local są lata świetlne do czegoś co zadziała dobrze na "normalnym" serwerze.

[Mion]

Czy ja gdzieś w tym topicku napisałem, że jest to proste?

[kolryb29]

Może wtrącę 3 grosze

Sporo tu teorii, ale można zamiast pascala, delphi czy C wykorzystać język Java, który jest/może być modułem Apache. Do tego język na tyle bezpieczny, że nie będzie problemów z serwerem (a także administratorem).

Java w PHP jest łatwa do obsługi - www.php.net/java . Równie dobrze można skorzystać z mostów php-java (https://php-java-bridge.sourceforge.net/pjb/).

Nie twierdzę, że takie rozwiązanie jest najlepsze, ale ilu zainteresowanych - tyle metod na rozwiązanie zadania...

[slawek22]

@Mion: odniosłem takie wrażenie

Do tego język na tyle bezpieczny, że nie będzie problemów z serwerem

Tutaj akurat bezpieczeństwo języka niewiele ma do rzeczy. Będzie problem z szybkością i jestem pewien, że również z stabilnością działania. Testowałeś to kiedyś?

[kolryb29]

Panie Sławku - to tylko moje drobne 3 grosze Nie testowałem, pomysł zupełnie teoretyczny

[Maximus Marius]

slawek22 - w dziwny sposób podchodzisz do problemu, bo przy tak małej ilości informacji jakie podał inicjący wątek ocenić jakie rozwiązanie jest najlepsze. Czasami trzeba być otwartym na "śmiałe pomysły".

Tutaj taki mały wątek https://www.forum.optymalizacja.com/index.php?showtopic=65010

Który pokazuje jak szybki jest PHP, a popatrz sobie jak wysoko jest JAVA, czesc problemu przenosisz na jave i masz pewne korzyści

Inna sprawa że jest sporo problemów rozwiązanych za pomocą javy a jeszcze nikt nie napisał implementacji w php .

I teraz wyobraź sobie że ktoś chciałby abyś mu stworzył system do zbierania danych i analizy online do jakiegoś tam badania naukowego, "wykresy", "tabelki" i obliczenie FFT dla danych. Przecież byś sie nie upierał pisać tego wszystkiego w PHP, czyż nie ?

slawek22 - rozumiem Twoj sposób myslenia bardzo dobrze , jednak czasami można spojrzeć troszkę szerzej , a nie w tak wąski sposób jak Ty.

[slawek22]

Wiesz ja nie twierdzę, że nie powinno się używać innych języków - bo to dobry pomysł i pewnie wiele osób tak robi. Ale wrzucanie takiego "chałupniczego kodu" kiepskiej jakości w środowisko PHP/Apache to idiotyzm. Masz sygnały, pamięć dzieloną, potoki i wiele innych mechanizmów które możesz wykorzystać, szczególnie pod linuxem bo cały system jest napisany tak, żeby takie operacje ułatwić. I te mechanizmy dość dobrze izolują takie "eksperymenty" od reszty systemu.

Po prostu jestem zdania, że łatwo można wykorzystać potoki czy inne mechanizmy integracji bo to nic trudnego. Praktycznie każdy może to zrobić. Za to takie doczepianie modułu w javie czy pascalu czy nawet w C do PHP/apache moim zdaniem przerosłoby większość osób które mają certyfikat zenda (co dopiero osób które "robią stronki").

Nie lepiej zrobić proste popen, niż wszystko rekompilować, zmieniać ustawienia apache / PHP i modlić się żeby to wszystko razem się nie pogryzło? Wiesz jak ci się wysypie oddzielna aplikacja w C/javie czy czymkolwiek to pewien mały fragment skryptu przestanie działać. Jak ten sam kod podczepisz do PHP/apache to cały serwer padnie albo będziesz miał włamanie. Jak zrobisz update środowiska to moduł może przestać działać a i tak pewnie nigdy dobrze działać nie będzie (szczególnie w modelu MPM czy na procesorach wielordzeniowych). Napisanie poprawnego modułu do P/A który się nadaje na produkcję to nie jest praca dla pojedynczej osoby.

[stat4seo]

Miło się czyta dyskusję mądrych ludzi :-)

pozdrawiam

[General_Depet]

Miło się czyta dyskusję mądrych ludzi :-)

Tylko że z tych mądrości dalej nic nie wynika albo inaczej... wynika że jednym realnym rozwiązaniem na zakodowanie PHPa jest ioncube.

[Maximus Marius]

wynika że jednym realnym rozwiązaniem na zakodowanie PHPa jest ioncube.

TAK

[slawek22]

Tylko że z tych mądrości dalej nic nie wynika albo inaczej... wynika że jednym realnym rozwiązaniem na zakodowanie PHPa jest ioncube.

Dokładnie. Albo jeszcze eval - ale to nie jest prawdziwe kodowanie (tzn. każdy po dwudniowym kursie PHP mógłby to obejść ). Można jeszcze zakodować pojedynczy duży plik (żeby nie było dostępu do funkcjonalności), plus że taniej wyjdzie a skrypt będzie można modyfikować.

Swoją drogą koszty licencji na ioncube w porównaniu z kosztami które trzeba ponieść żeby takie coś stworzyć to na prawdę grosze...