Userbase

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.

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.

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.

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

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.

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

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.

Wil men de broncode niet geven dan is het enige alternatief dat van blaatpraat.

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?

Probeer je de inhoud van een site/pagina te rippen?
Kan je dat niet met curl?

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.

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.

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.

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...

CCatalyst 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.

Weent in ITIL releasemanagement

meon schreef: Weent in ITIL releasemanagement

Ik weet het. Desondanks zijn dit zaken die in de realiteit gebeuren