[PHP] CMS encrypten

[Reveller]

Deze vakantie heb ik besteed aan het bouwen van een CMS'je - althans, ik ben ermee begonnen.

Uiteindelijk wil ik dit CMS'je aan anderen gaan verkopen. Hieroven heb ik twee vragen.

Ten eerste: in principe wil ik CMS + hosting in een pakket verkopen, zodat ik de code niet uit handen hoef te geven. Ik kan me alleen goed voorstellen dat mensen al een hostingpakket ergens hebben, en alleen het CMS willen kopen. In dat geval geef ik de code uit handen. Niet dat die nou zo briljant is, maar er zitten van mij toch een heleboel uren werk in. Vandaar mijn vraag of het mogelijk is om alle PHP code te encrypten, waarbij er op de server geen extra tools nodig zijn om die ge-encrypte code te kunnen draaien.

De tweede vraag heeft te maken met de database backup. Ik wil een functie in het systeem bouwen dat gebruikers in het admin gedeelte op een knop kunnen klikken om een database (mysql) backup te downloaden - gelijk aan bv. de export functie in PHPMyAdmin. Dit lijkt me verstandig, omdat je dan de verantwoordelijkheid van het backuppen van het systeem bij de klant legt.

Nadeel is alleen dat ik niet teveel wil prijsgeven over de structuur van de database. Ik stuur geen structuur mee, maar een hoop kan toch afgelezen worden aan de INSERT queries. Vandaar ook de vraag: is het mogelijk om deze sql dumps te encrypten, en dat ze voor mij weer de decrypten en te gebruiken zijn in het geval dat ik een backup moet terugzetten?

Ik hoop op een paar nuttige tips

[gorgi_19]

Uiteindelijk wil ik dit CMS'je aan anderen gaan verkopen. Hieroven heb ik twee vragen.

Ga dan ook vast gelijk nadenken over de vraag: "Waarom moet ik jou nemen? Wat onderscheid jou van de rest?"

Niet dat die nou zo briljant is, maar er zitten van mij toch een heleboel uren werk in. Vandaar mijn vraag of het mogelijk is om alle PHP code te encrypten, waarbij er op de server geen extra tools nodig zijn om die ge-encrypte code te kunnen draaien.

Zoek ook eens naar obfuscaten

Nadeel is alleen dat ik niet teveel wil prijsgeven over de structuur van de database. Ik stuur geen structuur mee, maar een hoop kan toch afgelezen worden aan de INSERT queries.

Als zij die database hosten, kunnen ze er achter komen. Je kan beter met contracten e.d. werken

[ Voor 16% gewijzigd door gorgi_19 op 17-08-2004 01:03 ]

[rollebol]

Zend. Dat lijkt me voldoende om het als pseudocode te verhaspelen waardoor het eigenlijk alleen nog machine readable is.

Ik zou die tables gewoon lekker leesbaar exporteren. Waarom niets prijsgeven over de structuur van de database? Het encrypten is wel degelijk mogelijk, maar ik zou graag willen dat je nog wat harder nadenkt over de voordelen van een wat opener opstelling.

[zeroxcool]

Als ik jou was zou ik eens met een provider gaan praten. Hun kunnen je uiteraard leuke prijzen bieden en mocht een potentiele klant bij een concurrent zitten willen zo'n bedrijven nogal eens omlaag gaan met prijzen. Ik denk dat je daar een veel makkelijkere - minder technische - oplossing hebt.

[Verwijderd]

Je kan het misschien Zend-encrypten?
http://www.experts-exchan...products/zend-encoder.php

[ Voor 20% gewijzigd door Verwijderd op 17-08-2004 01:09 ]

[Verwijderd]

je code encrypten kan ik me enigzins voorstellen, maar waarom zou je in godsnaam je database backup willen encrypten? is je structuur zo revolutionair? kan een concurrerende site draaien puur op je database output? heb je zoveel tijd in het uitdenken van je structuur gestopt?

[Not Pingu]

^^ What he said.
En waar ligt de grens? Gaat je CMS ook zo'n leuk 'no right click' javascriptje bevatten? Ze mochten eens in je HTML kunnen kijken...!

Even serieus... er zijn tig andere mogelijkheden waarop mensen enig idee kunnen krijgen van wat er binnen je CMS omgaat. Als ze echt willen, tenminste. Maar als je CMS een bepaalde grootte bereikt, dan is het sowieso al een heel werk om de broncode door te spitten en te zien wat waar op uitkomt en hoe alles met elkaar gebruikt wordt. Als ik jouw was zou ik me daar niet te druk om maken, en gewoon zorgen dat je goeie copyright meldingen neerzet en in het contract met je klanten duidelijk maakt dat ze geen code mogen jatten (als extra geheugensteun zeg maar).

In mijn ervaring willen mensen meestal hun code obfuscaten als ze niet willen dat anderen kunnen zien dat het eigenlijk niet zoveel voorstelt, of dat het zelfs ergens gejat is. Ik neem niet aan dat dat hier het geval is, maar imho is je code teveel obfuscaten een zwaktebod. Als iemand er echt achter wil komen, komt ie er toch wel achter. En degenen die er ook wel achter willen komen maar te lui zijn om er iets voor te doen, die zullen ten eerste niet gauw iets bruikbaars uit een heel CMS kunnen halen en zullen ten tweede toch niet weten wat ze ermee moeten doen.

[CyBeR]

TS is waarschijnlijk bang dat iemand een search-and-replace op zijn naam doet en 't verder verkoopt alsof deze persoon 't zelf gemaakt heeft.

[Soultaker]

Reveller schreef op 17 augustus 2004 @ 01:00:
Ten eerste: in principe wil ik CMS + hosting in een pakket verkopen, zodat ik de code niet uit handen hoef te geven. Ik kan me alleen goed voorstellen dat mensen al een hostingpakket ergens hebben, en alleen het CMS willen kopen. In dat geval geef ik de code uit handen.

Mijn ervaring is dat de mensen die bereid zijn te betalen, vaak op zoek zijn naar een totaalpakket. Die hebben dus helemaal geen zin om jouw CMS los te kopen en ergens anders een hostingpakket aan te schaffen, om vervolgens een boel tijd en moeite kwijt te zijn aan het configuren van jouw CMS bij hun hosting provider.

Waarschijnlijk kun je je dus een heleboel zorgen besparen door alleen een compleet pakket aan te bieden. Daardoor beperk je uiteraard je afzetmark, maar het spaart je ook een heleboel zorgen uit.

[Steven]

Maar ik vermoed dat je een goedkope oplossing zoekt... Wat altijd kan is met een scriptje alle \n achter ; en {} weghalen en alle tabs en lege regels verwijderen. Op die manier ben je wel een heel ziek persoon als je dit CMS leesbaar wilt gaan maken aangezien andere CMSen dan een makkelijker alternatief zijn.

PS: Dit is wel een hele zieke manier van code verbergen btw

[ Voor 10% gewijzigd door Steven op 17-08-2004 12:02 ]

[Erkens]

Steven schreef op 17 augustus 2004 @ 12:01:
PS: Dit is wel een hele zieke manier van code verbergen btw

welke ook heel eenvoudig weer leesbaar te maken is

[gorgi_19]

Steven schreef op 17 augustus 2004 @ 12:01:
Maar ik vermoed dat je een goedkope oplossing zoekt... Wat altijd kan is met een scriptje alle \n achter ; en {} weghalen en alle tabs en lege regels verwijderen. Op die manier ben je wel een heel ziek persoon als je dit CMS leesbaar wilt gaan maken aangezien andere CMSen dan een makkelijker alternatief zijn.

PS: Dit is wel een hele zieke manier van code verbergen btw

Dan kan je beter een standaard obfuscator pakketje nemen, als je het toch wilt doen..

[djluc]

Steven schreef op 17 augustus 2004 @ 12:01:
Maar ik vermoed dat je een goedkope oplossing zoekt... Wat altijd kan is met een scriptje alle \n achter ; en {} weghal[...] alternatief zijn.

Je vergeet commentaar weghalen

@ts: heb je al precies nagedacht op welke manier je geld wilt gaan verdienen enzo? Eventueel eens wat op papier gezet, eens gekeken of het wel rendabel is. Welke vraag is er eigenlijk op de markt? Misschien willen mensen wel helemaal niet zelf hosten maar het kan net zo goed zijn dat ze dat juist alleen maar willen en jouw hosting dus niet willen.

[Not Pingu]

CyBeR schreef op 17 augustus 2004 @ 02:01:
TS is waarschijnlijk bang dat iemand een search-and-replace op zijn naam doet en 't verder verkoopt alsof deze persoon 't zelf gemaakt heeft.

Maar dat is imho meer een juridische kwestie dan een technische.

Daarnaast maakt djluc een goed punt: wat voor klanten zullen geinteresseerd zijn in een CMS? Klanten die niet zelf een site kunnen maken. Die klanten zullen dus waarschijnlijk ook niet weten hoe ze een server moeten draaien/huren en hoe ze daar een CMS op moeten installeren. Dus een alles-in-een pakket is dan de beste oplossing. Hoef je ook niet bang te zijn voor codediefstal, maar natuurlijk kan men altijd je layout of interface jatten. Dat blijf je toch houden. En als dat gebeurt dan zul je dat toch juridisch moeten regelen.

[Verwijderd]

oeps sorry laatste reactie van topic niet gezien


"Waarom zou je zo moeilijk doen......

Ik neem aan dat je de CMS maakt voor mensen die zelf niet goed zijn in websites bouwen. Iemand gaat normaal gesproken geen CMS kopen als hij er een zelf kan bouwen ( of zit ik mis). Mensen die hem wel nemen zullen dus weinig kaas hebben gegeten van de code die ze zien staan."

[ Voor 10% gewijzigd door Verwijderd op 17-08-2004 13:29 ]

[Erkens]

Verwijderd schreef op 17 augustus 2004 @ 13:28:
oeps sorry laatste reactie van topic niet gezien


"Waarom zou je zo moeilijk doen......

Ik neem aan dat je de CMS maakt voor mensen die zelf niet goed zijn in websites bouwen. Iemand gaat normaal gesproken geen CMS kopen als hij er een zelf kan bouwen ( of zit ik mis). Mensen die hem wel nemen zullen dus weinig kaas hebben gegeten van de code die ze zien staan."

Je vergeet mensen/bedrijven die geen tijd hebben om een CMS te bouwen

[_-= Erikje =-_]

Draai je je eigen server? dan zou je naar turc kunnen kijken, dat is een zend achtige php accelerator die ook kan encrypten maar dan freeware

[Reveller]

Verwijderd schreef op 17 augustus 2004 @ 01:39:
...waarom zou je in godsnaam je database backup willen encrypten? is je structuur zo revolutionair? ...

Helemaal niet revolutionair, waarschijnlijk zelfs erg simpel - maar wel het enige kapitaal van deze kleine onderneming...

Gunp01nt schreef op 17 augustus 2004 @ 01:58:
En waar ligt de grens? Gaat je CMS ook zo'n leuk 'no right click' javascriptje bevatten? Ze mochten eens in je HTML kunnen kijken...!
[...] gewoon zorgen dat je goeie copyright meldingen neerzet en in het contract met je klanten duidelijk maakt dat ze geen code mogen jatten.
[...] In mijn ervaring willen mensen meestal hun code obfuscaten als ze niet willen dat anderen kunnen zien dat het eigenlijk niet zoveel voorstelt, of dat het zelfs ergens gejat is.

Achtereenvolgens: ik weet ook dat als je browser het kan weergeven, je de originele HTML kunt terughalen. Bovendien - imo boeit de HTML output niet. Copyright is al voor gezorgd - ook middels Algemene Voorwaarden etc. Maar hoe goed je het juridisch ook dichttimmert - als iemand jouw code (al dan niet aangepast) als de zijne gaat verkopen, kom je daar ws. of niet of pas heel laat achter. En trouwens - we weten allemaal (zie CyBeR) hoe makkelijk het is code om te vormen. Je kunt dan niet eens meer aantonen dat het oorspronkelijk jouw code was.
Niet zoveel voorstelt / gejat - geen van beide, maar zoals al gezegd: wel het enige kapitaal van deze kleine onderneming.

Soultaker schreef op 17 augustus 2004 @ 03:39:
[...]

Mijn ervaring is dat de mensen die bereid zijn te betalen, vaak op zoek zijn naar een totaalpakket. [...] Waarschijnlijk kun je je dus een heleboel zorgen besparen door alleen een compleet pakket aan te bieden. Daardoor beperk je uiteraard je afzetmark, maar het spaart je ook een heleboel zorgen uit.

Dat is ook mijn gedachte (zie openingspost), en die hoop ik hier bevestigd te zien.

djluc schreef op 17 augustus 2004 @ 12:13:
[...]@ts: heb je al precies nagedacht op welke manier je geld wilt gaan verdienen enzo? Eventueel eens wat op papier gezet, eens gekeken of het wel rendabel is. [...]

Als rechtgeaard bedrijfskunde student heb ik uiteraard al goed rondgevraagd Maar de kwestie uit de openingspost blijft open staan. Je hebt een bepaalde kritieke massa nodig om te weten wat mensen willen.

Tenslotte ben ik het eens met de gedachte dat mensen ws. niet eens zin / tijd / geld hebben om los een CMS en hosting aan te schaffen.

Tenslotte 2: ik geloof niet zo in obfuscaten - ik weet zeker dat er tooltjes op de markt zijn die alles weer netjes indenten, net zoals ik die voor HTML heb. En dat een variabele hernoemd wordt...tja...dat maakt ook niet zoveel uit...

[humi]

Je kan met Turckmmcache ook als de webserver niet van jezelf is prima de boel encrypten. Enige wat mogelijk moet zijn is de functie dl, waarmee je een losse loader kan laden (enigzins omslachtig, maar 't werkt wel), makkelijker natuurlijk is als de turckmmcache extensie op de webserver zelf geinstalleerd staat.

[ripexx]

Even nog een opmerking als jij een backup gaat versleutelen wordt men niet blij Ik wil als dat nodig is gewoon mijn database kunnen restoren zonder rare tools. En ik wel des noods zelf mijn backups regelen.

Voor het bedrijf waar ik werk maken we gebruik van obfuscaten voor de javascripts. En dan niet vanwege dat men het niet kan lezen maar om bandbreedte en prefromance reden. Server side maken we gebruik van asp met javascript of vbscript welke weer gecodeerd worden met een of andere tool. De databases doen we niets mee deze worden gewoon normaal uitgeleverd.

De reden dat we de asp encrypten is heel eenvoudig, we willen niet dat men zelf in onze code zaken gaat aanpassen. Want dan kunnen we a) de kwaliteit en preformance niet meer garanderen en b) willen we zelf ook wat verdienen aan maatwerk

[Not Pingu]

Wat dat betreft is het een voordeel dat je bij ASP.Net bepaalde zaken kunt compileren, zoals je DAL classes en je business logica. Dat is wel met moeite terug te halen, maar het is erg veilig en staat niet in de weg van de normale werking van het geheel.

[Verwijderd]

als het extern wordt gehost op een hostingpakketje kun je andere methodes als Zend al gauw vergeten. Hosting Providers zijn niet zo wel willend in het installeren van allerlei extensions op PHP omdat iemand zijn code wil beveiligen.

check op Zend.com anders het small business programme eens, op die manier kun je heel goedkoop, legaal aan de Zend Encoder komen

[gorgi_19]

Gunp01nt schreef op 17 augustus 2004 @ 23:47:
Wat dat betreft is het een voordeel dat je bij ASP.Net bepaalde zaken kunt compileren, zoals je DAL classes en je business logica. Dat is wel met moeite terug te halen, maar het is erg veilig en staat niet in de weg van de normale werking van het geheel.

offtopic:
.Net is normaliter zo gruwelijk simpel te decompilen, daar wordt je niet vrolijk van

[PipoDeClown]

hier php compiler voor "maar" 399 dollar, lol
je moet er maar voor over hebben

[ Voor 23% gewijzigd door PipoDeClown op 18-08-2004 08:37 ]

[Verwijderd]

Verwijderd schreef op 18 augustus 2004 @ 02:28:
als het extern wordt gehost op een hostingpakketje kun je andere methodes als Zend al gauw vergeten. [ ...]

Onzin. Zend encoder zit ingebouwd in zend optimizer, dat is bij een beetje zich zelf respecterende provider geinstalleerd, en bovenal gratis. De zend encoder kost ~ 2000 dollar, maar als het meer hobby is adviseer ik kazaa . Voor het encrypten van de database: zoek eens naar de mcrypt functie op de website van php. Dat is wat je nodig hebt.

offtopic:
Volgens mij steld de topicstarter een duidelijke vraag. Waarom moet iedereen zo nodig zijn mening geven of hetgeen men wil al dan niet handig is

[Schonhose]

Verwijderd schreef op 19 augustus 2004 @ 00:37:

offtopic:
Volgens mij steld de topicstarter een duidelijke vraag. Waarom moet iedereen zo nodig zijn mening geven of hetgeen men wil al dan niet handig is

offtopic:
Omdat wij ons afvragen of de topicstarter wel goed heeft nagedacht waarom hij het wil. Daarom worden er kritische vragen gesteld of meningen gegeven waarom zoiets niet haalbaar is. Zo wordt de topicstarter gedwongen na te denken over de haalbaarheid.

[StevenK]

Het lijkt dat wanneer je je code wil verbergen, je niet met een interpreted language moet gaan werken.

Of een tussenoplossing waarbij je een aantal functies niet in PHP, maar in een compiled language schrijft.

En hetzelfde voor die database: als je je structuur wil verbergen, moet je maar voor lief nemen dat je zelf de backups moet draaien.

[Suepahfly]

Steven schreef op 17 augustus 2004 @ 12:01:
Maar ik vermoed dat je een goedkope oplossing zoekt... Wat altijd kan is met een scriptje alle \n achter ; en {} weghalen en alle tabs en lege regels verwijderen. Op die manier ben je wel een heel ziek persoon als je dit CMS leesbaar wilt gaan maken aangezien andere CMSen dan een makkelijker alternatief zijn.

PS: Dit is wel een hele zieke manier van code verbergen btw

In Zend Studio zit een hele makkelijke menu optie: Ident Code.
Die maakt zelfs de meest lelijk geformateerde code enigzins leeesbaar.