Skrytí zdrojového kódu
Školení, která pořádám
Jeden čtenář se mě zeptal, jestli jde před klientem ukrýt zdrojový kód PHP skriptů. Pokud pominu možnost aplikaci hostovat na svém stroji, vím o několika možnostech:
- BCompiler
- PECL rozšíření Bytecode compiler se dostalo už i do PHP manuálu, kde se o něm dozvíte vše potřebné.
- Zend Encoder
- Komerční nástroj firmy Zend.
- PHP Encoder
- Komerční nástroj firmy ionCube.
- eAccelerator
- Nástroj vyvíjený jako optimalizátor umožňuje i zpracování zakódovaných souborů.
Ani jeden způsob kód nešifruje, ale tím, že ukládá zkompilovaný kód, přesnou rekonstrukci zdrojového kódu fakticky znemožňuje. Jak se rozšíření BCompiler používá?
<?php
$fp = fopen("test_bc.php", "wb");
bcompiler_write_header($fp);
bcompiler_write_file($fp, "test.php");
bcompiler_write_footer($fp);
fclose($fp);
?>
Kód vytvoří soubor test_bc.php
, který lze následně standardně vložit do jiných souborů nebo přímo zobrazit v prohlížeči – samozřejmě pouze za předpokladu, že je rozšíření BCompiler k dispozici.
Osobně skrytí zdrojového kódu asi těžko někdy využiji – samotný zdrojový kód podle mě velkou hodnotu nemá a představa, že by ho někdo vzal a bez znalosti myšlenek v kódu skrytých ho třeba dál prodával, mi přijde skoro až úsměvná.
Diskuse
BCompiler je velmi šikovné rozšíření PHP, určitě stojí za pozornost. Vedle toho Zend Encoder je pro běžné smrtelníky docelá drahá sranda.
Jinak ten poslední odstaveček byl myšlen ironicky? ;)
Miloslav Ponkrác:
Ten poslední odstavec se asi trochu mýlí. PHP je ve své podstatě velmi jednoduchý jazyk, ve kterém se právě skryté myšlenky ukryté v kódu hledají podstatně snáze, než v mnoha jiných programovacích jazycích.
Řeknu to tak, pokud vaše projekty a vaše zdrojové kódy za mnoho nestojí pane Vráno, pak se o ně opravdu nemusíte obávat a nikoho zajímat nebudou. Pokud ovšem uděláte něco špičkového, pak je velmi snadná cesta vzít vaše zdrojové kódy, trochu se jimi probrat, pochopit vaše myšlenky a vaše postupy, trochu je vylepšit a použít pro své účely, třeba pro business. Pochopit cizí projekt v PHP a myšlenky autora v něm je v podstatě směšně jednoduché oproti tomu, když třeba děláte reverse enginnering programu ve strojovém kódu.
Myslím, že jste ještě dost nezkušený idealista. Sám jsem před několika lety dělal na zakázku PHP projekt, ze kterého mi byly ukradena část zdrojových kódů. Konkurence je velmi dobře využila a zabudovala do svých projektů a vysloveně jsem poznával svoje myšlenky na cizím webu.
Tomas Pokorny:
jak souvisi zdrojovy kod s poznanim svych myslenek na cizim webu? To ze se mi libi urcity zpusob navigace ci jine casti ciziho webu neznamena, ze musim ukrast jeho zdrojovy kod. Proste si to tak na svem webu naprogramuji. Vy by jste mel byt rad, ze jste vymyslel neco smysluplneho. A to ze se vam to nelibi, ze to tak nekdo udela, je jako dat si patent na to, ze se chlapum pohodlneji cura ve stoje. Na svuj kod mate samozrejme pravo a pokud Vam jej nekdo bez dovoleni zneuzije, je to zlodejina, s tim s Vami souhlasim. Taky s Vami souhlasim, ze dobry pocit z open-source Vas nenakrmi, ale je rozdil mezi tim prodat svou praci a inspirovat nekoho vysledkem sve parce.
Na konec jenom malou pripominku k Vasemu nazoru, ze pan Vrána je nezkuseny idealista. Nemel by jste takhle nekoho urazet (me by to urazelo). Hlavne pokud absolutne nevite co vse uz v zivote mohl dokazat. A o jeho zkusenosti v oblasti PHP vypovida mimo jine tento web.
Miloslav Ponkrác:
Jak souvisí zdrojový kód s poznáváním svých myšlenek na cizím webu? Jednoduše, zaručuji Vám, že pokud někdo cizí použije řadu PHP modulů z Vašeho kódu na cizím webu, aniž by se jej obtěžoval změnit, že to celkem snadno poznáte. Od stejných názvů PHP skriptů přes stejné parametry PHP skriptů, pak na tom cizím webu jsou čistě náhodou naprosto stejné chyby jako ve Vašem kódu až po desítky dalších drobností, které ukradení cizího kódu usvědčují. Nevím jak Vy, ale já tohle opravdu nenazývám inspirací.
Co se týká mého nazvání pana Vrány nezkušeným idealistou, nemyslím, že by v tom bylo něco urážlivého. Mě osobně by to určitě neuráželo, považuji to za celkem neutrální. Upřímně řečeno, kdybych napsal něco podobného jako poslední odstavec ve článku pana Vrány, očekával bych automaticky kritiku a to bez ohledu na to, co bych v životě dokázal a bez ohledu na to, jaké jsou moje zkušenosti ohledně PHP.
Jinak považuji od Vás za velice neslušné, jak jste mě, sice nenápadně a diplomaticky, ale přece jen obvinil na základě pouhé kritiky autorova názoru na cenu zdrojových kódu z toho že znevažuji to, co snad mohl pan Vrána v životě dokázat, a že snad znevažuji jeho zkušenosti v PHP. A věřte, že se najdou lidé, kteří by se za takové obvinění mohli urazit.
Jirka Táborský:
Moje mělenky na cizím webu? K tomu snad stačí si stránku přečíst. Nebo si chcete patentovat sekvence kódu? No, na tom snad php založeno není, ne? Stejně, pokud někdo zcizí jeden skript, u internetového obchodu mu bude k ničemu. Navíc, bez znalosti funkcí celého systému je zloději k ničemu i celý web.
Jak je to s rychlosti a narocnosti vykonavani tohoto byte codu?
Michal Hantl:
Taky mě to zajímalo.. Jestli mě moje angličtina neklame, tenhle text se k otázce vyjadřuje (z PHP manuálu):
bcompiler can improve performance by about 30% when used with uncompressed bytecodes only. But keep in mind that uncompressed bytecode can be up to 5 times larger than the original source code. Using bytecode compression can save your space, but decompression requires much more time than parsing a source. bcompiler also does not do any bytecode optimization, this could be added in the future...
30% není špatné číslo, ale jde to úsporu 30% času stráveného přežvykováním PHP kódu, nebo 30% času stráveného vygenerováním stránky? Možná spíš to druhé, přesto je to zajímavé pro některé druhy použití.
Marcel Simonides:
Vážený pane Vráno, naprosto nesouhlasím s Vaším posledním odstavcem. Pokud vyvíjím léta ve firmě redakční systém, v žádném případě ho nedám klientovi k dispozici, neboť:
1)
zrovna na to se těší majitelův syn/známý/správce sítě/apod., který se mi v tom bude nadále vrtat
2)
začínajících programátorů/webdesignerů co se naučili HTML + základy PHP ve škole a chtějí něco začít dělat pro zákazníky jsou tisíce. Nemají však znalosti, čas, peníze na vývoj redakčního systému. Je rozhodně mnohokrát jednodušší "si něco vypůjčit", pochopit jak to autor myslel, trochu předělat a dále používat, než něco vyvíjet. Ve vývoji jsou totiž tisíce hodin práce, omylů apod.
3)
jakmile se někdo jiný začne "vrtat" v kódu, většinou to dopadne tak, že to rozhodí a nechodí to. Zákazník pak chce uplatňovat reklamaci. Samozřejmě vůbec neřekne, že se v tom někdo vrtal. Zjištění, v čem to je, to jsou další hodiny a hodiny navíc, přičemž tyto hodiny odmítají zaplatit
4)
vývoj redakčního systému, to jsou statisíce. Klient si pak kupuje licenci na neomezené používání. Kdyby si měl koupit zdrojové kódy, rozhodně ho stránky nebudou stát desetitisíce, ale statisíce. To by asi ale zaplatit již nechtěl...
K tomuto poznání mě vedou zkušenosti z více jak 250 projektů.
Marcel Simonides:
Ve firmě používáme ionCube PHP Encoder. Pro server je zdarma, program si kupuje ten co skripty kóduje. Cena je přijatelná. Adresa je
http://www.ioncube.comCena Zend Encoderu je IMHO mimo mísu...
Jakub Vrána :
Nejsem idealista, pouze mám blíž k myšlenkám open-source. Jsem proti softwarovým patentům a rád se s ostatními podělím o myšlenky v kódu ukryté. Za práci na PHP dokumentaci nic nedostávám, za tento weblog ostatně taky ne, většina mých zdrojáků je volně k dispozici (pokud nejsou určeny pro odběratele, pak s nimi nakládá on). Přesto se psaním v PHP živím.
Je to prostě jiná filozofie - PHP je také open-source, přesto se jeho autorům špatně nedaří. Na určité úrovni se zkrátka vyplatí psát closed-source, na jiné open-source a na jiné na tom nezáleží.
passofur:
Musim se Vas zastat. Take vse co napisu (neni to jen PHP, ale i ruzny sw co jsem treba delal do soutezi, nebo pro skolu atd.) jsem vzdy uvolnil, pokud s tim dany subjekt (pro ktereho to bylo) souhlasil. Podle me je hloupost myslenky tutlat! Stejne nemuzete nic vymyslet tak, aniz by to nekdo nevymyslel o rad lepe.
dgx:
Rozhodně vás nechci urazit, mám jen z vašeho komentáře pocit, že dosud jste psal velmi malé nebo samoúčelné (soutěžní, školní) projekty, které stejně nelze obchodně využít. Tudíž zveřejněním zdrojových kódů není nijak 'odvážný' krok.
A co v případě, že byste byl majitel softwarové firmy a dokončil několikaletý vývoj aplikace v hodnotě milionu dolarů - také byste zahájil obchodování zveřejněním zdrojových kódů? A v případě, že ne, nazýval byste své konání 'TUTLÁNÍM'?
Marcel Simonides:
.....do soutěží, pro školu.....
Jestli odhaduji správně:
jste student, nemáte kancelář (pracujete ve škole, nebo doma u rodičů), nemáte zaměstnance (neplatíte všechny ty benefity s tím spojené), neplatíte účetní firmu, elektřinu atd. atd. Prostě každý měsíc nemusíte přemýšlet, kde vezmete na výplaty, na nájmy a jiné věci. A věřte mi, ono to nikoho nezajímá, jestli na to je, nebo není.
Zkuste si ale založit firmu, zaměstnejte programátory. Začněte si budovat nějakou jistotu. Myslím že myšlenky open-source Vás časem přejdou. Pokud ne, budu velmi rád, když se za cca 5 let fungování firmy ozvete a předáte mi své zkušenosti. Mé zkušenosti říkají, že tato cesta v dlouhodobém horizontu nefunguje, viz můj předchozí příspěvek.
Naopak ale chápu studenty, či čerstvé absolventy, kteří se chtějí zviditelnit a očekávají, že je nějaká firma poté zaměstná. Předpokládám ale, že ona firma již open-source vyvíjet nebude.
Neberte to prosím jako útok, chápu i Vaše stanoviska.
passofur:
mate pravdu oba dva, jsem student, bydlim na kolejich, vydelavam si prilezitostne psanim webu, programu (pro mensi firmy nebo zivnostniky, protoze velke firmy si pochopitelne objednaji u velke firmy schopne zajistit podporu atd.). Nezamestnavam lidi atd.
Na druhou stranu. Vyuzivam produkty opensource. Jsem za ne vdecny. Proto at napisu cokoliv, dam kod volne k dispozici. Mne je k nicemu. Ale chapu podnikatele, ze se o dusevni vlastnictvi sebe nebo svych zamestnancu boji. Nicmene nepovazuju ze zverejneni meho kodu je odvazny cin, ale proc ne, me na nich nezalezi. Svuj nazor ale nikomu nevnucuji.
btw. moc velkych projektu jsem nenapsal. Ovsem velky projekt zacina nekde kolem 50 000 radku kodu. Nejvetsi co jsem kdy napsal (demon + windows klient) melo kolem 10 000 radku kodu. Samozrejme jestli se dostanu do pracovniho procesu jako programator, budu respektovat prani firmy. Ale v opensource verim uz tak dlouho, ze me to asi jen tak neprejde. Konec koncu kvalita neni zavisla na utajeni kodu, nebo ano?
No, rekl jsem svoje. Nechci uz odvadet diskuzi od puvodniho tematu.
Jakub Podhorský:
imho občas kvalita taky není závislá na otevřenosti kódu :)
Miloslav Ponkrác:
Myšlenka open source je pěkná, ale pokud děláte projekt, do kterého jste nacpal jenom na výoji třeba milióny korun, tak se budete chovat jinak. Dokud děláte na malých projektech za pár korun, tak si můžete dovolit být stoprocentní zastánce open source vždy a všude.
Mimochodem, právě přílišná otevřenost zdrojových kódů PHP je důvod, proč v současné době hledám jiný programovací jazyk na práci na serverové straně webového serveru. Dost často jsem to dělal tak, že jsem prostě kritické části napsal jako CGI v jazyce C++.
A že si autoři PHP nežijí špatně? No jenom proto, že s prominutím zkriplili PHP. Každý skriptovací jazyk co znám, ať už jde o Perl/Python, nebo jakýkoli jiný jazyk použitelný na serverové straně webového serveru obsahuje: a) kompilaci do binárního kódu, b) debugger, c) často i profiler. Autoři PHP záměrně z PHP tyto věci uřízli. V PHP verze 3 tyto možnosti byly a nebylo nutné používat žádný BCompiler, ani jiné s prominutím náhražky typu z nouze ctnost, ale přímo php umělo přes parametr příkazové řádky zkompilovat do binárního kódu a PHP to umělo používat. Když začali dělat PHP verze 4, tak si autoři uvědomili, že by rádi na PHP něco vydělali a možnosti binárního kódu uřizli, stejně tak jako debuggování. Namísto toho nechali v PHP jenom určité API, aby se toho dalo dosáhnout externími nástroji. Na absenci těchto základních věcí v PHP si pak autoři udělali svůj kšeft. Evidentně autoři PHP nejsem stoprocentním zastáncem open source kódu. Už jenom to mě podněcuje k hledání jiného jazyka, než PHP pro psaní kódů na serverové straně.
Jakub Vrána :
Díky za rozšíření obzorů. O síťovém debuggeru v PHP 3 jsem věděl a jeho absenci díky volně dostupným, těsněji integrovaným debuggerům nepovažuji za zásadní. O přepínači -p vytvářejícím zkompilovaný soubor jsem nicméně nevěděl. Vypadá to, že by se něco podobného mohlo v PHP 6 vrátit.
O pohnutkách vyjmutí těchto vlastností z PHP 4 nic nevím, ale vzhledem k tomu, že PHP 4 má úplně jiné jádro, tak bych řekl, že klidně jenom mohlo být moc krkolomné to tam udělat a později bylo jednodušší to udělat samostatně.
Vývojáři PHP jsem neměl na mysli jenom lidi ze Zendu, ale třeba i Rasmuse, Iliu a další, kteří jsou placeni převážně za to, že tomu perfektně rozumí.
Miloslav Ponkrác:
"O pohnutkách vyjmutí těchto vlastností z PHP 4 nic >nevím, ale vzhledem k tomu, že PHP 4 má úplně jiné >jádro, tak bych řekl, že klidně jenom mohlo být moc >krkolomné to tam udělat a později bylo jednodušší >to udělat samostatně."
Dovolte tedy, abych ještě trochu doplnil Vaše znalosti. Nevím, proč by mělo být krokolomné to tam dodělat. Ono je to ještě trochu jinak a možná vás to překvapí. Ono to tam totiž dodělané je, a to jak v PHP 4, tak i v PHP 5! Každý spouštěný PHP skript se totiž nejdříve celý přeloží do binárního kódu a až ten je vykonáván. Jinak řečeno, celé vytváření binárního kódu je už zabudované do PHP, pouze je zablokováno nahrátí binárního kódu do souboru. Vy mi pořád nevěříte, když Vám píšu, že prostě si z toho autoři udělali kšeft.
Postupně docházím k závěru, že díky podobným a jiným zásahům je v podstatě PHP jeden z nejhůře vybavených skriptovacích jazyků, co znám. I toto je pro mě motivace snažit se dělat v něčem jiném.
Jakub Vrána :
Já samozřejmě vím, že PHP skripty jsou překládány do mezikódu, v článku je na vysvětlující prezentaci dokonce odkaz. Ale před tím, než něco odsoudím, mám ve zvyku si prověřit fakta. Vzhledem k tomu, že ani vy ani já nevíme, jak to tehdy přesně bylo, je unáhlené vynášet jakékoliv soudy. Výstup kompilace mohl být znepřístupněn z mnoha různých důvodů, z nichž jeden je i ten, že si z toho Andi a Zeev chtěli udělat kšeft. Z toho, jaký mám dojem z vývojářů PHP, se mi zdá spíše nepravděpodobný.
Jakub Podhorský:
jen se chci zeptat: je zkompilovaný do mezikódu nebo do strojového kódu? :)
Jakub Vrána :
Do mezikódu, který se následně interpretuje. Kam mé znalosti sahají, je to podobné jako byte-code v Javě.
Jakub Podhorský:
jasně díky, jen...není to trochu zbytečné? pochopil bych kdyby do strojového kódu ale do mezikódu se mi zdá na způsob smarty....z šablonový syntaxe dělám PHP syntaxi(v podstatě zbytečnost :)...i když jsem zastánce šablon ale tohle mi tak trochu přijde)
Miloslav Ponkrác:
Ne, rozhodně to není zbytečné. Překlad do mezikódu používá obrovská řada interpretovaných jazyků (namátkou Perl, Python, Java, jazyky rodiny .NET, ...) a dělá se to proto, že interpretace mezikódu je mnohonásobně rychlejší, než interpretace původního zdrojového kódu.
Existují dokonce odvážné teorie, které tvrdí, že při vhodném způsobu interpretace mezikódu zejména s použitím technologie JIT (just in time) lze dosáhnout rychlosti srovnatelné se strojovým kódem. A jak zkušenosti ukazují, tak se to občas i skoro podaří (viz Java, nebo .NET).
To samozřejmě není případ PHP. PHP mezikód se interpretuje značně pomaleji, než strojový kód. Nicmémě i v PHP přispívá překlad do mezikódu ke značnému zvýšení rychlosti běhu PHP skriptů.
Bohužel, jak je u PHP ve všem zvykem, je PHP značně pozadu za jinými jazyky a to platí i u práce s mezikódem. Předpokládám, že PHP tak ve verzi 6, nebo 7 se konečně dostane na úroveň, kdy budou možnosti práce s mezikódem srovnatelné s tím, co jiné interpretované jazyky nabízejí hned od počátku.
PHP dost hledá. Takže v PHP 3 se generoval mezikód průběžně s tím, jak se prováděl PHP skript. Pak PHP ve verzi 4 objevil Ameriku s tím, že konečně udělal to, co je normální všude jinde, a to, že nejdříve přeložil celý skript do mezikódu a pak teprve jej začal provádět. Tato změna je hlavní příčinou zrychlení běhu PHP od verze 4.
Jakub Podhorský:
přiznávám se že při psaní toho komentáře mně v tu chvíli nedošli všechny jeho výhody(jedinou kterou jsem si v tu chvíli uvědomil je možnost používání více jazyků které se nakonec do tohoto jazyku přeloží viz .NET) urychlení jsem si ale bohužel neuvědomil
každopádně děkuji za rozšíření obzorů
Steve :
Open source a urkast cizi SW je neco dost rozdilneho jase rad podelim o myslenky:) ovsem nemam prostredky abych se soudil ikdyz vim ze SW mi byl odcizen. Kdo nevedl soud o tomto tematu v CR nevi o cem to vubec je. Po kratkem case zjistite ze to nema cenu a akorat jste cast zisku hodil do kanalu - u nas nazyvany soud. Zend encoder je podle me dobra volba a nabizi small business programy, ale moznosti je vice kazdopadne kazdemu doporucuji minimalne se nad problemem zamyslet.
PS v diskusi sem narazil na vrtani se v kodu od zakazniku to je jednoduche u nas takovy source pri reklamaci porovname a kdyz jsou rozdili zakaznikovi vse osvetlime ;).
juno:
máte tušení, jak zkompilovat PHP do EXE?
llook:
Zkompilovat nevím. Ale je tu možnost vytvořit exáč, který obsahuje skripty i interpretr: http://www.priadoblender.com/
Žádná ochrana to není, vytahat z toho ty zdrojáky je strašně snadný, ale může se to hodit pro PHP-GTK věci.
Možná by to mohlo jít zkombinovat s tím bytecode compilerem. Nikdy jsem to nepotřeboval, takže jsem to ani moc nezkoumal.
juno:
díky moc, podívám se na to...
spaze:
Co se týká Zend Encoderu, tak tojeono.cz (dobrovolně se přiznám, že v tom mám prsty ;) nabízí přístup k ZE za příplatek http://www.tojeono.cz/zeptejte-se.php?cat=10#a19 . Použití je jasné, chceme kód uchránit před zraky klienta, což je asi ten nejčastější případ. Sry za selfpromo.
Jinak doplnění, Zend SafeGuard Suite nabízí i podporu pro "Limit usage by Host ID", pro omezenou dobu běhu apod.
K již zmíněnému ionCube PHP Encoderu přidám eAccelerator (nástupce Turck MMCache), zkušenosti však nemám.
K ceně ZE, smallbiz program ATM "Starting at $395".
Jakub Vrána :
Díky za upozornění, doplnil jsem to do přehledu.
Petr:
Mám bohužel již nějaký ten pátek pocit, že Turck zamrzl ve vývoji.
Jakub Vrána :
Jak už psal Spaze, nástupcem MMcache je eAccelerator.
Tim:
Uz to tu bylo receno nekolikrat, ze jit vzdy cestou open-source nebyva to nejlepsi reseni. Modelovy pripad - pres dva roky vyrabim redakcni system, misty to jde dobre, jinde se s tim peru, nektere veci postupem casu od zakladu prekopavam. Vyleze z toho celkem funkcni projekt, ktery delam z vlastni iniciativy pro sve kamarady zadarmo. Nemam s tim problem. Horsi ovsem bylo, kdyz na server mel pristup kazdy jouda, heslo se nekontrolovatelne a bez naseho vedomi rozsirilo za ucelem nahravani fotek. Bohuzel na hostingu neslo ochranit slozky s vykonnymi skripty. A tak jsem jednou narazil na svoji navstevni knihu, za kterou byl do nebes chvaleny nekdo jiny, podruhe radobykamarad pouze pozmenil barvicky a vizualni usporadani na mem systemu a zacal ho komercne sirit pod svym jmenem. Zmenili jsme tedy hosting a pristup ke skriptum zablokovali. Jake ale bylo me rozcarovani, kdyz muj kolega, ktery ma na starosti pouze odstranovat preklepy ve strankach (tudiz ma pristup ke skriptum) a vetsi chyby hlasit, pouzil muj system na svou ciste komercni prezentaci aniz by cokoli dopredu rekl. Az zpetne se zeptal, jak to mam v tom systemu udelane, ze mu tam neco nejde "znasilnit" podle jeho predstav. Zakryptovani kodu je tedy jedine vychodisko k nezneuziti free projektu.
Neco jineho je, kdyz delam za penize pro zakaznika. Da penize, dostane kod a at si s nim dela co chce.
Michaels:
Zend nabizi v ramci Zend Small Buisness Program svuj Encoder za $246, coz zase neni tak moc, pokud vam to vydelava, a podminkou je rocni obrat firmy do $250000.
dgx:
nemýlím-li se, jde o roční poplatek
magelan:
Bohužel tohle všechno je nastavený buď na lidi, co mají výše uvedený obrat $250000 nebo výše, a nebo na open_source, který to nepotřebuje. Nikdo v tomhle všem nemyslel na možnost, že by někdo kromě open_source chtěl vytvářet sice komerční, ale levné skripty. (třeba něco za $50 například) Což je třeba můj případ. Než si na nějaký "compiler" vydělám tak dávno bude můj kod volně běhat po netu, a já z něj budu mít houby. Zřejmě neřešitelná situace.
Bohužel, kradou se i levná řešení.
Jakub Vrána :
V textu jsou odkazy na dva nekomerční nástroje, které by podle mého názoru běžným potřebám měly dostačovat.
magelan:
Netušíte někdo, kde je (třeba) první z uváděných možností (BCompiler) k dispozici? Nebo alespoň jak moc je to běžné, že hostingy mají tuto knihovnu/rozšíření povolenu? Zkusil jsem to najít v phpinfo() nějakých hostingů, ale nenašel... Pokud to má jeden ze sta hostingů, tak je to z praktických důvodů k ničemu.
llook:
Zatím jsem to nijak víc nezkoumal, ale pokud s tím nejsou žádné bezpečnostní problémy, tak by snad pro slušného komerčního webhostera neměl být problém na požádání toto rozšíření přiinstalovat.
JoinT:
Než si vyděláte je možné řešení viz. příspěvek od Spazeho.
Jan HejTi Šedo:
V každém programu je chyba. Základní programátorská poučka.
I když je program testován, kontrolován více lidmi, je možné, že někde je chyba, která by někomu mohla pomoci se do systému nabourat (třeba i jen částečně). Je možné že chybu ani neudělal programátor při psaní PHP kódu - je třeba přímo v PHP - kdo ví, že tato funkce je použita tam a tam, může ji snadno zneužít.
I zde tedy vidím další výhodu kompilovaného kódu (či jakýmkoli jiným způsobem chráněný kód). Je asi dobré dodat, že třeba linux je díky přesnému opaku bezpečnější, což je ale díky jeho popularitě (a dalším okolnostem), kterou jen tak nějaký program nemá.
radim:
Téměř se nevyskytly příspěvky pro podporu Jakubových slov posledního odstavce. Reakce byly až zlostné, že si někdo dovolí názory, beroucí lidem peníze. Dokonce je Jakub vykreslován jako nýmand, včera spadlý z datle a navíc, chtíce hlásat programátorskou morálku.
Argumenty jsou k tomu víc než pádné, mzdy, kanceláře a přiznejme i drahá autíčka, no proč si nedopřát. A na to je třeba vydělat a jedině tak, že skryji kód. Pánové to je Vaše volba, k tomu Vás nikdo nenutil, klidně to můžete ihned zabalit a máte po starostech. Doporučuji ke zkoumání pojem PARADIGMA. Doba skrytých kódů je definitivně za námi. Argumentovat milionovou investicí do redakčního systému, když je jich k použití pod GPL víc než stovka, je přinejmenším zcestné. Ano, dá se vydělat na úpravě dle přání zákazníka, jak to dělají mnozí, nejznáměji snad stará dobrá WELLDONKA.
Asi Vám uniklo, že samotný program (kód) je vcelku bezcenná věc, daleko významnější jsou data (texty, články, historie, atd.). Program pouze a jenom ona data vhodně ukládá a zobrazuje a to přívětivějším, nebo komplikovanějším způsobem. Navíc, ceněny jsou počty instalací (klientů). Jedna či dvě instalace s náklady na ochranu kódu? Přímočará jednoduchost vede k cíli (a zaplať Bůh i k penězům). Chraňme si především myšlenky a data, a to i "mečem".
dgx:
No to nelze neodpovědět :-) Vezmeme to stručně ale popořádu a budu Radime velmi rád za reakci:
- "reakce byly až zlostné" - můžu poprosit o příklad?
- "přiznejme i drahá autíčka" - je to zlostná (resp. závistivá) reakce, nebo také toužíš po drahém autě? Vadí ti, že někdo toho dosahuje nezveřejněním kódu?
- "A na to je třeba vydělat a jedině tak, že skryji kód" - proč používáš pojem skryji? Není kód skryt sám od sebe do doby, než jej někdo uvolní? Dovedeš říct, co vše takové uvolnění obnáší? Včetně negativních dopadů na autora? viz http://maly.cz/index.php?item=1495
- "doba skrytých kódů je definitivně za námi" - není to demagogie? Nakonec, dá se stejně přesvedčivě tvrdit totéž o době otevřených kódu
- "Argumentovat milionovou investicí do redakčního systému, když je jich k použití pod GPL víc než stovka" - znáš dobře licenci GPL? K čemu je stovka red.systémů pod GPL, když v konkrétní situaci narazíš na problém s licencí GPL?
- "nejznáměji snad stará dobrá WELLDONKA" - dovedeš vysvětlit, proč tímto postupem stará dobrá WELLDONKA hrubě porušuje GPL a autorská práva dalších osob?
- "daleko významnější jsou data" - jak konkrétně se liší data a program (kód)? Kde je přesná hranice, co jsou data a co už je kód?
- "Chraňme si především myšlenky" - tedy podporuješ softwarové patenty? Slučuje se to s tvým paradigmatem?
Michal Hantl:
Super, souhlas:). Podle mě se tady pletou dohromady dvě odlišné situace :
a) Uvolním kód a nemá mě to jak poškodit (ať už jsou důvody jakékoli)
b) Vyvíjím něco, na čem se může konkurence (nebo kdokoliv) jednoduše obohatit a mě to může poškodit
Obě zcela chápu a už to tady bylo naznačováno, ani jednu bych nezatracoval, nebo kritizoval.
Opensource přece není o tom, že vezmu source E-shopu, na kterém někdo roky tvrdě maká, upravím tomu pro zákazníka design a prodám. (nebo se mýlím?)
Vojtas:
Mezi reci.. Hranice kodu a dat byla u 16 bitovych procesoru zcela teoreticka. "Novejsi" procesory, ktere umi strankovani pameti maji jednoduchou ochranu. Data se od kodu lisi pouze z hlediska procesoru, diky ruznym opravnenim pro bloky pameti je zakazano spousteni kodu z adresy nalezejici datovemu bloku. Apropo mate nekdo skusenosti s rozchozenim php_bcompiler.dll? Mam nekolik verzi pro PHP5 a i PHP 4.3.1 ale yadne mi nejede. Pri spousteni php.exe mi pise chzbovou hlasku "ap_php_sprintf se nepodarilo v php4ts.dll najit.."
Marcel Simonides:
......Chraňme si především myšlenky a data, a to i "mečem"......
Jak to myslíte? Data uložená v databázi jsou přeci v majetku odběratele, který si je tam také sám vkládá. Skripty jste uvolnil. Co si tedy chcete chránit?
Bochi:
"Program pouze a jenom ona data vhodně ukládá a zobrazuje a to přívětivějším, nebo komplikovanějším způsobem."
Tato vaše představa o programu je dosti omezená. Víte, existují i jiné kódy než PHP skripty čtoucí z databáze a generující HTML kód, který se následně zobrazí.
Zkusím vám dát příklad - představte si složitý algoritmus molekulární dynamiky vycházející z kvantové teorie hustoty funkcionálu, na kterém pracovalo léta stovky lidí. S jeho pomocí pak počítáte nějaký soubor molekul, přičemž vstupem je jen poměrně málo dat, řekněme pár údajů o elektronové struktuře atomů (což je obecně a volně dostupná informace z odborných článků a knih) a nějaké geometrické parametry, a výstupem může být třeba i jen jediné číslo. Připadá vám, že zde algoritmus, potažmo vlastní program, není podstatný a jde jen o zdrojová data a formu výstupu?
A takových případů jsou samozřejmě mraky. Radime, svět nekončí za vaším monitorem.
radim:
Připouštím, jsem to ale omezenec. Jdu de sebe!!!!
Miloslav Ponkrác:
Ach jo. Ty osobní výpady, Radime jsi si mohl ušetřit. Ale koneckonců nejsi jediný v této diskusi, který argumenty lidí proti open source považuje za smrtelnou urážku a namísto věcných argumentů začíná osobními emocemi.
Nebudu argumentovat, jen přidám pár postřehů:
1) Poměrně často vidím i v open source komunitě proces deziluze. Prostě ze skalního zastánce open source se po několika tragických zkušenost stane člověk, který uzavírá zdrojové kódy. Viz třeba v poslední době známý případ Nesusu.
2) Možná jsem trochu zlomyslný, ale neříkám nic, jen setkejme se za 10 let, až vás programátorský život trochu otříská a pak si řekneme, jaké budou vaše názory na bezvýhradní podporu open source.
Na zbytek říkám jenom to, že slova "doba toho a toho je definitivně za námi" jsem slyšel už mockrát v nejrůznější podobě. Většinou se z toho ukázalo po čase jen prázdné klišé. Ale hezky to zní zejména v marketinkovém podání.
Zapomínáte na to, že software není jenom redakční systém a tvorba software není jenom tvorba webů.
Co se týká hranice mezi daty a programem, tak je dnes už velmi nejasná. Koneckonců program není nic jiného, než vhodně interpretovaná data. Chráním-li tedy program, chráním vlastně data typu zdrojový kód a chovám se tedy s Vámi v souladu.
Dál už nebudu reagovat. Je to zbytečné, a navíc k smrti nerad diskutuji s někým, kdo do věcné diskuse začíná tahat osobní emoce typu "zlostné reakce", nebo "Jakub je vykreslován jako nýmand". Nic takového tu řečeno nebylo, jen to Radime prostě začínáte brát příliš osobně a zatmívá se vám před očima a ztrácíte s prominutím soudnost.
Robo.cz:
Pro úplnost bych ještě upozornil na jeden starší projekt vycházející z poměrně zajímavé myšlenky ;-)
http://pobs.mywalhalla.net/
Jakub Hejda:
Tento využívám já.
Je zdarma a je jednoduchý.
Doporučuji!
radim:
Rád odpovím.
Píši provokativní příspěvky s úmyslem hecnout, rozpálit do ruda. Jen tak se poznají pravé úmysly autora (i v komentářích). A odhaduji, kdo se chytí a jak. Vcelku se nepletu. Kdo byl horlivec pro svoji „věc“, bude povětšinou v reakci ještě horlivější své pravdy. Skoro bych řekl bez přemýšlení nad sděleným.
Ale nikomu nic nevnucuji.
Shrnu stručně mnou sdělené:
1) zdálo se mi, a jak vidím tak zcela zcestně, že jste Jakuba pěkně za jeho počin zpražili, a jako argumenty použily emoce (např. mám přece ty mzdy),
2) odhaduji, a opět zcestně, že asi tak v roce 2010 nastane okamžik, kdy LINUX získá 50proc instalací +1,
3) jsem si vědom, že hranice mezi daty a kódem programu je velmi tenká ,
4) SW patenty zatracuji, GPL licenci znám, za zneužití GPL licence jinými nechci nést zodpovědnost,
5) nejsem profi programátor, zvládl jsem uživatelsky některé programovací prostředky v nichž si pro svoji potřebu „tvořím“, spíš si ulehčuji manuální práci s daty , nemám v úmyslu se programátorsky otřískávat,
6) pokud jsem použil nepřesné výrazy (skrýt), přijměte prosím mou pokornou omluvu,
7) toužení po AUTECH, poslední dvě mi byla shořena, teď mám favorita a tak trochu i klid,
8) za tím co jsem napsal si bez emocí plně stojím a bušte do toho jak chcete, znáte to o potrefené huse?
9) jen slabé nátury neunáší kritiku,
10) zkusme být k názorům tolerantní.
A na úplný závěr. Mám auta skutečně rád, určitě se mi líbí vše nad 2mil bez výjimky, ano, trochu i závidím. Z druhé strany jsem se věnoval automobilovému sportu víc jak 15 let a vlastnil i legendu Š130RS. Jsem aut vcelku syt.
kerosen:
Podívejme se na to taky z té druhé stránky: osobně bych nikdy nenainstaloval na server nějaký CMS, u kterého bych si nemohl prohlédnout zdroje a ujistit se, že tam někde nesedí nějaký backdoor. Jistě, je to celé záležitost důvěry - ale jestliže autor ke mně nechová tolik důvěry, aby mi zpřístupnil zdroje, proč já k němu mám chovat tolik důvěry, abych věřil, že mi v CMS nepodstrčí backdoor, přes který si bude moci například číst interní poštu našich klientů...
Jakub Podhorský:
v tom případě je lepší ani nemít počítač, že? :) protože skutečně ani nemůžu vědět co windowsy si dělají :-/
Karel Čermák:
no ehmm nejsem si tim chlapci zrovna jist ale pokud vim tak kod php vam asi jen tak ze stranek nikdo neukradne :) mozna tak vysledny kod html ale php podle me dost tezko leda ze by mel pristup k vasemu ftp nebo ste mu je sami dali coz asi ne protoze pak by zase tato cinost nepmela smysl :)
Karel Čermák:
aha tak se omlouvam sem to poradne nepochopil :) ono je to pred klientem atd. no to uz chapu :)
spaze:
no, mozna by ses divil. Takovy neosetreny vstupy do skriptu, shared hostingy atp. vsechno to predstavuje mozne riziko.
@ss@ssIn:
Podla mojho (mozno zcestneho nazoru), by bolo vyvyjat tri verzie (resp. z tej best kickovat funkcie)
Predstavte si Sablonovaci system v 3 verziach (Personal, Professional a Enterprise (ako Borland C++ Builder ;p))
a) Personal -> nevie skor nic iba 'dosadzovat' premenne (pre malicke weby a amaterov) - OPEN-SOURCE
b) Professional -> par funckii navyse (pre stredne weby, pokrocili a profesionaly) - FREEWARE CLOSED-SOURCE {skompilovane napr. cez bcompiler}
c) Enterprise -> dokonaly sablonovaci system, nenormalne mnozstvo funkcii (obrovske projekty, profici) - KOMERCNY-SOFT CLOSED-SOURCE {tiez zkompilovane}
[d) Enterprise Open-Source - za nenormalne prachy a pri podpise 'dohody' o 'utajeni zdrojakov' by klient dostal aj zdrojaky]
Toto cele ma vyhodu, ze DEV maniaci si mozu pozriet ako taka jednoducha aplikacia funguje (src) a klient si najprv stiahne freeware aby priblizne videl ako to fungueje (html), moznosti atd...(RIZIKO: klient sa uspokoji s Professionalom)
Je jasne, ze sa to neda uplatnit vsade, ale podla mna je toto idealne :)
( ja osobne by som nekupil nic, co by som predtym nevyskusal(ne doslova))
lexlutor:
nevite o cracku na ByteRun Protector
lexlutor(zavinac)pobox(bodka)sk
troska:
Hlavne si nikdo nekupujte a ani nekodujte kdejakyma pokutnima cracknutyma verzama ZEND... a mnoho dalsich "kompileru" = vyhozene penize. Proc? Proto:
http://www.zendecode.com/
bcompiler:
Bcompiler vypadá super. Škoda že nefunfuje. Aspoň mě ne. Mám trochu rozsáhlejší projekt, všechny skripty zakóduju a výsledkem jsou jen chybový hlášení, polofunkční skripty a padání apache. Zkoušel jsem různé verze php a apache a stojí to zkrátka za prd. Nemluvě o tom, že když se skripty nezapakují ale jen encodují, tak je kromě php syntaxe vidět všechno. Podle mě je tam pořád problém s include (include v include), kterej už měl bejt vyřešenej, ale asi není.
Dál jsem zkusil PHPObfuscator, ten sice nic nezakóduje, ale udělá ze zdrojáku slušnej bordel. Každopádně asi nebere v potaz zase includy, protože prostě názvy některých sdílených funkcí najednou nejsou k nalezení. Taky pokud narazí na xml kód kterej začíná
<? tak to asi vyhodnotí jako php a zbytek zdrojáku nerozmašíruje. A poslední věc - po převedení mi přestaly fungovat flash videa, nevim proč, asi pomrvil něco co neměl.
gdx:
na PHP encoder, by som sa nespoliehal, prelomit mi ho tvalo necelu hodinu aby som vytvoril skript na decode :)
Zool:
Zdravím taky přihodím do mlýna.
Mě třeba nevadí, když mi kód někdo sebere, stejně k němu nepíšu komentáře a navíc odstraňuju mezery a enter. Když se v tom pak někdo vyzná a pochopí to, tak smekám a ať si to užije, ale tolik času co nad tím bádal a upravoval kod do přehledné formy, tak by si svůj systém naprogramoval stejně rychle.
cucací potřeby:
* například phpEdit umí "splasklý" kód přeformátovat.
* nepsat do kódu komentáře je proti etice dobrého programátora
JNO:
Mám problém s bcompilerem. Všechny soubory zkompiluje v pořádku, ale když chci pak web zobrazit tak mi chrome vrátí hlášku "Chyba 324(net::ERR_EMPTY_RESPONSE): Server ukončil spojení, aniž by odeslal jakákoli data.". Dělají to jen některé třídy, bohužel ale nejsem schopen zjistit na čem přesně to padá. Může mu nějak vadit třeba PHP4? Nebo nenapadá někoho, co by mohl být problém?
retriever:
No ja by som to nevidel tak že sa tu jedná len o modulové kopírovanie nejakej dynamickej grafiky. Ak raz hodíte do enginu nejaký vlastný algoritmus, potom sa stane táto otázka pre každého veľmi chúlostivá. Sám som uvažoval že asi jediná možnosť je prekryť kód maskovacím layerom, a samotný výkonný (chránený kód ´tahať z inej URL a zo SQL databázy, a až po odsúhlasení prístupu, samozrejme.
Diskuse je zrušena z důvodu spamu.