Diskussion om no-rip funktion

Din host bliver du nødt til at have tillid til. Han må nødvendigvis have administrator rettigheder på serveren for at kunne vedligeholde systemet (og fx stoppe dit script hvis du har lavet noget skodkode der går i løkke). Lad være med at flytte ind hos nogen du ikke mener du kan stole på.

men ellers er php-script da ret så umuligt at rippe. Alt hvad folk får når de beder om filen 'noget.php' er jo output fra det script, ikke scriptet selv.

mvh JakobA

Ok:
- som skrevet handler det ikke om tilliden til hosten, selvom jeg godt nok bruger en sådan i mit eksempel. For som du skriver er man nødt til at stole på hosten...ellers skal man slet ikke uploade noget som helst.

- hvis en udefrakommende person får fat i kildekoderne og installerer dem på en server og begynder at bruge systemet, så kunne det være smart med et lille script der kunne fortælle at det var installeret ulovligt...ved godt det lyder langt ude, men også derfor jeg skriver "Diskussion" ;-)

F.eks. kunne et system som OScommerce - (open source shop i PHP) teoretisk set indeholde sådan et lille script, der fortæller folkene bag systemet at scriptet nu benyttes på blabalba.com - bare for informationens skyld. Det er sådan noget jeg er interesseret i. Jeg har selvfølgelig selv nogle ideer, men vil gerne høre nogle metoder fra andre.

Hej Andy :))

if (strstr($_SERVER["SERVER_NAME"],"mitdomaenenavn") !== false) {
  print "jada";
}else{
print "hov sgu";
}

Hey laaang tid siden!
Ja da, den er faktisk ret god noget i den stil jeg selv tænkte på.

Flere! :-)

Men det kan man jo bare ændre i koden.
Hvis man har adgang til kildekoden kan man lave nok så mange krumspring for at forhindre kopiering, men i sidste ende må man sætte sin lid til en kontrakt.

Ovenstående har jeg selv brugt til at connecte til forskellige databaser afhængigt af hvor jeg arbejdede med php´en.

En anden fidus som visse laver er simpelthen at adskille login sektionen fra hele molevitten og så kræve adgang via en helt anden og meget hemmelig server. På den måde vil du altid kunne styre hvem der får adgang og fra hvilke domæner. Problemet med den metode er selvfølgelig at der ikke er mange der bryder sig om at blive overvåget på den måde når nu de allerede har købt noget færdigt.

/Nikolaj

Jeg har altså svært ved at følge din tankegang. Jeg tror du har misforstået noget. Almindelige folk som dig og mig, vil aldrig kunne få fat i et script fra en vilkårlig server, med mindre det pågældende script er lagt til fri downloading.

Prøv at læse jakobas kommentar 13/11-2003 13:48:41 igen. Eventuelt også denne lille leksion http://www.html.dk/tutorials/asp/lektion1.asp (princippet er det samme som ved PHP).

Det er vel reelt nok. Man sælger et script, og vil sikre sig at det ikke
bare ændres/videresælges. En løsning er:
http://www.zend.com/store/products/zend-encoder.php

el_barto: --> Nemlig! -men kan selvfølgelig være svær at finde i en overflod af scripts ;-)
- denne metode vil formentlig være god i det tilfælde, at det er en ikke-alt-for-avanceret php-mand der gør det.

Nikolaj: --> Overvågning er altid et grimt ord for kunder - og det er som sådan heller ikke meningen at de skulle blive - jeg forestiller mig at denne funktion er en del af installationen af systemet, på den måde bliver kunden ikke overvåget...kun i det tilfælde hvor siden og systemet flyttes til en anden server.

Gerne flere

erikjacobsen: --> Lige hvad jeg ikke vidste fandtes! Kanon!

Det optimale ville klart være en kryptering som Zend encoder umiddelbart kan klare, ser lige nærmere på den.

Og ja hensigten er reel i det tilfælde, at andre kan videresælge selvom en kontrakt siger de ikke må. Dette eksempel jeg giver er jo ikke anderledes end problemerne med piratkopiering.

Så søg lidt mere - Zends løsning er mig bekendt ikke den eneste.

Du kan jo evt. lave en funktion der _skal_ valideres op mod et script på din egen server, fx en godkendelse af en ip, host eller lignende... hvis den pågældende ikke findes i din database, kunne du modtage en alarm, eller scriptet får simpelthen en fejlmeddelelse retur.

Hvis du vil lave det, så brugeren får en fejlmeddelelse, så lad være med at lave det sådan: "Hahahahahahahaha - det er bare ulovligt!!! HAHAHAHAHAHA!!!"
Lav det som en "Siden kan ikke vises-fejl" Fx send en header-fejl 400

Det kan selvfølgelig godt omgås, men det sker tit, at webmastere kører scriptet første gang, hvorefter de så fejlfinder. Så hvis du bare sørger for at scriptet køres som det ALLERFØRSTE, så kan du jo banne ip'en fremover, såfremt du ikke har godkendt den. Du sørger simpelthen for, at en HELT speciel, vital funktion SKAL valideres før det virker. Så kan de jo kontakte dig hvis de gerne vil købe systemet.

Dette kræver dog at du har en JÆVNT!!!! stabil server!!!

exp:--> Rigtig holdbar løsning :-) den er fornuftig!
Nej jeg kunne aldrig finde på at skrive sådan noget til brugeren ;-) - en silent alarm er hvad jeg vil benytte og det er hvad du skriver om - kanon!

Nu ved jeg ikke om det bare er mig, men en "silent alarm" minder mig om
spyware: noget med ukendte, registrerende funktioner i et program, hvor
brugeren ikke er orienteret om det. Det er jo nogen der ikke kan lide.

Hvis du ikke fortæller kunden om denne "silent alarm", synes jeg du snyder
ham. Og du står med et ansvar, den dag denne funktion, ved en fejl, forhindrer
hans script i at køre.

Men det er bare min mening.

Man kan jo evt. fortælle det til dem der køber den, og så give hver enkelt (officiel) kopi en unik identifier. Hvis så denne begynder at gå igen, kan man opspore originalen. Så skal der bare tages højde for det i kontrakten :-D

Ja, det kan man. Men vil kunden købe med de betingelser? Der er en "sjov"
historie, som dette minder mig om.

"Quicken" er et populært program i USA til hjemme- og firmaregnskab. Det
blev så lanceret i Danmark en gang i 90'erne. I dag eksisterer det firma,
som lancerede det ikke længere. Forklaringen, som jeg opfatter den, er at
de netop bandt deres kunder med mærkelige betingelser.

Selv om man fx havde købt programmet i en forretning med CD og det hele,
skulle man alligevel ind på en website og registrere programmet. Skulle man
flytte til en anden maskine, skulle man igen. Uagtet man måske ikke har
internet. Registreringen skulle så ovenikøbet ske 10 minutter efter, ellers
vil den ikke virke. Ikke noget med at få koden på biblioteket, og så
cykle hjem og taste den ind. Ok, man kunne ændre datoen på computeren.

Så kom der en opdatering, som kun kunne fås på Internettet. Kørte man på
en maskine uden Internet kunne man ikke få en opdatering. Man kunne end
ikke købe en CD med opdateringen på. Det lykkedes så enkelte at få en CD
alligevel.

Så nu eksisterer firmaet ikke mere i Danmark, fordi man ikke lod
kunderne få det program de købte, og stillede mærkelige betingelser op.

Jeg synes man skal holde sig til en reel handel og en reel vare, og så
løbe risikoen for kopiering.

Hmm, hvad er det nu det minder mig om .... et firma der har succes med
sådanne ordninger? Nå ja, Microsoft...

De essentielle her er vel at få lavet en unik identifier i hver "legal" version af programmet. Så kan en evt. lækket version spores tilbage til den oprindelige ejer ;-)
Og så kan de holdes ansvarlige...!

erik--> Okay silent alarm var nok et dårligt ordvalg - det er egentlig heller ikke det jeg er ude efter.

Jeg er heller ikke interesseret i at en evt. fejl i et sådant licensstyringsscript kan give gener for kunder som er reelle kunder.

Min foreløbige konklusion:
- kyptering af en enkelt fil - som kun indeholder meget få linier kode, men som er essentiel for at sitet fungerer.

Lad os kalde den for config.php:
- indeholder user og pass til sql
- 10 forskellige indstillinger som bruges af "systemet" f.eks. site-url

Denne fils indhold er unikt for ethvert site og ved at kryptere denne, burde der ingen risiko være for at folk skulle kunne kopiere sitet og genbruge systemet....for man ved jo ikke hvad denne fil måtte indeholde!

Ganske smart - skulle jeg mene...

Ville det være muligt selv at lave en form for kryptering i denne enkeltstående fil? Uden at skulle købe ex. Zend encoder?

Min løsning blev kryptering af nogle vitale variabler som på ingen måde vil kunne genere brugerne af scriptet, men scriptet vil være ubrugeligt på et andet domæne.

Inspiration:
http://www.eksperten.dk/spm/254658

Læg svar så deler jeg pointene mellem jer.