Hallo,
Ik ben bezig met een webapplicatie te maken die lokaal draait maar er zal ook een PHP-file extern moeten gekoppeld worden met include waar dat enkele functies inzitten om te gebruiken maar de externe php-file heeft .PHP als extentie. Dit om blijkbaar te verkomen dat iemand die functies kan zien/kopieren.
Als ze die externe file de extensie omzetten naar bv .func of .inc etc dan werkt het maar dan is de broncode van die file te zien en dat willen ze niet.
JSON/API is hebben ze niet. (of willen ze niet maken) Of kan het anders remote ingesteld worden dat de inhoud niet gelezen kan worden als ze gewoon surfen naar de externe file?
de regel die zou gebruikt worden is : include('https://www.domein.com/functies.php');
Heeft iemand een idee om dit op te lossen?
Apache en PHP 7.3 draaien om een debian omgeving.
php include() vraag
- guntherstassen
- Pro Member
- Berichten: 315
- Lid geworden op: 09 feb 2011, 20:16
- Locatie: Sint-Truiden
- Uitgedeelde bedankjes: 12 keer
- Bedankt: 27 keer
-
- Elite Poster
- Berichten: 3724
- Lid geworden op: 17 apr 2019, 11:47
- Uitgedeelde bedankjes: 111 keer
- Bedankt: 154 keer
- Recent bedankt: 3 keer
Kan je niet gewoon een copie vragen van die remote file om lokaal te hosten ?
Anders gaat het niet lukken (tenzij via misconfiguratie/exploits)... je kan niet tegelijk iets zien en niet zien.
Anders gaat het niet lukken (tenzij via misconfiguratie/exploits)... je kan niet tegelijk iets zien en niet zien.
-
- Elite Poster
- Berichten: 1301
- Lid geworden op: 10 jan 2014, 12:09
- Uitgedeelde bedankjes: 32 keer
- Bedankt: 103 keer
Enige manier hier zal zijn dat zij hun code encrypten, en dat jij een encryption loader installeert, met de juiste licentiecode van hun.
Een voorbeeld is bijvoorbeeld ioncube loader.
Dit wordt vaak gebruikt om closed source php applicaties bij klanten te installeren, als je als bedrijf php ontwikkelt.
Een voorbeeld is bijvoorbeeld ioncube loader.
Dit wordt vaak gebruikt om closed source php applicaties bij klanten te installeren, als je als bedrijf php ontwikkelt.
-
- Elite Poster
- Berichten: 8273
- Lid geworden op: 20 jun 2016, 18:36
- Uitgedeelde bedankjes: 19 keer
- Bedankt: 527 keer
- Recent bedankt: 13 keer
Idd, encryptie, maar ik zou het eenvoudig houden met gewoon openssl.
Maar dat is niet de enige manier, alternatieven die iets minder expensive zijn dan telkens moeten decrypteren:
* .htaccess op de andere server en dan met username:password@ in de include, zoals in de PHP manual een voorbeeld staat
* Op andere server de include file data genereren met een php script dat enkel werkt als er een zekere tag in de request staat a la file.php?geheimecode
* Bestand op de server een zeer complexe naam geven, maar dat is vooral security through obscurity en geen aanrader
Maar dat is niet de enige manier, alternatieven die iets minder expensive zijn dan telkens moeten decrypteren:
* .htaccess op de andere server en dan met username:password@ in de include, zoals in de PHP manual een voorbeeld staat
* Op andere server de include file data genereren met een php script dat enkel werkt als er een zekere tag in de request staat a la file.php?geheimecode
* Bestand op de server een zeer complexe naam geven, maar dat is vooral security through obscurity en geen aanrader
- bitbite
- Premium Member
- Berichten: 558
- Lid geworden op: 18 dec 2012, 14:01
- Uitgedeelde bedankjes: 38 keer
- Bedankt: 42 keer
Hoe doen ze het voor andere 'klanten'?
Een (rest?) service aanbieden lijkt me het technisch meest evident.
In theorie zouden ze natuurlijk ook jouw code bij hen kunnen draaien (waar je dan zelf een API rond bakt), maar dan komt het nog op vertrouwen neer.
In de corporate wereld lossen ze dat op met contracten en non-disclosure agreements, maar ik zou precies twee keer nadenken voor je die weg inslaat.
Een (rest?) service aanbieden lijkt me het technisch meest evident.
In theorie zouden ze natuurlijk ook jouw code bij hen kunnen draaien (waar je dan zelf een API rond bakt), maar dan komt het nog op vertrouwen neer.
In de corporate wereld lossen ze dat op met contracten en non-disclosure agreements, maar ik zou precies twee keer nadenken voor je die weg inslaat.
-
- Elite Poster
- Berichten: 3724
- Lid geworden op: 17 apr 2019, 11:47
- Uitgedeelde bedankjes: 111 keer
- Bedankt: 154 keer
- Recent bedankt: 3 keer
Al deze vormen geven je toegang tot de PHP broncode... dan kan men evengoed de code gewoon geven zodat je ze lokaal op je eigen server kan plaatsen.CCatalyst schreef:* .htaccess op de andere server en dan met username:password@ in de include, zoals in de PHP manual een voorbeeld staat
* Op andere server de include file data genereren met een php script dat enkel werkt als er een zekere tag in de request staat a la file.php?geheimecode
* Bestand op de server een zeer complexe naam geven, maar dat is vooral security through obscurity en geen aanrader
Wil men de broncode niet geven dan is het enige alternatief dat van blaatpraat.
- meon
- Administrator
- Berichten: 16729
- Lid geworden op: 18 feb 2003, 22:02
- Twitter: meon
- Locatie: Bree
- Uitgedeelde bedankjes: 574 keer
- Bedankt: 770 keer
Wat Blaatpraat zei.
Los van het feit wat een slecht idee het is om remote een file in je eigen uitvoerbare code te injecteren.
Want dat vertrouwen werkt in twee richtingen: wat weerhoudt hen er van om niet de code na een tijd te wijzigen om via exec() lokaal op jouw server zaken uit te voeren? Of de geladen connection string op te vragen en jouw database manipuleren?
Los van het feit wat een slecht idee het is om remote een file in je eigen uitvoerbare code te injecteren.
Want dat vertrouwen werkt in twee richtingen: wat weerhoudt hen er van om niet de code na een tijd te wijzigen om via exec() lokaal op jouw server zaken uit te voeren? Of de geladen connection string op te vragen en jouw database manipuleren?
- guntherstassen
- Pro Member
- Berichten: 315
- Lid geworden op: 09 feb 2011, 20:16
- Locatie: Sint-Truiden
- Uitgedeelde bedankjes: 12 keer
- Bedankt: 27 keer
Allen bedankt voor de feedback. Ik ga het bekijken samen met dat bedrijf wat ze willen toegeven en wat niet...
Alvast bedankt voor de tips.
Alvast bedankt voor de tips.
-
- Elite Poster
- Berichten: 8273
- Lid geworden op: 20 jun 2016, 18:36
- Uitgedeelde bedankjes: 19 keer
- Bedankt: 527 keer
- Recent bedankt: 13 keer
Ik heb de vraag begrepen als zijnde dat de file extern gehost moet worden, publiek toegankelijk moet zijn (voor de include), maar dat men niet wil dat jan en alleman de broncode dan kan zien ("dat de inhoud niet gelezen kan worden als ze gewoon surfen naar de externe file"). Dat volgt immers uit het feit dat OP include() gebruikt dat geen encryptie toelaat, OP mag de code dus wel zien en in zijn code toevoegen. Daar kan een reden toe zijn, men wil bv daar wel nog de controle houden om (snel) aanpassingen te kunnen maken aan de code van die functies, en dan kan het dus niet lokaal gehost worden bij OP.DarkV schreef:
Al deze vormen geven je toegang tot de PHP broncode... dan kan men evengoed de code gewoon geven zodat je ze lokaal op je eigen server kan plaatsen.
Als het hier over zo'n commercieel pakket gaat waarbij OP de code ook niet mag zien, zou ik toch veronderstellen dat men al op de hoogte zou zijn van de oplossing die blaatpraat voorstelt, gezien dat toch vrij courant is in dat wereldje... Overigens zou men de code dan al gelekt hebben na die ".func of .inc" probeersels...
- meon
- Administrator
- Berichten: 16729
- Lid geworden op: 18 feb 2003, 22:02
- Twitter: meon
- Locatie: Bree
- Uitgedeelde bedankjes: 574 keer
- Bedankt: 770 keer
Weent in ITIL releasemanagementCCatalyst schreef:Daar kan een reden toe zijn, men wil bv daar wel nog de controle houden om (snel) aanpassingen te kunnen maken aan de code van die functies, en dan kan het dus niet lokaal gehost worden bij OP.