[PHP] Cross domain including classes

[R0K13]

Hoi,

Ik heb een aantal classes gemaakt die ik centraal op een domein X heb staan en nu wil ik die gebruiken op bijvoorbeeld het domein Y. Nu heb ik een hele simple classe gemaakt op domein X:

class test() {

var mytext;

function test() {
mytext = = 'hello world';
}

function get_msg() {
return mytext;

}

}

Op domein Y wil ik die classe nu includen op de volgende manier:

function LOAD_database_module($dbID = 0) {

include_once($GLOBALS['system_path'].'database.php');

$database = new test();
return $database;
}

Alleen krijg ik nu de melding:

Fatal error: Cannot instantiate non-existent class: database in /home/httpd/vhosts/markhandels.nl/subdomains/labs/httpdocs/danoukki/_protected/system.php on line 29

Help wat doe ik fout??

Het adres $GLOBALS['system_path'].'database.php' klopt zeker. Dat heb ik getest!

[ Voor 4% gewijzigd door R0K13 op 02-11-2006 17:22 ]

[DizzyWeb]

Waarom zegt de foutmelding dat je een class "database" probeert te instantieren, terwijl je in de code over een class "test" spreekt?

[NMe]

Als PHP op de externe server ook geparset wordt, dan include je een lege file. Wordt PHP daar dus ook geparset of niet?

[Janoz]

Probeer je nu een php bestand te includen dat op een geheel andere server staat? Heb je in $GLOBALS['system_path'] een URL ipv een directory staan?

In dat geval raad ik je aan om eens goed na te denken hoe je denkt dat dit zou werken. Bedenk daarbij vooral welke code waar uitgevoerd wordt en hoe de resulterende html van die verschillende scripts op welke plek uitkomt.

Als het je bedoeling is om op domein Y een database verbinding aan te maken om vervolgens op domein X een mysql_query op deze verbinding uit te voeren dan gaat dat natuurlijk never nooit niet werken....

[R0K13]

$GLOBALS['system_path'] = "http://system.markhandels.nl/_modules/";

Dus deze variabele bevat gewoon een link.

De foutmelding is inderdaad van een classe genaamd database. Maar in mijn voorbeeld gebruik ik even test.

Ik wil graag dat de code van de classe die op het domein markhandels.nl staat wordt geinclude in een php bestand op het domein, zeg sat2d.nl. De classe moet dus dan ook uitgevoerd worden op domein sat2d.nl niet op markhandels.nl. Daarom ook de include. De classe database bevat geen mysql opdrachten, die geef ik later aan de classe mee.

Voor de eenvoud neem gewoon de classe test() die ik in het bovenstaande voorbeeld heb gebruikt. Die staat op markhandels.nl maar ik wil hem gebruiken op sat2d.nl. ALs ik hem echter include krijg ik de error dat de classe niet bestaat.

[Pete]

Wat je nu met je include ophaald is een geparste pagina van je classe. En omdat je classe geen uitvoer heeft is deze pagina helemaal leeg. Kijk zelf maar wat http://system.markhandels.nl/_modules/database.php voor een uitvoer geeft: helemaal niets!

Logisch gezien zou dit natuurlijk ook niet mogen! Stel je voor dat jij in database.php contact maakt met jouw klantendatabase. Als ik dan dezelfde file zou includen zou ik direct toegang hebben tot jouw db. Daarnaast moet iedere keer als er op Domein Y een pagina opgevraagt word, een request gedaan worden naar Domein X. Hierdoor krijg je een niet echt performante webpagina. Ik zou als ik jouw was dus gewoon de source kopieeren naar Domein Y.

[Apache]

Webservices?

[Pete]

Apache schreef op donderdag 02 november 2006 @ 19:46:
Webservices?

Ik denk dat de TS niet bezig is met geavanceerde samenwerkende sites op te zetten, maar dat hij gewoon 'handig' wilde zijn om zijn db-connect classjes ergens anders makkelijk te hergebruiken. Ik zie niet in waarvoor je dan webservices nodig hebt. Je vraag/opmerking slaat dus een beetje een gat in de lucht.

[NMe]

En toch zijn webservices in dit geval een heel stuk beter/handiger dan dit. Daarnaast is jouw eerste reply ook niet zo zinvol aangezien ik al eerder hetzelfde heb gezegd, dus reken andere gebruikers ook hun "zinloze" posts niet aan.

[R0K13]

database.php bevat alleen een classe. Dat hij dus niets laat zien als je hem direct draait is logisch. Ik wil deze classe alleen gaan gebruiken op een ander domein. De classe manipuleert de data alleen. Ik wil dus inderdaad de source van deze pagina includen.

[file: database.php]

<?php

class test() {

var mytext;

function test() {

$this->mytext = "hello world";

}
}

return "OK";

?>


Nu gebruik ik op een ander domein (bijv. sat2d.nl) de volgende code:

<?php

$succes = include_once(http://system.markhandels.nl/_modules/database.php);

$database = new test();

?>

Nu geeft echter $succes al geen 'OK' terug wat betekent dat het includen al niet is gelukt. Logisch dus dat de classe ook niet wordt herkend. Ik vraag me echter af waarom niet?? De link klopt 100%. De bovenstaande links zijn alleen ter illustratie. Waarom zou ik niet files op een andere server kunnen includen of doe ik iets verkeers of moet het anders?

[mrFoce]

R0K13 schreef op donderdag 02 november 2006 @ 20:09:
database.php bevat alleen een classe. Dat hij dus niets laat zien als je hem direct draait is logisch. Ik wil deze classe alleen gaan gebruiken op een ander domein. De classe manipuleert de data alleen. Ik wil dus inderdaad de source van deze pagina includen.

[file: database.php]

<?php

class test() {

var mytext;

function test() {

$this->mytext = "hello world";

}
}

return "OK";

?>


Nu gebruik ik op een ander domein (bijv. sat2d.nl) de volgende code:

<?php

$succes = include_once(http://system.markhandels.nl/_modules/database.php);

$database = new test();

?>

Nu geeft echter $succes al geen 'OK' terug wat betekent dat het includen al niet is gelukt. Logisch dus dat de classe ook niet wordt herkend. Ik vraag me echter af waarom niet?? De link klopt 100%. De bovenstaande links zijn alleen ter illustratie. Waarom zou ik niet files op een andere server kunnen includen of doe ik iets verkeers of moet het anders?

Nogal logisch dat dit niet gaat werken. Anders include ik even de config.php van Tweakers.Net forum en echo ik 'm op m'n eigen site. (passwords e.d.)

Je kan niet cross-site includen. Dit moet via het Filesysteem.

Maar goed, dit is al gezegd. Extern (via http) krijg je de output -> html van de file. Via het filesysteem werkt het wel ( /usr/home/otheruser/site/file.php) bv

[ Voor 5% gewijzigd door mrFoce op 02-11-2006 20:17 ]

[R0K13]

Ik begrijp dat je niet zomaar externe php bestanden kunt includen. Maar ik wil toch graag zoiets realiseren zoals ik hierboven heb beschreven. Hoe moet ik het dan doen? Wat bedoel je precies met een filesysteem?

[Verwijderd]

-NMe- schreef op donderdag 02 november 2006 @ 17:26:
Als PHP op de externe server ook geparset wordt, dan include je een lege file. Wordt PHP daar dus ook geparset of niet?

Bedoel je niet ge-execute of in het Nederlands uitgevoerd?

Het resultaat van een parsering is een token stream (lexical phase) of een syntax tree (syntactical phase). Parsen is niet een woord zoals smurf wat je overal voor kunt gebruiken in algemene betekenis.

[Erkens]

R0K13 schreef op donderdag 02 november 2006 @ 20:27:
Ik begrijp dat je niet zomaar externe php bestanden kunt includen. Maar ik wil toch graag zoiets realiseren zoals ik hierboven heb beschreven. Hoe moet ik het dan doen? Wat bedoel je precies met een filesysteem?

noem de file .txt ipv .php en het zal wel lukken
of .inc, of whatever, zolang het maar niet "uitgevoerd" word

[ Voor 9% gewijzigd door Erkens op 02-11-2006 20:31 ]

[R0K13]

Erkens schreef op donderdag 02 november 2006 @ 20:31:
[...]

noem de file .txt ipv .php en het zal wel lukken
of .inc, of whatever, zolang het maar niet "uitgevoerd" word

Dus als ik het .inc noem dan kan ik hem wel includen en begrijpt php ook dat ik een classe heb toegevoegd?

[Verwijderd]

R0K13 schreef op donderdag 02 november 2006 @ 20:55:
[...]


Dus als ik het .inc noem dan kan ik hem wel includen en begrijpt php ook dat ik een classe heb toegevoegd?

Waarschijnlijk wel, omdat de parsering (en nu is er dus wel sprake van parsering) pas NA de include operatie plaats vind.

Dit is echter wel een heel dom mechanisme en wordt door iedereen die een beetje professioneel bezig is dan ook gemeden als de pest. Het idee bestond vroeger al in C en is een grote bron van problemen en fouten. In JSP bestaat het mechanisme ook, maar ook daar is het nix dan ellende. In JSP heb je dan nog wel tenminste de keuze tussen om een gegeven JSP pagina als code te includen (statische include) of als het resultaat van de executie (dynamische include).

Includen van code is in 99.9% van de gevallen sterk af te raden. Includen van het resultaat (meestal html in de praktijk) is vaak wel handig.

[ Voor 4% gewijzigd door Verwijderd op 02-11-2006 21:08 ]

[Pete]

-NMe- schreef op donderdag 02 november 2006 @ 20:06:
En toch zijn webservices in dit geval een heel stuk beter/handiger dan dit. Daarnaast is jouw eerste reply ook niet zo zinvol aangezien ik al eerder hetzelfde heb gezegd, dus reken andere gebruikers ook hun "zinloze" posts niet aan.

Echter het was aan de reply na jouw post duidelijk dat de boodschap niet overgekomen was bij de TS. Daarnaast legde ik in mijn post iets meer (en imho het iets duidelijker) uit wat we beiden bedoelden.
De opmerking "Webservices?" daarentegen lijkt mij hier totaal niet op zijn plaats en als zou deze op zijn plaats zijn zou deze opmerking alleen maar meer onduidelijkheid scheppen bij de TS. Daarom leek het mij zinvol de TS hiervoor te waarschuwen.

[R0K13]

De reden dat ik classes op een domein X wil includen op een domein Y is omdat ik zo alle classes maar één keer hoef te maken en dan op meerdere websites kan gebruiken. En als ik dan de classes vernieuw dan hoef ik dat maar op een plek te doen en alle websites maken dan in een keer gebruik van de nieuwe classes.

Ik zou de source code van de classes via een .htaccess kunnen beveiligen.

[Erkens]

R0K13 schreef op donderdag 02 november 2006 @ 22:14:
De reden dat ik classes op een domein X wil includen op een domein Y is omdat ik zo alle classes maar één keer hoef te maken en dan op meerdere websites kan gebruiken. En als ik dan de classes vernieuw dan hoef ik dat maar op een plek te doen en alle websites maken dan in een keer gebruik van de nieuwe classes.

Ik zou de source code van de classes via een .htaccess kunnen beveiligen.

denk wel na over de gevolgen hiervan, zodra server X down is weken alle anders sites ook niet meer

[Verwijderd]

R0K13 schreef op donderdag 02 november 2006 @ 22:14:
En als ik dan de classes vernieuw dan hoef ik dat maar op een plek te doen en alle websites maken dan in een keer gebruik van de nieuwe classes.

Sorry hoor, maar dat vind ik echt 1 van de aller domste redenen die ik ooit heb gehoord. Heb je er wel eens over nagedacht dat code dependencies op elkaar heeft? Als een website of web applicatie zomaar een nieuwe versie van een classe krijgt dan kunnen er op tal van plekken dingen fout gaan. Zulke zaken moet je dan ook eerst testen.

De normale gang van zaken is dat je je code in een vcs hebt staan (zoals CVS of SVN) en dat je van daaruit eerst deployed naar een test server en daarna naar een live server. Op die manier staat je code ook centraal, maar kun je wel updates gecontroleerd doorvoeren.

Om nog maar te zwijgen over de performance en robuustheid issues.

Die doe maar raak praktijken van mensen zoals jij zorgen er helaas voor dat PHP'ers zo'n slechte naam hebben onder developers.

[ Voor 3% gewijzigd door Verwijderd op 02-11-2006 22:52 ]

[Janoz]

R0K13 schreef op donderdag 02 november 2006 @ 22:14:
De reden dat ik classes op een domein X wil includen op een domein Y is omdat ik zo alle classes maar één keer hoef te maken en dan op meerdere websites kan gebruiken. En als ik dan de classes vernieuw dan hoef ik dat maar op een plek te doen en alle websites maken dan in een keer gebruik van de nieuwe classes.

Ik zou de source code van de classes via een .htaccess kunnen beveiligen.

Je kunt beter eens wat gaan lezen en uitzoeken over versiebeheer en release managment.

[R0K13]

Verwijderd schreef op donderdag 02 november 2006 @ 22:51:
[...]


Sorry hoor, maar dat vind ik echt 1 van de aller domste redenen die ik ooit heb gehoord. Heb je er wel eens over nagedacht dat code dependencies op elkaar heeft? Als een website of web applicatie zomaar een nieuwe versie van een classe krijgt dan kunnen er op tal van plekken dingen fout gaan. Zulke zaken moet je dan ook eerst testen.

De normale gang van zaken is dat je je code in een vcs hebt staan (zoals CVS of SVN) en dat je van daaruit eerst deployed naar een test server en daarna naar een live server. Op die manier staat je code ook centraal, maar kun je wel updates gecontroleerd doorvoeren.

Om nog maar te zwijgen over de performance en robuustheid issues.

Die doe maar raak praktijken van mensen zoals jij zorgen er helaas voor dat PHP'ers zo'n slechte naam hebben onder developers.

Okeej sorry.

Ik dacht juist dat het een goed idee was. Blijkbaar niet. Het was nooit mijn bedoeling om PHP een slechte naam te geven. Ik denk ook niet dat ik die invloed zal hebben maar ik wil er zeker ook niet aan bijdragen.

Ik zal voortaan beter nadenken voordat ik iets ga uitproberen of ga vragen.

Je hebt gelijk ik ben dom bezig. Ik moet het alleen nog ff zelf inzien.

Nogmaals mijn excuses..

[Infinitive]

Er is op zich niks mis met shared libraries
Alleen het importeren van zo'n library via http werkt niet zomaar en is erg onhandig
In principe staat er niets op tegen om - als de websites op dezelfde server staan - een mapje op de harddisk van de server aan te maken waarbij je gedeelde scripts opslaat (zolang je rechten e.d. maar goed instelt). Let er wel op dat bepaalde instelligen van een specifieke website, zoals een connectiestring naar de database, niet in zo'n shared library thuishoren.

Sterker nog, een goed deployment systeem verzorgt de sharing/isolatie van libraries voor je...
(zoals bijvoorbeeld Nix, maar dat gaat wat offtopic)

[ Voor 126% gewijzigd door Infinitive op 03-11-2006 00:01 ]

[igmar]

R0K13 schreef op donderdag 02 november 2006 @ 17:58:
$GLOBALS['system_path'] = "http://system.markhandels.nl/_modules/";

Omdat je dan een geparsde pagina terug krijgt ? Wel eens gekeken wat je daadwerkelijk inleest ? MAW : debuggen.

[NMe]

Verwijderd schreef op donderdag 02 november 2006 @ 20:30:
[...]

Bedoel je niet ge-execute of in het Nederlands uitgevoerd?

Nee. Het antwoord op die vraag is namelijk in dit geval domweg hetzelfde.

R0K13 schreef op donderdag 02 november 2006 @ 20:55:
[...]

Dus als ik het .inc noem dan kan ik hem wel includen en begrijpt php ook dat ik een classe heb toegevoegd?

Wat let je om zoiets simpels gewoon even uit te proberen?

igmar schreef op vrijdag 03 november 2006 @ 14:49:
[...]

Omdat je dan een geparsde pagina terug krijgt ? Wel eens gekeken wat je daadwerkelijk inleest ? MAW : debuggen.

Pssst, daar waren we al uit.

[Verwijderd]

-NMe- schreef op vrijdag 03 november 2006 @ 14:55:
[...]
Nee. Het antwoord op die vraag is namelijk in dit geval domweg hetzelfde.

Hoezo nee? Parsen is niet hetzelfde als uitvoeren. Ik mag toch hopen dat jij dat weet???

[Verwijderd]

Volgens mij kan je de file op die andere server gewoon opslaan als class.php.txt... dan is hij wel bereikbaar.... maaaaar dan is hij gelijk bereikbaar voor iedereen, dus niet secure.

[Evilbee]

Verwijderd schreef op dinsdag 07 november 2006 @ 10:40:
Volgens mij kan je de file op die andere server gewoon opslaan als class.php.txt... dan is hij wel bereikbaar.... maaaaar dan is hij gelijk bereikbaar voor iedereen, dus niet secure.

Dat kan je wel oplossen met een .htaccess file. En dat kan je het bestand wel includen met de volgende regel:

PHP:

include('http://user:[e-mail]/class.php.txt')