ugrás a tartalomhoz

PHP kód titkosítása

fERI · 2005. Már. 23. (Sze), 01.05
Sziasztok ListaTagok!

A következő lenne a problémám., és szerintem nagyon sok embert érint:
Ma Magyarorszáron nem tisztázott, hogy egy szolgáltatást fizetnek meg a vásárlók vagy egy szellemi terméket (ami jóval drágább), amikor egy weboldalt készítettnek el valakivel. Egyre többen írnak olyan "alkalmazásokat", melyek szinte teljesen felparaméterezhetők. Természetesen ezeket értékesíteni is lehet, és szoktak is. Viszont a kérdés ebben az esetben nagyon érdekes: HOGY VÉDED MEG A SZELLEMI TERMÉKED, HOGY MÁS AZ ENGEDÉLYED, MEGVÁSÁRLÁS NÉLKÜL NE HASZNÁLHASSA FEL, AZON KÍVÜL, HOGY SZERZŐDÉSBEN EZT KIKÖTÖD (ami nem jelent semmit, mert nagyon kicsi az esélye annak, hogy megtudd)? Ugye, valahogy le kellene kódolni a forrást. Szóval van e valakinek olyan információja, hogy egy PHP állomány kódolható (titkosítható) legyen úgy, hogy ha azt a partnercégnek átadja, a szerveren semmi módosítást ne kellen végrehajtani a konfigurációs állományokban? Vagy van e valakinek valami más kiforrot megoldása erre a problémára?

Én arra is gondoltam, hogy az osztályokat a saját szerveren tárolnám, de ez sem a legjobb megoldás, a titkosítás viszont tökéletesen megfelelne.

Szóval van e olyan titkosítási módszer, mely minden szerveren fut, és viszonlyag a PHP 4.x.x-et támogatja?

Előre is köszönöm a válaszokat.

Üdvözlettel: fERI :)
 
1

Encoder a kulcs

Benjamin · 2005. Már. 23. (Sze), 02.36
Neked Encoderre van szukseged!

Zend.com, Zend - CraftCore

--
bye, Benjamin
2

Benjamin jó kereskedő

Anonymous · 2005. Már. 23. (Sze), 09.45
Szeretjük is, meg csak nála vegyél Zend Studiót, ami a legjobb szerkesztő, ami létezik PHP-hez, de mielőtt szélesre tárod a bukszádat, azért nézd meg ezt is, ingyen van : http://turck-mmcache.sourceforge.net/index_old.html

Bocs, Benjamin, nem akarom rontani a boltot, csak ugye a nyílt forráskód :))
3

Encoder

fERI · 2005. Már. 23. (Sze), 12.51
Sziasztok!

A Zendet én is néztem, de nagyon nrága nekünk, induló cég esetén nem nagyon engedhetünk meg ilyen külcségeket. A másik probléma ezzel, hogy Optimalizert is telepíteni kell a szerverre, ahol használják a kódolt forrást. Sajnos a legtöbb helyen erre egyáltalán nincs lehetőség, mert még a szerver paramétereket sem akarják, vagy tudják megmondani. Szóval Zend kilőve már ez utóbbi dolog miatt is.

Anonymous által adott forrást megnézem, remélem, hogy jutok valamire.

De sajnos ez a dolog jogilag is elég kényes kérdés, és szerintem igazából nem lehet rá jó megoldást találni. Jó lenne, ha ezzel kapcsolatban is valami módosítást eszközölnének a nagyokosok.

Köszönöm a segítségeket, illetve várom a további javaslatokat.

Üdvözélettel:
fERI
4

A szerverhez telepíteni kell

Anonymous · 2005. Már. 23. (Sze), 13.32
A szerverhez telepíteni kell mindkét esetben egy értelmezőt, valaminek ui. meg kell értenie a kódot. Ha olyan titkosítás szeretnél, amit a futó script maga bont ki, akkor már felejsd is el az ötletet. Amit a programod eleje ki tud bontani, azt kibontja más is. Maxium obfuscator jöhet szóba nálad, ami csinál egy zavaros, nehezen visszafejthető kódot, de ez már gányolás, rengeteg hátulütője van.

Mi egyrészt saját szerveren hosztolunk, ott pedig telepítve van mindkettő értelmező program, bár mi a Zendet használjuk, mert ugyan drága, de megtérül. Benjámin biztos tud jó árat mondani (Van még kisvállalati csomag?), de ha külső cégnek készítjük a programot, előírjuk az elején a futtató környezetet. Ha nem kell neki, akkor mehet máshová programot íratni. Nincs elfogadható magyarázata, ha valaki nem akarja telepíteni a Zend Optimizert. Ez olyan, mintha nem akarnák telepíteni a .NET keretrendszert, de a program C#. Tudomásul kell venni, nem adunk át forráskódot, vagy annak is meg van az ára, megvehetik.

Aurum
5

Akkor megoldási javaslat

fERI · 2005. Már. 23. (Sze), 15.27
Szia!

Köszike a segítséget. Kb én is erre jutottam, de gondoltam, megkérdezem, hogy van e más lehetőség.

Akkor a következőt fogom csinálni:
Kap egy index.php állományt, aminek nem kell semmi titkosítás, és minden egyéb forráskódot azt az én szerveremen fogok tárolni. Ezzel meg van oldva az, hogy nem nézegeti a forráskódot. Természetesen a szerződés mellé teszek egy mellékletet, melyben megnyilatkoztatom, hogy az adott alkalmazást hol szeretné futtatni, és csak ott futtathajta. Abban az esetben, ha át szeretné telepíteni a rendszert, akkor értesít, és megkapja a kulcsot, illetve engedjük a rendszerünkben. Ezzel az is meg van oldva, hogy nem tudja másnak átadni a terméket.

Az Ő tárhelye meg tartalmazza az index.php állományokat, meg a képeket és az egyéb dolgokat, ami az oldal működéséhez szükséges.

Ez jogilag is megoldható, ha nyilatkozom azzal kapcsolatban, hogy az osztálydeffiniciók elérhetőek lesznek.

De szerintem az új PHP verziókban erre is kellene gondolni, hogy a forrás a szerveren ne legyen böngészgethető (ezzel kapcsolatban nem tud valaki valami infót?), mert a szellemi termék nagyon drága, elég sokat kell a programozónak küzdenie érte, mit véleményem szerint nem lehet megfizetni. Továbbá az új kidolgozott megoldások is veszélybe kerülhetnek. Éppen a kollágám járt így, hogy összedobott egy rendszert, és átadta a cégnek (mert buta volt) az meg lenyúlta... gondolom a többit nem kell mondanom (bíróság ezerrel). Na erre nincs szükségünk.

Köszönöm a segítséget, de azért várom az egyéb javaslatokat.

Üdvözlettel mindenkinek:

fERI
6

Esetleg el lehet rejteni a

Anonymous · 2005. Már. 23. (Sze), 15.57
Esetleg el lehet rejteni a forrásban egy pár aknát. Olyan rutinokat, amik működését csak a fejlesztő ismeri, és pl. spec. GET, POST kérésekkel kívülről is töröltethetők velük a kulcs állományok a rendszerben.
Ha elég terjedelmes a rendszer, akkor van rá esély, hogy nem találják meg idejekorán ezeket a rutinokat benne, és szerződés szegés esetén legalább nem tudják azt tovább használni.
Persze ehhez is ismerni kell az új url-t, ahová átlopták a cuccot.

2. megoldás: meg kell nézni kinek dolgozunk ill. kinek, milyen feltételekkel adjuk ki a kódunkat.
7

Ez amatőr dolog

aurum · 2005. Már. 23. (Sze), 16.47
Aknásítani a forráskódot amatőr dolog és rendszerint visszafelé sül el. Két hónap múlva, amikor majd bővíteni kell a programot, a saját aknáidba fogsz belebolondulni. Egyébként meg, aki meg akarja szereni, az kiszedi belőle ezeket. Gyenge védelem a pistikebt-k ellen, de csak egyszer okozzon véletlenül hibát egy rosszul kezelt aknád, bukod a szerződést. Arről nem beszélve, hogy ha a cégnek jó ügyvédje van, olyan kártérítési pert kapsz érte a nyakadba, hogy attól kódulsz. Senki sem lesz boldog, ha a drága pénzen megvett programjában spyweart talál.

De szerintem az új PHP verziókban erre is kellene gondolni, hogy a forrás a szerveren ne legyen böngészgethető

A PHP fejlesztői gondoltak rá, hogy ne lehessen a forráskódhoz hozzáférni, ha a szerző nem akarja. Azonban valamiből nekik is meg kell élni és pénzért adják, nem része az ingyenes PHP-nek. Úgy hívják, hogy Zend Encoder, erről beszélünk. Ha a kódoddal pénzt keresel és nem akarod, hogy mások ingyen hozzáférjenek a szellemi termékedhez, miért is baj, hogy a Zend cég emberei is így gondolkodnak és pénzt (nem sokat) szeretnének a munkájukért? De mint fentebb anonimusként javallottam, van ingyenes megoldás is, nem kel döngetni a szélesre tárt kapukat.
13

Expiration

Benjamin · 2005. Már. 24. (Cs), 12.16
Fogni kell 1 db olyan allomanyt amit minden PHP hasznal (pl: config) ezt ugy encodeolni, hogy X nap mulva lejar (havonta / felevente / evente) attol fugg milyen intervallumba fizetik a dijakat. + Raszamolni Y napot.
X nap elteltekor ertesitot/emlekeztetot kuldeni, hogy a program licence Y nap mulva lejar, es a program nem fog mukodni.

Termeszetesen errol elotte meg kell egyezni (szerzodesben)

--
bye, Benjamin
8

Biztos jó?

aurum · 2005. Már. 23. (Sze), 16.58
Ha távolról tudom includeolni a fájlokat a szerveredről, akkor biztos, hogy ezzel megvédted? Ha includeolni lehet, mert engedélyezve van a távoli fájlelérés, akkor fopennel is meg lehet nyitni és szépen beolvasni bájtonként. Cserébe viszont jó lassú lesz az oldal, mert az interneten kell fájlokat megnyitnia, holott egy összetett szájt nem két php állományból áll. Ha viszont a feldolgozást is a saját szervereden akarod megoldani, akkor meg az oldal adatait kell oda-vissza közlekedtetni a neten, a teljes adatbázis forgalommal együtt.

Továbbá fordított irányban is engedélyezni kellene a távoli fájlelérést, hogy a config állományokhoz a programod hozzáférjen. Gondolod, hogy az a rendszergazda, aki nem telepíti fel neked a Zend Optimizert, az majd pont ezt fogja megengedni?
9

PrímPosta

bbalint · 2005. Már. 23. (Sze), 17.49
a PrímPostánál (legjobb emlékeim és a hibaüzenetek szerint) távolról van felcsatlakoztatva (mount-olva) az alkalmazást (IMP) tartalmazó megosztás/könyvtár,

(szvsz) ez még jobb megoldás, minthogy a PHP foglalkozzon ezzel-azzal, hogy most ki érheti el meg nem, illetve a te szervered erőforrásait sem eszi annyira, mint egy PHP szkript

bbalint
12

Mit fog csinalni az az egy

Benjamin · 2005. Már. 24. (Cs), 12.16
Mit fog csinalni az az egy darab index.php?

--
bye, Benjamin
10

Encoder

zila · 2005. Már. 23. (Sze), 20.30
Ezt a jogilag kényes kitételt nem igazán értem...
Te készíted a programot, és előtte természetesen szerződést is köttök. Ebben a szerződésben kell kitérni arra, hogy mit kap a vevő a pénzéért. Ha ebben nem említed a forrást, vagy kifejezetten forrás nélküli fejlesztésre szól, akkor nem vagy köteles odaadni a forrást. PHP esetében ezt egy encoderrel tudod elérni, teljes nyugalommal kikötheted, hogy a programod futásához a szerveren telepíteni kell ezt-azt. Ha ez nem tetszik a megrendelőnek, akkor fizesse ki a forrás díját is...

üdv,
Zila
11

Optimizer

Benjamin · 2005. Már. 24. (Cs), 12.07
En arra szoktam hivatkozni ha nem akarnak Optimizert felrakni, hogy:
  • akkor bizony nem fog mukodni amit megvettek (errol mar a kezdetektol tudnak) szerzodes, megbeszeles miatt
  • az Optimizer egy PHP kiegeszito, ugyanazok keszitik akik a PHP-t, PHP-t hogyhogy felraktak?
  • nem tudok ugy garanciat vallalni a munkara ha felkerul egy szerverre ahol a virtualhostok kozott barki barmibe belenezhet, esetleg a rendszergazda / mas egyeb emberke aki hozzafer (tulajdonos) belemodosit a kodba

Ugy gondolom h. az ember segiti az ugyfeleit, ha egy olyan gepen van az oldala ahol az uzmeltetok nem rugalmasak (szerverparameterek, +programok telepitese: Optimizer, nconvert, stb. vagy PHP modulok bovitese: LDAP, DOMXML, CURL, GD, stb.) akkor meg lehet gyozni, hogy ilyen es ilyen okok miatt a fejlesztes hatraltatva van es ez a kesobbiekben is gondot okozhat. (nem szolnak ha valtozik valami, stb.)
Ezert erdemesebb lenne uj szolgaltatot keresni. Pl: ilyent ritkan lat az ember: PHPhost szerver info

Az araval kapcsolatban csak annyit, hogy Budapesten egy PHP programozo az SBP aranak 2-4x-et kapja havonta fizeteskent.

--
bye, Benjamin
14

Optimizer

fERI · 2005. Már. 27. (V), 20.34
Sziasztok!

Örülök neki, hogy sok dolgot sikerült ebben a témában összegyűjteni. Szorgalmasan figyeltem, hogy kinek milyen reakciói vannak a dologgal kapcsolatban.

A feldobott témával kapcsolatban csak annyi tudok mondani, hogy ahogy látom, nem kerülhető el, hogy a szerverre telepítsek bármit is. Természetesen nagyon sok okos dolog lett felsorolva, hogy ezeket hogy lehet kivitelezni. Nagyon szépen köszönöm a javastalokat.

A következő kérdésem lenne, és számítok a tapasztalataitokta: milyen titkosító szoftvert kellene használni, hol lehet esetelge ezeket beszerezni, és körülbelül milyen költségekkel kell számolni?

Nagyon szépne köszönöm a segítségeteket.

Üdvözlettel:

fERI!
15

Encoders

Benjamin · 2005. Már. 28. (H), 22.25
Hello,

Tobb lehetoseged is van:

Az elso ketto fizetos, az utolso ingyenes, ha fel kell tenni vmit a szerverre az Optimizert elobb fogjak felrakni mint barmi mast. Zend-el kapcsolatban, ha arajanlat kell, keress meg.

--
bye, Benjamin