Code mbv. Php in HTML document invoegen

[Oysterhoys]

Ik heb me globaal in Php verdiept.
Ik zou vanuit een HTML bestand een Javascript functie willen aanroepen die niet in de html-file zelf is geschreven, of in een 'gelinkte' script, maar die in bijv. een MySql database ligt opgeslagen, als het ware een soort Java Applet, maar die dan met behulp van Php. wordt aangeroepen
Dit alles als een manier om delen van je code te beschermen.
Kan dit met behulp van Php/MySql ? Ik heb daar mu meer zin om me in te verdiepen dan in Java. Het gaat me nu dus niet om code, maar of zoiets kan en of het ook veilig te maken is.

[gorgi_19]

Zinloos; een javascript functie is clientside en dus in principe moet deze dus op de client bekend zijn.

Je kan zaken javascript code opslaan in de database en deze beschikbaar maken via PHP, maar dan is deze dus ook zichtbaar op de client en is er geen sprake van broncode bescherming, zoals jij wilt.

[ Voor 50% gewijzigd door gorgi_19 op 21-05-2004 12:06 ]

[Bosmonster]

Precies.. Javascript is niet te beveiligen, het is alleen onleesbaar te maken.

Als dit echter je doel is dan vraag ik me alleen al af hoe nuttig je bezig bent, aangezien je belangrijke en beschermde logica natuurlijk nooit in javascript moet zitten

[Oysterhoys]

Als de code 'dynamisch' wordt geladen, draait ie wel op de client,
maar kan de client niet bij de bron komen, was mijn idee.
Klopt dat niet?

[ Voor 7% gewijzigd door Oysterhoys op 21-05-2004 12:10 ]

[BtM909]

Oysterhoys schreef op 21 mei 2004 @ 12:08:
Als de code 'dynamisch' wordt geladen, draait ie wel op de client,
maar kan de client niet bij de bron komen, was mijn idee.
Klopt dat niet?

Nee

Met de adres-balk en source-code kan men alsnog achter de inhoud komen...

[gorgi_19]

Oysterhoys schreef op 21 mei 2004 @ 12:08:
Als de code 'dynamisch' wordt geladen, draait ie wel op de client,
maar kan de client niet bij de bron komen, was mijn idee.
Klopt dat niet?

Wat is jouw definitie van bron? Als de bron de gegenereerde javascript is: daar kan de client gewoon bijkomen.

Als de bron in jouw optiek de database is, dan klopt het; hier kan de client niet bijkomen normaliter.

[Bosmonster]

Oysterhoys schreef op 21 mei 2004 @ 12:08:
Als de code 'dynamisch' wordt geladen, draait ie wel op de client,
maar kan de client niet bij de bron komen, was mijn idee.
Klopt dat niet?

Denk het niet.. maar tis maar een gok want Joost mag weten wat je precies bedoelt

[Kwai_gon_jinn]

Bosmonster schreef op 21 mei 2004 @ 12:10:
[...]


Denk het niet.. maar tis maar een gok want Joost mag weten wat je precies bedoelt

Meneertje Joost wil graag zijn "kostbare" javascript opslaan in de database om het zodanig te beschermen dat het niet zichtbaar is voor de gebruiker

Alleen weet hij niet dat dat niet kan. Echter zoals Bosmonster al eerder zei. je kunt het wel encrypten zodat het niet zichtbaar leesbaar is. Maar wel door de browser word ondersteund/ingelezen&uitgevoerd.

[Oysterhoys]

Als bron zie ik de opgeslagen geschreven code, ergens op een server.
Als die in een Javascript of HTML -file opgeslagen ligt is die niet safe, omdat het adres bekend is.

Ik dacht dat met Java of mbv. een data base, dat dan het adres wel bekend was,
resp. het adres van de Applet of een verwijzing naar een database.

Maar dat 'derden' geen toegang kunnen hebben tot dit adres en deze code om dan te lezen of 'in te pikken'.


p.s. ik zit gewoon met een uit de hand gelopen javascript geval, waar ik een veilige draai aan probeer te geven.

p.s. meneer kwai ... nog meer, moet het zo denigrerend, Got is toch om dingen uit te vinden, als ik alles al wist, hoefde ik het niet te vragen.

[ Voor 15% gewijzigd door Oysterhoys op 21-05-2004 12:20 ]

[gorgi_19]

p.s. ik zit gewoon met een uit de hand gelopen javascript geval, waar ik een veilige draai aan probeer te geven.

Clientside Javascript is niet goed te beveiligen.

[Oysterhoys]

Dat weet ik dus.
Ik vraag me dus af of er 'wel-veilige' ingredienten "in te weven zijn ".

Een Java Applet is toch ook zo'n ingredient ?

[Verwijderd]

Het enige wat je zou kunnen doen is de JavaScript obfuscaten. Dat wil zeggen dat je er een onbegrijpelijke brei van maakt;

code:

var sVoornaam = "";
alert("Hallo, " + sVoornaam);

In bovenstaand voorbeeld is meteen duidelijk dat "sVoornaam" een naam in. Dat je de variabele "sVoornaam" noemt is alleen voor je eigen gemak. De werking wordt er niet anders op als je "sVoornaam" vervangt voor "s".

code:

var s = "";
alert("Hallo, " + s);

Nu is het al een stuk onbegrijpelijker. Dat is precies wat obfuscating inhoudt. Als je grote lappen js code hebt en je vervangt alle variabelnamen, dan blijft er al gauw onbegrijpelijke zooi over...

Om dit te automatiseren zijn programma's, maar die zijn niet gratis.

[Oysterhoys]

Bedankt Jorgen, ik wist het.
Het punt blijft dat de code wel te downloaden is.
Een Java applet is dacht ik toch niet te downloaden ?
Ik zat te filosoferen over een soort veilige "applets', server side, die via Php opgeroepen konden worden uit een veilige database dmv. een functie in het 'onveilige' document .

[Verwijderd]

Oysterhoys schreef op 21 mei 2004 @ 12:31:
Bedankt Jorgen, ik wist het.
Het punt blijft dat de code wel te downloaden is.
Een Java applet is dacht ik toch niet te downloaden ?
Ik zat te filosoferen over een soort veilige "applets', server side, die via Php opgeroepen konden worden uit een veilige database dmv. een functie in het 'onveilige' document .

Het is het veiligst om je javascript dan maar gewoon niet op het internet te zeten.
Applets moeten ook gedownload worden voor ze kunnen worden gebruikt, en die zijn ook te decompilen.

[Verwijderd]

Java applet kan je decompilen

[Tjark]

je zou je javascript ook kunnen escapen

code:

<script language="JavaScript" type="text/javascript">eval(unescape('%76%61%72%20%61%64%64%72%20%3d%20%27%25%36%64%25%36%31%25%36%39%25%36'));</script>

dan is het voor een noob niet te lezen.

Maar natuurlijk is het eenvoudig te unescapen en dan is het wel leesbaar, maar noobs kunnen dat niet.

nadeel is wel dat het script veel langer wordt (meer download), maar met gzip apache compression valt het wel weer mee, maar 't blijft meer.

[ Voor 24% gewijzigd door Tjark op 21-05-2004 12:44 ]

[Oysterhoys]

Als Php NOOB,
Het handige van Php is toch juist dat je server side 'acties' kan plegen. ?!
Ik begreep ook dat je php commando's kon intergreren in .html pagina's.

Is er niet een soort Php commando:
Voer code-x , uit database-y uit in dit document en die code-x, is dan html/of javascript code.

beetje het idee als met het Javascript commando: eval ( " functie .....")

Sorry als dit allemaal te dom gedacht is.

[ Voor 6% gewijzigd door Oysterhoys op 21-05-2004 12:52 ]

[miw]

gorgi_19 schreef op 21 mei 2004 @ 12:18:
[...]

Clientside Javascript is niet goed te beveiligen.

Ook hier is enige nuance vereist. Software obfuscation is namelijk best in staat om een behoorlijke bescherming te realiseren. Deze techniek wordt ook gebruikt in DRM implementaties die op een PC moeten draaien. Uiteraard is reverse engineering in principe mogelijk, maar bij gebruik van state of the art obfuscation tools is dat niet eenvoudig. Als je aanneemt dat elke beveiliging te breken is, moet je afwegen of de gevolgen van een aanval te dragen zijn. Als die gevolgen niet acceptabel zijn, lijkt software obfuscation een zinloze optie. Als het slechts vervelend is als de source code door iemand achterhaald wordt, kan je obfuscation overwegen.

[Verwijderd]

Je denkt totaal verkeerd. De PHP engine kan inderdaad gegevens uit bestanden of databases halen. Maar wet PHP teruggeeft aan de client, is één document. En alles wat daarin staat moet gewoon kunnen werken. Alle javascript functies moeten erin staan, of als het losse javascript documenten betreft, een link naar die documenten.

Alles moet dus toegankelijk zijn voor de client. Hoe kan een browser nou javascript code uitvoeren als hij het niet zou mogen downloaden?

[NMe]

Oysterhoys schreef op 21 mei 2004 @ 12:31:
Bedankt Jorgen, ik wist het.
Het punt blijft dat de code wel te downloaden is.
Een Java applet is dacht ik toch niet te downloaden ?
Ik zat te filosoferen over een soort veilige "applets', server side, die via Php opgeroepen konden worden uit een veilige database dmv. een functie in het 'onveilige' document .

Het kan gewoon niet. Punt. Javascript is client side. Om dat te gebruiken moet je op de een of andere manier een verwijzing naar je script (in de vorm van een applet) of je script zelf, al dan niet ge-escapet of gecodeerd, in je HTML opnemen.
PHP is server sided, dus die zou je wel die Javascript voor je uit de database kunnen laten halen en dan "beveiligd" (op de manieren die de mensen boven mij uitgelegd hebben) afdrukken, maar veel meer kun je niet doen. Je moet gewoon dingen die beveiligd moeten worden in PHP regelen, en niet in Javascript.

[Oysterhoys]

Als een php document data uit een database opvraagt en die naar de browser stuurt om te verwerken opeen of andere wijze, betekent dat toch niet dat diezelfde data door iedereen op zijn eigen pc gezet kunnen worden.

Het wordt toch ook niet afgedrukt door de browser als die de data geleverd krijgt vanuit de database.

[ Voor 21% gewijzigd door Oysterhoys op 21-05-2004 13:11 ]

[NMe]

Oysterhoys schreef op 21 mei 2004 @ 13:08:
Als een php document data uit een database opvraagt en die naar de browser stuurt om te verwerken opeen of andere wijze, betekent dat toch niet dat diezelfde data door iedereen op zijn eigen pc gezet kunnen worden.

Jawel... Als je HTML naar een browser stuurt dan betekent dat per definitie dat het gedownload wordt en dus al op die eigen pc staat.

[ Voor 17% gewijzigd door NMe op 21-05-2004 13:11 ]

[gorgi_19]

Oysterhoys schreef op 21 mei 2004 @ 13:08:
Als een php document data uit een database opvraagt en die naar de browser stuurt om te verwerken opeen of andere wijze, betekent dat toch niet dat diezelfde data door iedereen op zijn eigen pc gezet kunnen worden.

Het wordt toch ook niet afgedrukt door de browser als die de data geleverd krijgt vanuit de database.

Ik denk dat je eens het verschil moet gaan onderzoeken tussen serverside en clientside. PHP genereert een serverside een stuk clientside code. Je ziet dus neit alle code (de serverside niet), maar de clientside code is gewoon te kopieren.

Alles wat je naar de client stuurt, is onveilig. Java applets dan je decompilen, javascript, obfuscated of niet, is te achterhalen en uit te pluizen.

[Oysterhoys]

Wat is er dan veilig aan Php ??????

Client /Server side hangt toch af van op welke plaats commando's worden uitgevoerd ?!!!!

Mijn hele idee is nou juist, met php aan de server site ( waarvan ik dacht dat het de veilige kant was) code op te halen die aan de client site ( lees browser) uitgevoerd worden, onzichtbaar en onbereikbaar voor 'derden'

Maar volgens NME 84 kan iedere slimmerik erbij als de browser er ook bij kan.

[ Voor 90% gewijzigd door Oysterhoys op 21-05-2004 13:22 ]

[gorgi_19]

Oysterhoys schreef op 21 mei 2004 @ 13:14:
Wat is er dan veilig aan Php ??????

Even terug naar het begin:

ASP:

Response.Write "Hello world"
Response.Write "<script>alert('hoi');</script>"

Levert op de client op

HTML:

Hello world
<script>alert('hoi');</script>

Vanuit dit principe kan je doorredeneren.

[ Voor 14% gewijzigd door gorgi_19 op 21-05-2004 13:16 ]

[NMe]

Oysterhoys schreef op 21 mei 2004 @ 13:14:
Wat is er dan veilig aan Php ??????

*sigh*

PHP is veilig omdat de server het uitvoert, en niet de client (dus degene die je site bezoekt). Je client krijgt die code niet te zien dus zelfs al zou je hard-coded wachtwoorden erin verwerken dan is dat relatief veilig.

JavaScript is clientside -> wordt gedownload en geïnterpreteerd door de browser van je bezoeker -> dus wordt het beschikbaar en leesbaar voor de gebruiker.

Mag ik je aanraden wat te Googlen?

edit:
@gorgi: misschien had je beter PHP code kunnen laten zien?

* gorgi_19 snapt 0,0 van PHP

ASP.NET Visual Basic:

Response.Write "Hello world"
Response.Write "<script>alert('hoi');</script>"

is in PHP:

PHP:

echo "Hello world";
echo "<script>alert('hoi');</script>";

[ Voor 24% gewijzigd door NMe op 21-05-2004 13:24 ]

[gorgi_19]

NMe84 schreef op 21 mei 2004 @ 13:19:

edit:
@gorgi: misschien had je beter PHP code kunnen laten zien?

* gorgi_19 snapt 0,0 van PHP

En ontopic:
Ik krijg een beetje ideeen dat het exact dezelfde kant op gaat als in je vorige topic; Broncode bescherming

Alles wat daar is gezegd is hierbij zo ongeveer ook geldig, aangezien je in principe hetzelfde doet.

[Oysterhoys]

Ik hoopte dus op een soort:

Response.Execute "<script>alert('hoi');</script>"

[gorgi_19]

Oysterhoys schreef op 21 mei 2004 @ 13:25:
Ik hoopte dus op een soort:

Response.Execute "<script>alert('hoi');</script>"

Dat kan niet; je kan serverside geen clientside zaken uitvoeren.

[ Voor 9% gewijzigd door gorgi_19 op 21-05-2004 13:27 ]

[Oysterhoys]

gorgi, je hebt een punt over dat ene topic.
Alleen schoot me nu dit alternatief te binnen, toch wel wat anders.

[NMe]

Oysterhoys schreef op 21 mei 2004 @ 13:26:
gorgi, je hebt een punt over dat ene topic.
Alleen schoot me nu dit alternatief te binnen, toch wel wat anders.

Nee het is praktisch hetzelfde.

Maar misschien kun je een beetje vertellen wat je precies wil bereiken met Javascript? Misschien kunnen we je helpen en een beetje uitleggen hoe datzelfde in PHP kan, als dat mogelijk is.

[Oysterhoys]

Sorry Boys, Bedankt voor het geduld.
Ik waardeer het zeer.

Is het in principe mogelijk om een HTML-bestand met allerlei 'onveilige' Javascript om te zetten naar een 'veilige' PHP uitvoering ervan met vergelijkbare functionaliteit ?

Ik zal jullie zo direct een linkje geven waar het om gaat, het is dus nu makkelijk te stelen, maar goed waarschijnlijk niet interessant voor jullie wizards.

[NMe]

Oysterhoys schreef op 21 mei 2004 @ 13:38:
Sorry Boys, Bedankt voor het geduld.
Ik waardeer het zeer.

Is het in principe mogelijk om een HTML-bestand met allerlei 'onveilige' Javascript om te zetten naar een 'veilige' PHP uitvoering ervan met vergelijkbare functionaliteit ?

Ik zal jullie zo direct een linkje geven waar het om gaat, het is dus nu makkelijk te stelen, maar goed waarschijnlijk niet interessant voor jullie wizards.

In principe is het wel mogelijk, alleen vergen sommige dingen die je in Javascript doet, zoals het verplaatsbaar maken van sommige elementen, het herladen van de pagina. Maar dergelijke dingen kun je best in Javascript laten staan, want dat is geen beveiligingsrisico.

[Oysterhoys]

het heeft nog wat schoonheidsfoutjes, maar jij komt er wel uit.

[ Voor 89% gewijzigd door Oysterhoys op 21-05-2004 14:03 ]

[NMe]

Waarom wil je iets dergelijks beveiligen? Het is alleen maar het verslepen van content, die bij een refresh nog weg valt ook. Ik kan me voorstellen dat je dit als een soort van design-test script wil gebruiken, waarom beveilig je het dan niet gewoon via .htaccess en .htpasswd zodat alleen gemachtigde gebruikers eraan kunnen?

[Oysterhoys]

Ik zal het nog een keer aan voor je zetten en wat meer uitleggen.

1) werkt voorlopig alleen in IE 6.0
2) niet refreshen

[ Voor 63% gewijzigd door Oysterhoys op 21-05-2004 14:02 ]

[Kwai_gon_jinn]

Oysterhoys schreef op 21 mei 2004 @ 12:16:
...
p.s. meneer kwai ... nog meer, moet het zo denigrerend, Got is toch om dingen uit te vinden, als ik alles al wist, hoefde ik het niet te vragen.

Heh mijn excuses Maar je omschrijving was wat onduidelijk, beetje fun terug gereageerd op die van Bosmonster, nogmaals excuses. Beide vriendjes


Mag ik vragen wat je "precies" wil hebben, ipv een lang vaag verhaal erom heen. Misschien kunnen we jou idee verhelderen dan je in een vage kant op sturen.

Wat ik zo verre uit je posts op uit maak is dat je de kracht van PHP niet echt ziet. (hee ASP fans nie schreeuwen hij wil zich gediepen in PHP ). Maar iig in simpelere woorden.

Alles wat je op je beeldscherm ziet op een webpagina bestaan over het algemeen uit wat jij noem HTML "bron" wat schijnbaar niet veilig blijkt te zijn uit je posts in combinatie van javascript. (weer een vage omschrijving)

Vb.

Je bent op een contact pagina en je wilt iemand mailen, maar er staat geen mail adres zichtbaar in de bron (rechtermuisknop -> bron weergeven). Maar als je op het "mail me" knopje drukt krijg je netjes je mailclient venster met tik-je-mailtje-maar-in. Waarin netjes het mail adres in staat van de beheerder.

infeite kan het dus zo gaan:
klik(knopje) -> PHP zegt: "haal adres uit de database" -> MySQL zegt: "Okee hier het adresje meneer PHP" -> PHP zegt: "dankje wel"

Dus. adres staat niet in de bron maar wel in de database.


Zoiets helder ?

( beetje flauw op m'n stage en vage berichten aan het tikken, mijn excuses )

[Oysterhoys]

o.k. vriendjes.
Helder uitgelegd.
Ik hoopte dus uit de database 'executable code' te halen die
dus in de html-bron niet zichtbaar is, omdat de werkelijke bron niet het html bestand is, maar de database

[ Voor 17% gewijzigd door Oysterhoys op 21-05-2004 14:09 ]

[intermusic]

NMe84 schreef op 21 mei 2004 @ 13:19:
[...]

*sigh*

PHP is veilig omdat de server het uitvoert, en niet de client (dus degene die je site bezoekt). Je client krijgt die code niet te zien dus zelfs al zou je hard-coded wachtwoorden erin verwerken dan is dat relatief veilig.

Eingelijk zet je die wachtwoorden (voor de DB enz.)toch altijd zo in je PHP bestand? (hard-coded)
Is er een andere manier dan?

[Kwai_gon_jinn]

intermusic schreef op 21 mei 2004 @ 14:10:
[...]


Eingelijk zet je die wachtwoorden (voor de DB enz.)toch altijd zo in je PHP bestand? (hard-coded)
Is er een andere manier dan?

hard coded wachtwoorden is voor 99% het geval niet echt veilig. meerdere manieren mogelijk waarbij meestal een database achterhangt.

Oysterhoys schreef op 21 mei 2004 @ 14:08:
o.k. vriendjes.
Helder uitgelegd.
Ik hoopte dus uit de database 'executable code' te halen die
dus in de html-bron niet zichtbaar is, omdat de werkelijke bron niet het html bestand is, maar de database

executable code? In feite "execute" je PHP script het en haal je data uit de database. Voorbeeldje:

- pakken we MSN erbij, drukt men rechtermuisknop op een maatje in je MSN lijst. Dan kan men kiezen "profiel weergeven"

wat jij als rechtermuisknop dialoog ziet... is infeit de HTML pagina (okee wijsneuzen, hier kun je de bron niet zien ).

- Zodra je erop klikt, opent het een nieuw browser venster (IE meestal ) en haalt hij de profiel pagina van je maatje op en toont het

In je "niet zichtbare" PHP code (executable code) haalt bijv gevens op van je maatje uit een database en toont dat.

[NMe]

Oysterhoys schreef op 21 mei 2004 @ 14:08:
o.k. vriendjes.
Helder uitgelegd.
Ik hoopte dus uit de database 'executable code' te halen die
dus in de html-bron niet zichtbaar is, omdat de werkelijke bron niet het html bestand is, maar de database

Dat kan dus helaas niet, wel kun je de beveiligingsmethodes proberen die hierboven al vaker genoemd zijn. PHP kan niet wat jij wil ben ik bang, omdat voor elke keer dat je de layout aanpast een refresh nodig zou zijn.

intermusic schreef op 21 mei 2004 @ 14:10:
[...]


Eingelijk zet je die wachtwoorden (voor de DB enz.)toch altijd zo in je PHP bestand? (hard-coded)
Is er een andere manier dan?

Neuh, probeerde gewoon aan te geven dat je dat gewoon zonder enig (groot) beveiligingsprobleem kon doen.

Kwai_gon_jinn schreef op 21 mei 2004 @ 14:16:
hard coded wachtwoorden is voor 99% het geval niet echt veilig. meerdere manieren mogelijk waarbij meestal een database achterhangt.

Hij had het over de databasewachtwoorden zelf.

[ Voor 16% gewijzigd door NMe op 21-05-2004 14:20 ]

[Oysterhoys]

quote van Kwai
"In je "niet zichtbare" PHP code (executable code) haalt bijv gevens op van je maatje uit een database en toont dat."

( ik weet de normale quote-wijze op Got Niet )

Ik begrijp dus dat je wel 'data' maar geen 'uitvoerbare functies' kan ophalen

Moet je trouwens altijd een aparte .php file hebben of kun je
php-functies ook intergreren in een gewoon .html bestand.


NMe 84:
Je hebt het nu dus beter kunnen bekijken, maar je kan dat dus niet zomaar met PHP uitvoeren

[ Voor 61% gewijzigd door Oysterhoys op 21-05-2004 14:37 ]

[Pastinakel]

Wat je nog kan gebruiken om "scoop & run" -diefjes om de tuin te leiden: een php-script dat geincluded wordt in je pagina en bij een ontbrekende $_SERVER['HTTP_REFERER'] een net even andere javascript-code terug geeft:

index.html:

code:

<HTML>
...
<HEAD>
<SCRIPT LANGUAGE="JavaScript" SRC="js.php"></SCRIPT>
</HEAD>
...
</HTML>

js.php:

code:

<?PHP
...
echo "javascriptbla;\n";
if (eregi( "^http://www.mijnserver.nl/", $_SERVER['HTTP_REFERER'] )) {
  echo "code;\n"; // dit gaat werken
}
else {
  echo "c0de;\n"; // dit gaat niet werken want hier staat een nul
}
echo "javascriptbla;\n";
...
?>

Het is geen waterdichte methode maar maakt het wel iets moeilijker je code te jatten. Iemand die de url van js.php in zijn browser intypt, krijgt nu niet-werkende code terug.

Edit: ja kan er natuurlijk ook voor kiezen om helemaal geen code terug te geven of zwaar verminkte code. Daarmee geef je minder uit handen maar is het wel sneller duidelijk dat je de boel zit te flessen. Het mooiste is natuurlijk code waar ogenschijnlijk niks mis mee is, die geen foutmelding in een debugger genereert maar geenszins doet wat er moet gebeuren.

[ Voor 27% gewijzigd door Pastinakel op 21-05-2004 14:54 ]

[NMe]

Oysterhoys schreef op 21 mei 2004 @ 14:30:
quote van Kwai
"In je "niet zichtbare" PHP code (executable code) haalt bijv gevens op van je maatje uit een database en toont dat."

( ik weet de normale quote-wijze op Got Niet )

Op het quote () knopje bij een post drukken.

Oysterhoys schreef op 21 mei 2004 @ 14:30:
Ik begrijp dus dat je wel 'data' maar geen 'uitvoerbare functies' kan ophalen

Jawel, dat kan wel, maar dan worden ze ook gewoon in de HTML afgedrukt, dus je wint er niets mee.

Oysterhoys schreef op 21 mei 2004 @ 14:30:
Moet je trouwens altijd een aparte .php file hebben of kun je
php-functies ook intergreren in een gewoon .html bestand.

Op de meeste servers moeten je bestanden inderdaad gewoon een .php extensie hebben. Sommige servers detecteren zelf of je PHP gebruikt, maar daar kun je beter niet van uit gaan.

Oysterhoys schreef op 21 mei 2004 @ 14:30:
NME84:
Je hebt het nu dus beter kunnen bekijken, maar je kan dat dus niet zomaar met PHP uitvoeren

Het kan wel, maar het is niet praktisch om het te doen.

edit:
Ik zou de methode die Pastinakel hier boven me gebruikt proberen, dat lijkt me het veiligste wat je kan bereiken zonder functionaliteit te verliezen.

[ Voor 8% gewijzigd door NMe op 21-05-2004 14:42 ]

[Kwai_gon_jinn]

Oysterhoys schreef op 21 mei 2004 @ 14:30:
quote van Kwai
"In je "niet zichtbare" PHP code (executable code) haalt bijv gevens op van je maatje uit een database en toont dat."

( ik weet de normale quote-wijze op Got Niet )

Ik begrijp dus dat je wel 'data' maar geen 'uitvoerbare functies' kan ophalen

Moet je trouwens altijd een aparte .php file hebben of kun je
php-functies ook intergreren in een gewoon .html bestand.


NMe 84:
Je hebt het nu dus beter kunnen bekijken, maar je kan dat dus niet zomaar met PHP uitvoeren

voorbeeldjes geven is leuk, hoppa nog maar 1;

PHP:

echo "dit zie je wel in je HTML";

$result = mysql_query("select * from database where id = '1';"); // <-- dit zie je niet
$row = mysql_fetch_object($result); // <-- zie je ook niet

echo $row->id; // <-- dit zie je weer wel

toelichting
regel 1 ziet je op de HTML pagina "dit zie je wel in je HTML"
regel 3 word niet getoont op je HTML pagina (execute code)
regel 4 word ook niet getoont op je HTML pagina (execute code)
regel 6 resultaat van regel 3&4 word getoont op de pagina, in dit geval 1

resultaat
Dit zie je op je HTML pagina

code:

dit zie je wel in je HTML 1

offtopic:
dit topic begint een beetje dicht te slibben met een wat ijzerwaar straks

[Oysterhoys]

Pastinakel, interesting : wacht effe, ik ben hard aan het nadenken om het te begrijpen.

Pastinakel schreef op 21 mei 2004 @ 14:40:


js.php:

code:

<?PHP
...
echo "javascriptbla;\n";
if (eregi( "^http://www.mijnserver.nl/", $_SERVER['HTTP_REFERER'] )) {
  echo "code;\n"; // dit gaat werken
}
else {
  echo "c0de;\n"; // dit gaat niet werken want hier staat een nul
}
echo "javascriptbla;\n";
...
?>

qua syntax,
zou het dus zoiets kunnen zijn ?!

code:

if (eregi( "^http://www.mijnserver.nl/", $_SERVER['HTTP_REFERER'] )) {
  echo "function test(){window.alert("hello"};\n"; // dit gaat werken
}

Begrijp ik het ook goed, dat waneer iemand naar het adres surft:
hij de foute code op het scherm ziet, maar als hij naar de bron kijkt ( als dat net zo kan als bij .html files, via menu of rechtermuisknop) ziet hij wel de if - else constructie ziet

[ Voor 144% gewijzigd door Oysterhoys op 21-05-2004 15:15 ]

[NMe]

Oysterhoys schreef op 21 mei 2004 @ 14:53:
Pastinakel, interesting : wacht effe, ik ben hard aan het nadenken om het te begrijpen.

Het stelt niet zoveel voor, wat hij in feite doet is kijken OF degene die het opvraagt daadwerkelijk via jouw server komt, en zo ja, dan laat je gewoon dat script afdrukken, zo nee dan druk je niks af. Ik zou het alleen een beetje herschrijven:

PHP:

$allowed = array("index.html", "blaat.html");
$mijndomein = "http://www.jouwdomein.nl/";

echo "javascriptbla;\n";

if ((substr($_SERVER['HTTP_REFERER'], 0, strlen($mijndomein)) == $mijndomein) 
     and in_array(substr($_SERVER['HTTP_REFERER'], strlen($mijndomein) + 1), $allowed)) {
  echo "code;\n"; // dit gaat werken
}
else {
  echo "c0de;\n"; // dit gaat niet werken want hier staat een nul
}

echo "javascriptbla;\n";

Op deze manier werken alleen bepaalde pagina's op jouw domein, wel zo handig als je bijvoorbeeld bijvoorbeeld je site bij Lycos host.

@Pastinakel: waarom gebruik je eregi? Regular expressions zijn trager en hier heb je ze niet nodig.

Oysterhoys schreef op 21 mei 2004 @ 14:53:
qua syntax,
zou het dus zoiets kunnen zijn ?!

code:

if (eregi( "^http://www.mijnserver.nl/", $_SERVER['HTTP_REFERER'] )) {
  echo "function test(){window.alert("hello"};\n"; // dit gaat werken
}

Daar moet je dan uiteraard wel het domein naar jouw domein veranderen.

[ Voor 25% gewijzigd door NMe op 21-05-2004 15:08 ]

[Oysterhoys]

als Php nOOb;
Duidt dat echo niet slechts op direct afbeelden op het scherm,
of wordt de 'code' met deze methode net als een gewoon extern .js bestand geladen in de browser
voor toekomstig gebruik.

[NMe]

Oysterhoys schreef op 21 mei 2004 @ 15:13:
als Php nOOb;
Duidt dat echo niet slechts op direct afbeelden op het scherm,
of wordt de 'code' met deze methode net als een gewoon extern .js bestand geladen in de browser
voor toekomstig gebruik.

Het wordt gewoon afgedrukt in dat bestand. En dat bestand wordt weer geinclude door je HTML. Wat dus inhoudt dat je het als een gewoon extern Javascript kan gebruiken.

[Pastinakel]

Oysterhoys schreef op 21 mei 2004 @ 14:53:
Pastinakel, interesting : wacht effe, ik ben hard aan het nadenken om het te begrijpen.
[...]
qua syntax,
zou het dus zoiets kunnen zijn ?!

code:

if (eregi( "^http://www.mijnserver.nl/", $_SERVER['HTTP_REFERER'] )) {
  echo "function test(){window.alert("hello"};\n"; // dit gaat werken
}

Dat kan ja maar dan is het voor de dief meteen duidelijk dat 'ie geflest wordt. Nogmaals: het is geen waterdichte methode, het is zonder veel moeite mogelijk een referer te faken. Ik zou proberen te voorkomen dat de dief doorkrijgt dat de code gewijzigd wordt.

code:

if (eregi( "^http://www.mijnserver.nl/", $_SERVER['HTTP_REFERER'] )) {
  echo "function test(){window.alert("hello"};\n"; // dit gaat werken
}
else {
  exit; // redelijk duidelijk: je krijgt een leeg document terug
  echo "Gaat heen snoodaard.\n"; // wel heel duidelijk
  echo "function test(){window.close("hello"};\n"; // werkt niet
}

Die laatste zou ik kiezen: syntactisch klopt het maar het script doet niet wat het moet doen. Met een beetje geluk piekert de dief zich suf waarom hij de gejatte code niet werkend krijgt.

NMe84 schreef op 21 mei 2004 @ 15:06:
[...]
@Pastinakel: waarom gebruik je eregi? Regular expressions zijn trager en hier heb je ze niet nodig.
[...]

Dat leek me duidelijker om uit te leggen wat ik bedoelde. Je hebt gelijk: jouw code is sneller.

[ Voor 17% gewijzigd door Pastinakel op 21-05-2004 15:21 ]

[Oysterhoys]

Pastinakel schreef op 21 mei 2004 @ 15:16:
[...]

code:

else {
  exit; // redelijk duidelijk: je krijgt een leeg document terug
  echo "Gaat heen snoodaard.\n"; // wel heel duidelijk
  echo "function test(){window.close("hello"};\n"; // werkt niet
}

Met leeg document terug bedoel je dat het scherm leeg is als je naar de file surft, of dat het bestand leeg is als je naar de bron kijkt.(als dat net zo als bij .html kan via menu of rechtermuisknop)

[ Voor 17% gewijzigd door Oysterhoys op 21-05-2004 15:23 ]

[Kwai_gon_jinn]

Oysterhoys schreef op 21 mei 2004 @ 15:21:
[...]


Met leeg document terug bedoel je dat het scherm leeg is als je naar de file surft, of dat het bestand leeg is als je naar de bron kijkt.(als dat net zo als bij .html kan via menu of rechtermuisknop)

lege file maw staat niks in je HTML bron noch in het bestand qua output (wel IE generate <html> bla bla meuk )

Maar nu kauwen we je code voor, is nie de bedoeling

[Oysterhoys]

Niemand hoeft iets voor te kauwen !!!!!!!!!

Ik ben erg blij met de respons op mijn probleem,

dit is een interessante optie.
maar ik probeer 'on the fly' een oplossing te begrijpen via code op een mij volkomen nieuw terrein.


p.s. sorry Kwai, door al het gepeins, kom ik niet aan jouw suggestie toe.

[ Voor 24% gewijzigd door Oysterhoys op 21-05-2004 15:41 ]

[gorgi_19]

* gorgi_19 gaat eens een slotje smeden voor dit topic. Ik heb het een tijdje aangekeken, maar we zijn nu redelijk op of onder het basisniveau terecht gekomen.

Wil je een uitgebreide uitleg hiervan over het verschil tussen clientside en serverside, dan kan je eens kijken op fora als www.beginnersweb.nl De meeste opties die mogelijk zijn, zijn al besproken.

Met de eerder genoemde links en opmerkingen in het topic moet je wel een eind kunnen komen. succes.

[ Voor 7% gewijzigd door gorgi_19 op 21-05-2004 15:51 ]