Bekijk Volledige Versie : code wel of niet tonen afhankelijk van referring domein?
Hallo,
Kan iemand mij zeggen of het mogelijk is om een stukje HTML code (of ssi)
wel of niet te tonen afhankelijk van het refering domein? Dus bijvoorbeeld,
als de referrer ebay.nl is dan wordt het stukje HTML code (bijvoorbeeld een
tabel met een tekst) wel getoond, maar in ieder ander geval wordt de code
niet getoond of wordt er een andere code getoond. Is een dergelijke
if-then-else statement mogelijk in HTML? Zo ja, hoe doe ik dit?
Groeten,
Rik.
Daniel Tryba
26/05/03, 21:05
Rik <rik@removethis.globalinsites.nl> wrote:
> Kan iemand mij zeggen of het mogelijk is om een stukje HTML code (of ssi)
> wel of niet te tonen afhankelijk van het refering domein? Dus bijvoorbeeld,
> als de referrer ebay.nl is dan wordt het stukje HTML code (bijvoorbeeld een
> tabel met een tekst) wel getoond, maar in ieder ander geval wordt de code
> niet getoond of wordt er een andere code getoond. Is een dergelijke
> if-then-else statement mogelijk in HTML? Zo ja, hoe doe ik dit?
In HTML? Bedoel je daarmee clientside javascript? Dan ben je hier
verkeert en moet je het eens in niwo vragen hoe dat precies werkt (hint:
document.referrer).
Met SSI/CGI kan dat op de server in iedergeval wel gebeuren. Hoe je dat
doet is natuurlijk van wat je voor een SSI/CGI engine tot beschikking
hebt. Maar helaas heb je zulke informatie niet gegeven.
BTW je weet wel dat de referrer header absoluut niet betrouwbaar is!
--
Daniel Tryba
Hoi Daniel,
> > Kan iemand mij zeggen of het mogelijk is om een stukje HTML code (of
ssi)
> > wel of niet te tonen afhankelijk van het refering domein? Dus
bijvoorbeeld,
> > als de referrer ebay.nl is dan wordt het stukje HTML code (bijvoorbeeld
een
> > tabel met een tekst) wel getoond, maar in ieder ander geval wordt de
code
> > niet getoond of wordt er een andere code getoond. Is een dergelijke
> > if-then-else statement mogelijk in HTML? Zo ja, hoe doe ik dit?
>
> In HTML? Bedoel je daarmee clientside javascript? Dan ben je hier
> verkeert en moet je het eens in niwo vragen hoe dat precies werkt (hint:
> document.referrer).
Nee, ik bedoel geen javascript. Ik wil gewoon een stukje HTML code wel of
niet tonen. Zoiets als dit bijvoorbeeld:
<table width="552" height="37" border="0" cellpadding="0"
cellspacing="0" bgcolor="#000000">
<tr>
<td align="center"><table width="550" height="35" border="0"
cellpadding="0" cellspacing="0" bordercolor="#666666"
style="border-collapse: collapse">
<tr>
<td width="40" align="center" bordercolor="********"
bgcolor="#CCCCCC"><img src="images/logo.gif"></td>
<td bgcolor="#CCCCCC"><p align="center"><a
href="http://www.mijnsite.com">
<b><font face="Verdana, Arial, Helvetica, sans-serif" size="2"
color="#CC0000">Hier een tekstlink</font></b></a></td>
</tr>
</table></td>
</tr>
</table>
> Met SSI/CGI kan dat op de server in iedergeval wel gebeuren. Hoe je dat
> doet is natuurlijk van wat je voor een SSI/CGI engine tot beschikking
> hebt. Maar helaas heb je zulke informatie niet gegeven.
SSI en CGI zijn beide geen probleem voor mijn server.
> BTW je weet wel dat de referrer header absoluut niet betrouwbaar is!
Nee, maar nu wel? ;-) Het is in dit geval niet een heel groot probleem als
het niet super betrouwbaar is.
Ik heb wat ervaring met SSI, maar wat moet ik doen om de code voor een
bepaald referring domain wel te tonen en voor alle andere niet?
Groeten,
Rik.
Rik wrote:
> Hoi Daniel,
>
>>> Kan iemand mij zeggen of het mogelijk is om een stukje HTML code
>>> (of ssi) wel of niet te tonen afhankelijk van het refering domein?
>>> Dus bijvoorbeeld, als de referrer ebay.nl is dan wordt het stukje
>>> HTML code (bijvoorbeeld een tabel met een tekst) wel getoond, maar
>>> in ieder ander geval wordt de code niet getoond of wordt er een
>>> andere code getoond. Is een dergelijke if-then-else statement
>>> mogelijk in HTML? Zo ja, hoe doe ik dit?
>>
>> In HTML? Bedoel je daarmee clientside javascript? Dan ben je hier
>> verkeert en moet je het eens in niwo vragen hoe dat precies werkt
>> (hint: document.referrer).
>
> Nee, ik bedoel geen javascript. Ik wil gewoon een stukje HTML code
> wel of niet tonen. Zoiets als dit bijvoorbeeld:
>
> <table width="552" height="37" border="0" cellpadding="0"
> cellspacing="0" bgcolor="#000000">
> <tr>
> <td align="center"><table width="550" height="35"
> border="0" cellpadding="0" cellspacing="0" bordercolor="#666666"
> style="border-collapse: collapse">
> <tr>
> <td width="40" align="center" bordercolor="********"
> bgcolor="#CCCCCC"><img src="images/logo.gif"></td>
> <td bgcolor="#CCCCCC"><p align="center"><a
> href="http://www.mijnsite.com">
> <b><font face="Verdana, Arial, Helvetica, sans-serif"
> size="2" color="#CC0000">Hier een tekstlink</font></b></a></td>
> </tr>
> </table></td>
> </tr>
> </table>
>
>> Met SSI/CGI kan dat op de server in iedergeval wel gebeuren. Hoe je
>> dat doet is natuurlijk van wat je voor een SSI/CGI engine tot
>> beschikking hebt. Maar helaas heb je zulke informatie niet gegeven.
>
> SSI en CGI zijn beide geen probleem voor mijn server.
>
>> BTW je weet wel dat de referrer header absoluut niet betrouwbaar is!
>
> Nee, maar nu wel? ;-) Het is in dit geval niet een heel groot
> probleem als het niet super betrouwbaar is.
>
> Ik heb wat ervaring met SSI, maar wat moet ik doen om de code voor een
> bepaald referring domain wel te tonen en voor alle andere niet?
Hier staat wat Perl code:
http://www.fdhosting.com/support/tutorials/perl_security.php
Negeer dat het over veiligheid gaat, want dat gaat het natuurlijk niet
(het is net zo veilig als je huis beveiligen door een bordje op te
hangen met 'hier mag je niet naar binnen' )
Mark
Daniel Tryba
26/05/03, 23:05
Rik <rik@removethis.globalinsites.nl> wrote:
>> Met SSI/CGI kan dat op de server in iedergeval wel gebeuren. Hoe je dat
>> doet is natuurlijk van wat je voor een SSI/CGI engine tot beschikking
>> hebt. Maar helaas heb je zulke informatie niet gegeven.
>
> SSI en CGI zijn beide geen probleem voor mijn server.
SSI en CGI zijn niet meer dan afkortingen.
>> BTW je weet wel dat de referrer header absoluut niet betrouwbaar is!
>
> Nee, maar nu wel? ;-) Het is in dit geval niet een heel groot probleem als
> het niet super betrouwbaar is.
>
> Ik heb wat ervaring met SSI, maar wat moet ik doen om de code voor een
> bepaald referring domain wel te tonen en voor alle andere niet?
Ik heb nog steeds geen idee wat in jou belevingswereld SSI en CGI
inhoud. Kom eens met iets concreets zoals naam en versie van webserver
en eventueel extra geinstalleerde plugins/modules :)
--
Daniel Tryba
Daniel,
> >> Met SSI/CGI kan dat op de server in iedergeval wel gebeuren. Hoe je dat
> >> doet is natuurlijk van wat je voor een SSI/CGI engine tot beschikking
> >> hebt. Maar helaas heb je zulke informatie niet gegeven.
> >
> > SSI en CGI zijn beide geen probleem voor mijn server.
>
> SSI en CGI zijn niet meer dan afkortingen.
>
> >> BTW je weet wel dat de referrer header absoluut niet betrouwbaar is!
> >
> > Nee, maar nu wel? ;-) Het is in dit geval niet een heel groot probleem
als
> > het niet super betrouwbaar is.
> >
> > Ik heb wat ervaring met SSI, maar wat moet ik doen om de code voor een
> > bepaald referring domain wel te tonen en voor alle andere niet?
>
> Ik heb nog steeds geen idee wat in jou belevingswereld SSI en CGI
> inhoud. Kom eens met iets concreets zoals naam en versie van webserver
> en eventueel extra geinstalleerde plugins/modules :)
Reactie van mijn host: 'Wat voor versie van de huidige webserver en of
modules hebben geen invloed op SSI. SSI is namelijk niet versie gebonden.
SSI is enkel iets wat je aan of uit zet. In het kort houd SSI simpelweg in
dat je het uitvoeren van CGI bestanden toestaat in _en ook buiten_ de
CGI-BIN directory.'
In mijn belevingswereld is SSI het includen van een bestand binnen een
pagina, bijvoorbeeld: <!--#include virtual="../include.htm"-->
Hoe dat werkt weet ik, nu zou ik nog graag willen weten hoe ik voor één
bepaald domein de include.htm wel kan laten tonen en voor alle anderen niet.
Is dit concreet genoeg voor jou?
Groeten,
Rik.
Rik wrote:
> Daniel,
>
>>>> Met SSI/CGI kan dat op de server in iedergeval wel gebeuren. Hoe
>>>> je dat doet is natuurlijk van wat je voor een SSI/CGI engine tot
>>>> beschikking hebt. Maar helaas heb je zulke informatie niet gegeven.
>>>
>>> SSI en CGI zijn beide geen probleem voor mijn server.
>>
>> SSI en CGI zijn niet meer dan afkortingen.
>>
>>>> BTW je weet wel dat de referrer header absoluut niet betrouwbaar
>>>> is!
>>>
>>> Nee, maar nu wel? ;-) Het is in dit geval niet een heel groot
>>> probleem als het niet super betrouwbaar is.
>>>
>>> Ik heb wat ervaring met SSI, maar wat moet ik doen om de code voor
>>> een bepaald referring domain wel te tonen en voor alle andere niet?
>>
>> Ik heb nog steeds geen idee wat in jou belevingswereld SSI en CGI
>> inhoud. Kom eens met iets concreets zoals naam en versie van
>> webserver
>> en eventueel extra geinstalleerde plugins/modules :)
>
> Reactie van mijn host: 'Wat voor versie van de huidige webserver en of
> modules hebben geen invloed op SSI. SSI is namelijk niet versie
> gebonden. SSI is enkel iets wat je aan of uit zet. In het kort houd
> SSI simpelweg in dat je het uitvoeren van CGI bestanden toestaat in
> _en ook buiten_ de CGI-BIN directory.'
>
> In mijn belevingswereld is SSI het includen van een bestand binnen een
> pagina, bijvoorbeeld: <!--#include virtual="../include.htm"-->
>
> Hoe dat werkt weet ik, nu zou ik nog graag willen weten hoe ik voor
> één bepaald domein de include.htm wel kan laten tonen en voor alle
> anderen niet.
>
> Is dit concreet genoeg voor jou?
<!--#include virtual="/cgi-bin/bla.cgi" -->
en in bla.cgi staat dan een scriptje dat checkt wat de HTTP_REFERER is,
en afhankelijk daarvan iets afdrukt. Heb je trouwens geen PHP, want dit
soort simpele dingetjes zijn daarmaa wel simpeler.
Mark
Hoi Mark,
> >>>> Met SSI/CGI kan dat op de server in iedergeval wel gebeuren. Hoe
> >>>> je dat doet is natuurlijk van wat je voor een SSI/CGI engine tot
> >>>> beschikking hebt. Maar helaas heb je zulke informatie niet gegeven.
> >>>
> >>> SSI en CGI zijn beide geen probleem voor mijn server.
> >>
> >> SSI en CGI zijn niet meer dan afkortingen.
> >>
> >>>> BTW je weet wel dat de referrer header absoluut niet betrouwbaar
> >>>> is!
> >>>
> >>> Nee, maar nu wel? ;-) Het is in dit geval niet een heel groot
> >>> probleem als het niet super betrouwbaar is.
> >>>
> >>> Ik heb wat ervaring met SSI, maar wat moet ik doen om de code voor
> >>> een bepaald referring domain wel te tonen en voor alle andere niet?
> >>
> >> Ik heb nog steeds geen idee wat in jou belevingswereld SSI en CGI
> >> inhoud. Kom eens met iets concreets zoals naam en versie van
> >> webserver
> >> en eventueel extra geinstalleerde plugins/modules :)
> >
> > Reactie van mijn host: 'Wat voor versie van de huidige webserver en of
> > modules hebben geen invloed op SSI. SSI is namelijk niet versie
> > gebonden. SSI is enkel iets wat je aan of uit zet. In het kort houd
> > SSI simpelweg in dat je het uitvoeren van CGI bestanden toestaat in
> > _en ook buiten_ de CGI-BIN directory.'
> >
> > In mijn belevingswereld is SSI het includen van een bestand binnen een
> > pagina, bijvoorbeeld: <!--#include virtual="../include.htm"-->
> >
> > Hoe dat werkt weet ik, nu zou ik nog graag willen weten hoe ik voor
> > één bepaald domein de include.htm wel kan laten tonen en voor alle
> > anderen niet.
> >
> > Is dit concreet genoeg voor jou?
>
> <!--#include virtual="/cgi-bin/bla.cgi" -->
>
> en in bla.cgi staat dan een scriptje dat checkt wat de HTTP_REFERER is,
> en afhankelijk daarvan iets afdrukt. Heb je trouwens geen PHP, want dit
> soort simpele dingetjes zijn daarmaa wel simpeler.
Ja ik heb PHP. Kun je me zeggen hoe ik dit met PHP zou kunnen aanpakken?
Groeten,
Rik.
Rik wrote:
> Hoi Mark,
>
>>>>>> Met SSI/CGI kan dat op de server in iedergeval wel gebeuren. Hoe
>>>>>> je dat doet is natuurlijk van wat je voor een SSI/CGI engine tot
>>>>>> beschikking hebt. Maar helaas heb je zulke informatie niet
>>>>>> gegeven.
>>>>>
>>>>> SSI en CGI zijn beide geen probleem voor mijn server.
>>>>
>>>> SSI en CGI zijn niet meer dan afkortingen.
>>>>
>>>>>> BTW je weet wel dat de referrer header absoluut niet betrouwbaar
>>>>>> is!
>>>>>
>>>>> Nee, maar nu wel? ;-) Het is in dit geval niet een heel groot
>>>>> probleem als het niet super betrouwbaar is.
>>>>>
>>>>> Ik heb wat ervaring met SSI, maar wat moet ik doen om de code voor
>>>>> een bepaald referring domain wel te tonen en voor alle andere
>>>>> niet?
>>>>
>>>> Ik heb nog steeds geen idee wat in jou belevingswereld SSI en CGI
>>>> inhoud. Kom eens met iets concreets zoals naam en versie van
>>>> webserver
>>>> en eventueel extra geinstalleerde plugins/modules :)
>>>
>>> Reactie van mijn host: 'Wat voor versie van de huidige webserver en
>>> of modules hebben geen invloed op SSI. SSI is namelijk niet versie
>>> gebonden. SSI is enkel iets wat je aan of uit zet. In het kort houd
>>> SSI simpelweg in dat je het uitvoeren van CGI bestanden toestaat in
>>> _en ook buiten_ de CGI-BIN directory.'
>>>
>>> In mijn belevingswereld is SSI het includen van een bestand binnen
>>> een pagina, bijvoorbeeld: <!--#include virtual="../include.htm"-->
>>>
>>> Hoe dat werkt weet ik, nu zou ik nog graag willen weten hoe ik voor
>>> één bepaald domein de include.htm wel kan laten tonen en voor alle
>>> anderen niet.
>>>
>>> Is dit concreet genoeg voor jou?
>>
>> <!--#include virtual="/cgi-bin/bla.cgi" -->
>>
>> en in bla.cgi staat dan een scriptje dat checkt wat de HTTP_REFERER
>> is, en afhankelijk daarvan iets afdrukt. Heb je trouwens geen PHP,
>> want dit soort simpele dingetjes zijn daarmaa wel simpeler.
>
> Ja ik heb PHP. Kun je me zeggen hoe ik dit met PHP zou kunnen
> aanpakken?
in php heb je $HTTP_REFERER , dus iets als
blablabalab
<?php
if ($HTTP_REFERER eq "http://ebayadreswaaropjewilttesten"){
?>
hier de htmlcode die je alleen dan wilt tonen
<?php
}
?>
blabaablabla
Mark
Nico Coesel
27/05/03, 19:05
"Marcus" <doei@bannerswapnl.com> wrote:
>Rik wrote:
>> Hoi Mark,
>>
>>>>>>> Met SSI/CGI kan dat op de server in iedergeval wel gebeuren. Hoe
>>>>>>> je dat doet is natuurlijk van wat je voor een SSI/CGI engine tot
>>>>>>> beschikking hebt. Maar helaas heb je zulke informatie niet
>>>>>>> gegeven.
>>>>>>
>>>>>> SSI en CGI zijn beide geen probleem voor mijn server.
>>>>>
>>>>> SSI en CGI zijn niet meer dan afkortingen.
>>>>>
>>>>>>> BTW je weet wel dat de referrer header absoluut niet betrouwbaar
>>>>>>> is!
>>>>>>
>>>>>> Nee, maar nu wel? ;-) Het is in dit geval niet een heel groot
>>>>>> probleem als het niet super betrouwbaar is.
>>>>>>
>>>>>> Ik heb wat ervaring met SSI, maar wat moet ik doen om de code voor
>>>>>> een bepaald referring domain wel te tonen en voor alle andere
>>>>>> niet?
>>>>>
>>>>> Ik heb nog steeds geen idee wat in jou belevingswereld SSI en CGI
>>>>> inhoud. Kom eens met iets concreets zoals naam en versie van
>>>>> webserver
>>>>> en eventueel extra geinstalleerde plugins/modules :)
>>>>
>>>> Reactie van mijn host: 'Wat voor versie van de huidige webserver en
>>>> of modules hebben geen invloed op SSI. SSI is namelijk niet versie
>>>> gebonden. SSI is enkel iets wat je aan of uit zet. In het kort houd
>>>> SSI simpelweg in dat je het uitvoeren van CGI bestanden toestaat in
>>>> _en ook buiten_ de CGI-BIN directory.'
>>>>
>>>> In mijn belevingswereld is SSI het includen van een bestand binnen
>>>> een pagina, bijvoorbeeld: <!--#include virtual="../include.htm"-->
>>>>
>>>> Hoe dat werkt weet ik, nu zou ik nog graag willen weten hoe ik voor
>>>> één bepaald domein de include.htm wel kan laten tonen en voor alle
>>>> anderen niet.
>>>>
>>>> Is dit concreet genoeg voor jou?
>>>
>>> <!--#include virtual="/cgi-bin/bla.cgi" -->
>>>
>>> en in bla.cgi staat dan een scriptje dat checkt wat de HTTP_REFERER
>>> is, en afhankelijk daarvan iets afdrukt. Heb je trouwens geen PHP,
>>> want dit soort simpele dingetjes zijn daarmaa wel simpeler.
>>
>> Ja ik heb PHP. Kun je me zeggen hoe ik dit met PHP zou kunnen
>> aanpakken?
>
>in php heb je $HTTP_REFERER , dus iets als
>
>blablabalab
><?php
>if ($HTTP_REFERER eq "http://ebayadreswaaropjewilttesten"){
>?>
>hier de htmlcode die je alleen dan wilt tonen
><?php
>}
>?>
Is het niet zo dat IE geen referer mee geeft? Ik heb daarmee eens
problemen gehad namelijk...
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vind U op www.adresboekje.nl
Ronald Paul
27/05/03, 19:20
nico@puntnl.niks (Nico Coesel) schreef:
>Is het niet zo dat IE geen referer mee geeft?
Niet per definitie.
>Ik heb daarmee eens problemen gehad namelijk...
Naast of er een optie in de browser aanwezig is waarmee je het sturen
van referers uit zet, kan het ook nog van andere dingen afhankelijk
zijn. Maar IE geeft standaard gewoon referers.
Nou ben ik wel benieuwd, wat voor problemen waren dit?
--
Groet, Ronald
Nico Coesel wrote:
> Is het niet zo dat IE geen referer mee geeft? Ik heb daarmee eens
> problemen gehad namelijk...
Voor zover ik weet wel, anders zou de functie van HTTP_REFERER geen
zijn. (Wat wel kan is dat een Opera die zich als IE voordeed m niet
meegaf)
Mark
<knip>
> in php heb je $HTTP_REFERER , dus iets als
>
> blablabalab
> <?php
> if ($HTTP_REFERER eq "http://ebayadreswaaropjewilttesten"){
> ?>
> hier de htmlcode die je alleen dan wilt tonen
> <?php
> }
> ?>
> blabaablabla
Dank je. Ik heb het getest door de code die ik eerder gaf bovenaan de body
van een site te plaatsen die ik heb bezocht vanaf het $HTTP_REFERRER domein
(ik had een link gemaakt naar de site) en vanaf een link naar dezelfde
pagina van een ander domein, maar ik zag in beide gevallen de tabel met de
tekstlink (de code) gewoon verschijnen. Moet ik het domein zo specificeren:
http://ebayadreswaaropjewilttesten of gewoon zo:
http://www.ebayadreswaarjeopwilttesten.com. Ik heb het laatste gedaan. Ik
kan helaas de betreffende url's niet posten. Ik gebruik IE 6, zonder
firewall.
Groeten,
Rik.
Rik wrote:
> <knip>
>
>> in php heb je $HTTP_REFERER , dus iets als
>>
>> blablabalab
>> <?php
>> if ($HTTP_REFERER eq "http://ebayadreswaaropjewilttesten"){
>>>
>> hier de htmlcode die je alleen dan wilt tonen
>> <?php
>> }
>>>
>> blabaablabla
>
> Dank je. Ik heb het getest door de code die ik eerder gaf bovenaan de
> body van een site te plaatsen die ik heb bezocht vanaf het
> $HTTP_REFERRER domein (ik had een link gemaakt naar de site) en vanaf
> een link naar dezelfde pagina van een ander domein, maar ik zag in
> beide gevallen de tabel met de tekstlink (de code) gewoon
> verschijnen. Moet ik het domein zo specificeren:
> http://ebayadreswaaropjewilttesten of gewoon zo:
> http://www.ebayadreswaarjeopwilttesten.com. Ik heb het laatste
> gedaan. Ik kan helaas de betreffende url's niet posten. Ik gebruik IE
> 6, zonder firewall.
Probeer eens het volgende:
<?php print "#" . $HTTP_REFERER . "#"; ?>
Wat tussen de #jes staat meot je dus invullen in plaats van
ebayadreswaaropjewiltesten.
Mark
Daniel Tryba
27/05/03, 23:50
Rik <rik@removethis.globalinsites.nl> wrote:
>> Ik heb nog steeds geen idee wat in jou belevingswereld SSI en CGI
>> inhoud. Kom eens met iets concreets zoals naam en versie van webserver
>> en eventueel extra geinstalleerde plugins/modules :)
>
> Reactie van mijn host: 'Wat voor versie van de huidige webserver en of
> modules hebben geen invloed op SSI. SSI is namelijk niet versie gebonden.
> SSI is enkel iets wat je aan of uit zet. In het kort houd SSI simpelweg in
> dat je het uitvoeren van CGI bestanden toestaat in _en ook buiten_ de
> CGI-BIN directory.'
Als dat waar zou zijn (en ik geloof er niets van dat elke webserver de
zelfde SSI tags heeft), dan kan je uit de voeten met
http://httpd.apache.org/docs/mod/mod_include.html#flowctrl
In $REFERER zou wel eens de referrer kunnen staan en met de expr
voorbeelden onder 'Variable Susbstituition' moet het dan wel lukken.
Maar in PHP is het wel een stukje makkelijker, maar het zal wel even
duren voordat je ADHV Marcus zijn tips erachter komt dat de referrer in
het $_SERVER array zit :) (phpinfo(32) is your friend).
--
Daniel Tryba
Daniel Tryba wrote:
> Maar in PHP is het wel een stukje makkelijker, maar het zal wel even
> duren voordat je ADHV Marcus zijn tips erachter komt dat de referrer
> in
> het $_SERVER array zit :) (phpinfo(32) is your friend).
hmm, ik ken ook niet echt php, sorry ;(
Maar wat is ADHV?
Mark
(vindt php maar slecht, perl forever ;) )
Daniel Tryba
28/05/03, 00:20
Marcus <doei@bannerswapnl.com> wrote:
>> Maar in PHP is het wel een stukje makkelijker, maar het zal wel even
>> duren voordat je ADHV Marcus zijn tips erachter komt dat de referrer
>> in
>> het $_SERVER array zit :) (phpinfo(32) is your friend).
>
> hmm, ik ken ook niet echt php, sorry ;(
Gebruik dan ook een andere woordkeuze dan:
'in php heb je $HTTP_REFERER , dus iets als'
> Maar wat is ADHV?
Aan De Hand Van
> Mark
> (vindt php maar slecht, perl forever ;) )
Wat snap je niet?
--
Daniel Tryba
"Daniel Tryba" <news_nl.internet.www.server-side@canopus.nl> schreef in
bericht news:bb0mgs$p7p$1@news.tue.nl...
> Rik <rik@removethis.globalinsites.nl> wrote:
> >> Ik heb nog steeds geen idee wat in jou belevingswereld SSI en CGI
> >> inhoud. Kom eens met iets concreets zoals naam en versie van webserver
> >> en eventueel extra geinstalleerde plugins/modules :)
> >
> > Reactie van mijn host: 'Wat voor versie van de huidige webserver en of
> > modules hebben geen invloed op SSI. SSI is namelijk niet versie
gebonden.
> > SSI is enkel iets wat je aan of uit zet. In het kort houd SSI simpelweg
in
> > dat je het uitvoeren van CGI bestanden toestaat in _en ook buiten_ de
> > CGI-BIN directory.'
>
> Als dat waar zou zijn (en ik geloof er niets van dat elke webserver de
> zelfde SSI tags heeft), dan kan je uit de voeten met
> http://httpd.apache.org/docs/mod/mod_include.html#flowctrl
>
> In $REFERER zou wel eens de referrer kunnen staan en met de expr
> voorbeelden onder 'Variable Susbstituition' moet het dan wel lukken.
>
> Maar in PHP is het wel een stukje makkelijker, maar het zal wel even
> duren voordat je ADHV Marcus zijn tips erachter komt dat de referrer in
> het $_SERVER array zit :) (phpinfo(32) is your friend).
Sorry, ik begrijp even niet wat je bedoelt. Is de code die Marcus schreef
niet correct? Wat moet er aan gewijzigd worden? Of weet je evt. waar ik er
meer over kan lezen?
Groeten,
Rik.
Daniel Tryba
28/05/03, 01:35
Rik <rik@removethis.globalinsites.nl> wrote:
>> Maar in PHP is het wel een stukje makkelijker, maar het zal wel even
>> duren voordat je ADHV Marcus zijn tips erachter komt dat de referrer in
>> het $_SERVER array zit :) (phpinfo(32) is your friend).
>
> Sorry, ik begrijp even niet wat je bedoelt. Is de code die Marcus schreef
> niet correct?
Die is inderdaad niet correct.
> Wat moet er aan gewijzigd worden? Of weet je evt. waar ik er
> meer over kan lezen?
Meer te weten komen over PHP doe je natuurlijk op http://www.php.net/ in
de documentatie sectie.
Zo zijn de 2 fouten in het voorbeeld dat er helemaal geen eq operator is
(http://nl3.php.net/manual/en/language.operators.comparison.php)
en dat de $HTTP_REFERER uit de lucht komt vallen.
Dat laatste is niet echt een fout maar een probleem uit het verleden wat
sinds 4.2.x+ default uitstaat
(http://nl3.php.net/manual/en/security.registerglobals.php) vandaar dat
ik ook verwees naar phpinfo(32)
(http://nl3.php.net/manual/en/function.phpinfo.php) waarmee je de
predefined variabelen kunt bekijken voor een pagina.
BTW het controleren van een http header is dusdanig triviaal dat het
wellicht handig is om eens wat te lezen voor je er uberhaupt aan begint
(en nee ik heb geen idee waar je dat moet vinden anders dan de php
manual).
--
Daniel Tryba
Daniel Tryba wrote:
> Marcus <doei@bannerswapnl.com> wrote:
>> Mark
>> (vindt php maar slecht, perl forever ;) )
>
> Wat snap je niet?
Ik snap niet dat PHP doet aan OO maar geen private properties heeft bv.
Ik snap niet dat objecten heel anders moeten werken dan in andere
programmertalen,...
Het is niet zo dat ik php niet begrijp, het is gewoon dat ik het niet
een fijne taal vindt...
Mark
Daniel Tryba wrote:
> Rik <rik@removethis.globalinsites.nl> wrote:
>>> Maar in PHP is het wel een stukje makkelijker, maar het zal wel even
>>> duren voordat je ADHV Marcus zijn tips erachter komt dat de
>>> referrer in het $_SERVER array zit :) (phpinfo(32) is your friend).
>>
>> Sorry, ik begrijp even niet wat je bedoelt. Is de code die Marcus
>> schreef niet correct?
>
> Die is inderdaad niet correct.
>
>> Wat moet er aan gewijzigd worden? Of weet je evt. waar ik er
>> meer over kan lezen?
>
> Meer te weten komen over PHP doe je natuurlijk op http://www.php.net/
> in de documentatie sectie.
>
> Zo zijn de 2 fouten in het voorbeeld dat er helemaal geen eq operator
> is (http://nl3.php.net/manual/en/language.operators.comparison.php)
Nog zo'n slecht punt aan php (quootje):
=========
These comparison operators work based on the context in which they are
being used. So if you want to compare two strings, but they both happen
to be valid numeric values, you're in line to get burned. The PHP way to
compare two strings safely is to use strcmp().
P.S. Don't look for this to change in PHP4 either, when I asked Andi
Gutmans (the guy who put the "nd" in Zend), he said the following:
"We don't want to add eq and the likes to PHP because they just add more
perl-ish complexity."
=========
Dat is toch juist onduidelijker??? Dus je moet maar strcompgebruiken ipv
eq?? Da's toch niet duidelijker, zo krijg je dus code die vrijwel
hetzelfde doet (2 ints of 2 strings vergelijken) die er wel heel anders
uitziet :(
> BTW het controleren van een http header is dusdanig triviaal dat het
> wellicht handig is om eens wat te lezen voor je er uberhaupt aan
> begint (en nee ik heb geen idee waar je dat moet vinden anders dan de
> php manual).
http://php.resourceindex.com
Staan wel links naar tutorials
Mark
Marcus <doei@bannerswapnl.com>:
> Daniel Tryba wrote:
>> Marcus <doei@bannerswapnl.com> wrote:
>>> Mark
>>> (vindt php maar slecht, perl forever ;) )
>>
>> Wat snap je niet?
>
> Ik snap niet dat PHP doet aan OO maar geen private properties heeft
> bv. Ik snap niet dat objecten heel anders moeten werken dan in andere
> programmertalen,...
Het adagium van PHP lijkt te zijn: "eindeloze backwardcompatibility, maakt
niet uit hoe". En dus krijg je een taal met allerlei vage extensies die
bovenop de basis geplakt zijn, en waar de rauwe randjes voor lief worden
genomen.
Voor veel mensen voldoet het prima als taal, maar mijn favoriete taal is
het ook zeker niet (i.t.t., tja, Perl ;).
--
robert
robert wrote:
> Marcus <doei@bannerswapnl.com>:
> > Daniel Tryba wrote:
> >> Marcus <doei@bannerswapnl.com> wrote:
> >>> Mark
> >>> (vindt php maar slecht, perl forever ;) )
> >>
> >> Wat snap je niet?
> >
> > Ik snap niet dat PHP doet aan OO maar geen private properties heeft
> > bv. Ik snap niet dat objecten heel anders moeten werken dan in
> andere > programmertalen,...
>
> Het adagium van PHP lijkt te zijn: "eindeloze backwardcompatibility,
> maakt niet uit hoe". En dus krijg je een taal met allerlei vage
> extensies die bovenop de basis geplakt zijn, en waar de rauwe randjes
> voor lief worden genomen.
Maar dan weer heel raar, want "hoi" eq "doei" is bv weer geen geldige
php :S Ik vind t maar een beroerd zootje, als je zo graag je code tussen
de html gooit, neem dan perl asp (waar ik overigens (helaas) nog niet
mee heb gewerkt)
Mark
Marcus <doei@bannerswapnl.com>:
> Maar dan weer heel raar, want "hoi" eq "doei" is bv weer geen geldige
> php :S Ik vind t maar een beroerd zootje, als je zo graag je code tussen
> de html gooit, neem dan perl asp (waar ik overigens (helaas) nog niet
> mee heb gewerkt)
Mijn persoonlijke website draait ermee, en het is best mooi spul; de
content staat opgeslagen in XML pagina's, die bij requests m.b.v. een
XSLT sheet omgezet worden naar HTML. Je kunt ook taglib-achtige dingen
doen (waarbij je je eigen XML-tags definieert, die dan door een stuk code
afgehandeld kunnen worden), en natuurlijk ook ASP/PHP-achtige code-inserts.
Al met al een aanrader :)
--
robert
Daniel Tryba
28/05/03, 13:35
Marcus <doei@bannerswapnl.com> wrote:
> Nog zo'n slecht punt aan php (quootje):
source?
> =========
> These comparison operators work based on the context in which they are
> being used. So if you want to compare two strings, but they both happen
> to be valid numeric values, you're in line to get burned. The PHP way to
> compare two strings safely is to use strcmp().
Dat is inderdaad == vs eq vc strcmp vs ===
strcmp is een C-ism, het is maar wat je gewend bent. strcmp is iets
anders dan een comparison aangezien die je ook nog vertelt of een string
"groter" of "kleiner" is. het gebruik van == ipv === is inderdaad een
fout gemaakt door veel gebruikers:
if(strpos("abc","a")!=false)
ipv
if(strpos("abc","a")!==false)
if("1.00"=="1")
ipv
if("1.00"==="1")
> P.S. Don't look for this to change in PHP4 either, when I asked Andi
> Gutmans (the guy who put the "nd" in Zend), he said the following:
> "We don't want to add eq and the likes to PHP because they just add more
> perl-ish complexity."
Nou vraag ik me toch echt af wat de source hiervan is? Zeker aangezien
dat er in (op z'n minst PHP4) dus wel duidelijk verschillende operatoren
zitten om zoiets te checken.
> Dat is toch juist onduidelijker??? Dus je moet maar strcompgebruiken ipv
> eq?? Da's toch niet duidelijker, zo krijg je dus code die vrijwel
> hetzelfde doet (2 ints of 2 strings vergelijken) die er wel heel anders
> uitziet :(
Dat is dus niet zo.
--
Daniel Tryba
Daniel Tryba
28/05/03, 13:50
Marcus <doei@bannerswapnl.com> wrote:
>> Wat snap je niet?
>
> Ik snap niet dat PHP doet aan OO maar geen private properties heeft bv.
> Ik snap niet dat objecten heel anders moeten werken dan in andere
> programmertalen,...
OO is een after thought. BTW ik zie het missen van private/protected
niet als een probleem, je moet er dan maar gewoon met je vingers
afblijven als gebruiker.
BTW geruchten zijn dat PHP 5 wel een zinnige OO implementatie heeft,
maar dat is iets voor in de verre toekomst.
BTW schijnbaar kan je met intro/retrospection ook in Java en C# met
privates gaan rommelen.
> Het is niet zo dat ik php niet begrijp, het is gewoon dat ik het niet
> een fijne taal vindt...
Het is maar hoe je naar een taal kijkt. OO is klote in PHP, gebruik het
dan niet. En als je het verwarrend vindt dat en geen eq is en niet weet
dat een een === als alternatief bestaat dan ben je vastgeroest.
--
Daniel Tryba
Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> Marcus <doei@bannerswapnl.com> wrote:
>>> Wat snap je niet?
>>
>> Ik snap niet dat PHP doet aan OO maar geen private properties heeft
>> bv. Ik snap niet dat objecten heel anders moeten werken dan in andere
>> programmertalen,...
>
> OO is een after thought. BTW ik zie het missen van private/protected
> niet als een probleem, je moet er dan maar gewoon met je vingers
> afblijven als gebruiker.
Je geeft hier min of meer de definitie van een 'hack' :)
> BTW schijnbaar kan je met intro/retrospection ook in Java en C# met
> privates gaan rommelen.
In Java kan dat AFAIK alleen als je (extern) declareert wat iemand door
gebruikmaking van reflection wel/niet kan zien.
>> Het is niet zo dat ik php niet begrijp, het is gewoon dat ik het niet
>> een fijne taal vindt...
>
> Het is maar hoe je naar een taal kijkt. OO is klote in PHP, gebruik het
> dan niet.
Inderdaad, ik gebruik Perl ;)
--
robert
Daniel Tryba wrote:
> Marcus <doei@bannerswapnl.com> wrote:
>> Nog zo'n slecht punt aan php (quootje):
>
> source?
Beetje selectief geknipt? Ik zei:
> Zo zijn de 2 fouten in het voorbeeld dat er helemaal geen eq operator
> is (http://nl3.php.net/manual/en/language.operators.comparison.php)
Nog zo'n slecht punt aan php (quootje):
-------
quootje uit het bovenstaande dus
Mark
Daniel Tryba wrote:
> Marcus <doei@bannerswapnl.com> wrote:
>>> Wat snap je niet?
>> Het is niet zo dat ik php niet begrijp, het is gewoon dat ik het niet
>> een fijne taal vindt...
>
> Het is maar hoe je naar een taal kijkt. OO is klote in PHP, gebruik
> het dan niet. En als je het verwarrend vindt dat en geen eq is en
> niet weet dat een een === als alternatief bestaat dan ben je
> vastgeroest.
Het is gewoon IMHO een beetje een zootje, ik heb er een (kort) tijdje
mee gewerkt, maar begon me er na verloop van tijd aan te ergeren, en ben
maar weer teruggegaan naar Perl. Bovendien is PHP kennelijk zo makkelijk
dat allemaal prutsers erin gaan programmeren (geldt ook voor
ASP/vbscript), waardoor we er weer bergen veiligheidslekken bij hebben.
(hoewel dat niet helemaal de schuld is van PHP natuurlijk)
Mark
Daniel Tryba
28/05/03, 23:50
Marcus <doei@bannerswapnl.com> wrote:
>>> Nog zo'n slecht punt aan php (quootje):
>>
>> source?
>
> Beetje selectief geknipt? Ik zei:
Inderdaad het zou netter zijn geweest indien je even had meegenomen wie
dat wanneer zei:
http://nl3.php.net/manual/en/language.operators.comparison.php
<q>
wizzard at wizzard dot org
*09-Sep-1999 12:07*
These comparison operators work based on the context in which they are
being used. So if you want to compare two strings,.....
</q>
--
Daniel Tryba
Daniel Tryba
29/05/03, 00:05
Marcus <doei@bannerswapnl.com> wrote:
>> Het is maar hoe je naar een taal kijkt. OO is klote in PHP, gebruik
>> het dan niet. En als je het verwarrend vindt dat en geen eq is en
>> niet weet dat een een === als alternatief bestaat dan ben je
>> vastgeroest.
>
> Het is gewoon IMHO een beetje een zootje, ik heb er een (kort) tijdje
> mee gewerkt, maar begon me er na verloop van tijd aan te ergeren, en ben
> maar weer teruggegaan naar Perl.
Raar, maar dat idee kreeg ik ook toen ik ooit iets in Perl moest doen:
het is gewoon een zootje. Het enige wat een beetje zinnig is aan Perl is
CPAN.
> Bovendien is PHP kennelijk zo makkelijk dat allemaal prutsers erin
> gaan programmeren (geldt ook voor ASP/vbscript), waardoor we er weer
> bergen veiligheidslekken bij hebben.
Inderdaad, al die populaire talen zijn gewoon niet 1337 genoeg meer.
Gelukkig is Perl zo inzichtelijk dat formmail.pl al jaren geleden
gefixed is :)
--
Daniel Tryba
Daniel Tryba wrote:
> Marcus <doei@bannerswapnl.com> wrote:
>>> Het is maar hoe je naar een taal kijkt. OO is klote in PHP, gebruik
>>> het dan niet. En als je het verwarrend vindt dat en geen eq is en
>>> niet weet dat een een === als alternatief bestaat dan ben je
>>> vastgeroest.
>>
>> Het is gewoon IMHO een beetje een zootje, ik heb er een (kort) tijdje
>> mee gewerkt, maar begon me er na verloop van tijd aan te ergeren, en
>> ben maar weer teruggegaan naar Perl.
>
> Raar, maar dat idee kreeg ik ook toen ik ooit iets in Perl moest doen:
> het is gewoon een zootje. Het enige wat een beetje zinnig is aan Perl
> is CPAN.
Perl nodigt (mij) best uit tot netjes (modulair) programmeren. Het is
iig de meest gestructureerde scriptingtaal die ik ken (python en ruby
zijn misschien beter, maar die ken ik dan ook niet)
>> Bovendien is PHP kennelijk zo makkelijk dat allemaal prutsers erin
>> gaan programmeren (geldt ook voor ASP/vbscript), waardoor we er weer
>> bergen veiligheidslekken bij hebben.
>
> Inderdaad, al die populaire talen zijn gewoon niet 1337 genoeg meer.
>
> Gelukkig is Perl zo inzichtelijk dat formmail.pl al jaren geleden
> gefixed is :)
Dat was ook geprogrammeerd door een beginner. Bovendien helpt php je met
onveilige code schrijven (zoals dat je even makkelijk een website opent
ipv een file, met (ik meende) fopen(), of door een vals gevoel van
veiligheid te geven mbv magic quotes)
Mark
Daniel Tryba
29/05/03, 01:05
robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> >> Ik snap niet dat PHP doet aan OO maar geen private properties heeft
> >> bv. Ik snap niet dat objecten heel anders moeten werken dan in andere
> >> programmertalen,...
> >
> > OO is een after thought. BTW ik zie het missen van private/protected
> > niet als een probleem, je moet er dan maar gewoon met je vingers
> > afblijven als gebruiker.
>
> Je geeft hier min of meer de definitie van een 'hack' :)
Ik zal het niet ontkennen.
> > BTW schijnbaar kan je met intro/retrospection ook in Java en C# met
> > privates gaan rommelen.
>
> In Java kan dat AFAIK alleen als je (extern) declareert wat iemand door
> gebruikmaking van reflection wel/niet kan zien.
Nee, tenzij je in een SecurityManger draaid (bv applets) mag je gewoon
overal bij:
java TstReflection
Name:foo, Type:java.lang.String, modifier: 2
foo
Value: foo
------
public class Tst
{
private String foo="foo";
public Tst()
{
System.out.println(this.foo);
}
}
------
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
public class TstReflection
{
public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException
{
int i;
int modifier;
Class classname=Class.forName("Tst");
Field[] fields=classname.getDeclaredFields();
for(i=0;i<fields.length;i++)
{
modifier=fields[i].getModifiers();
System.err.println("Name:"+fields[i].getName()+", Type:"+fields[i].getType().getName()+", modifier: "+modifier);
if(Modifier.isPrivate(modifier))
{
fields[i].setAccessible(true);
Object Tst=classname.newInstance();
Object tmp=fields[i].get(Tst);
System.err.println("\t Value: "+tmp.toString());
}
}
}
}
------
--
Daniel Tryba
Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> Marcus <doei@bannerswapnl.com> wrote:
>> Het is gewoon IMHO een beetje een zootje, ik heb er een (kort) tijdje
>> mee gewerkt, maar begon me er na verloop van tijd aan te ergeren, en
>> ben maar weer teruggegaan naar Perl.
>
> Raar, maar dat idee kreeg ik ook toen ik ooit iets in Perl moest doen:
> het is gewoon een zootje.
Maar dat komt omdat jij geen Perl-programmeur bent. De meeste, zo niet
alle, mensen die klagen over de onleesbaarheid van Perl zijn stuk voor stuk
personen die:
- brakke code van iemand anders moeten onderhouden (majordomo, anyone?);
- zelf te weinig kennis hebben om er netjes in te programmeren;
- nogsteeds in het Perl-4 tijdperk leven;
Als je de taal fatsoenlijk beheerst, valt er in Perl prima _netjes_ te
programmeren; de taal biedt er in ieder geval alle mogelijkheden voor (en
dát is IMO bij PHP anders).
--
robert
Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>> In Java kan dat AFAIK alleen als je (extern) declareert wat iemand door
>> gebruikmaking van reflection wel/niet kan zien.
>
> Nee, tenzij je in een SecurityManger draaid (bv applets) mag je gewoon
> overal bij:
<snip>
> for(i=0;i<fields.length;i++)
> {
> modifier=fields[i].getModifiers();
> System.err.println("Name:"+fields[i].getName()+", Type:"+fields[i].getType().getName()+", modifier: "+modifier);
>
> if(Modifier.isPrivate(modifier))
> {
> fields[i].setAccessible(true);
>
> Object Tst=classname.newInstance();
> Object tmp=fields[i].get(Tst);
> System.err.println("\t Value: "+tmp.toString());
> }
> }
Mag je de waarde ook aanpassen?
--
robert
Hans Wolters
29/05/03, 11:20
On Thu, 29 May 2003 07:19:53 +0000 (UTC), robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
[netjes/mooi coden]
> > Raar, maar dat idee kreeg ik ook toen ik ooit iets in Perl moest doen:
> > het is gewoon een zootje.
>
> Maar dat komt omdat jij geen Perl-programmeur bent. De meeste, zo niet
> alle, mensen die klagen over de onleesbaarheid van Perl zijn stuk voor stuk
> personen die:
> - brakke code van iemand anders moeten onderhouden (majordomo, anyone?);
> - zelf te weinig kennis hebben om er netjes in te programmeren;
> - nogsteeds in het Perl-4 tijdperk leven;
>
> Als je de taal fatsoenlijk beheerst, valt er in Perl prima _netjes_ te
> programmeren; de taal biedt er in ieder geval alle mogelijkheden voor (en
> dát is IMO bij PHP anders).
Het is in bijna elke taal mogelijk om netjes te coden, mits je idd genoeg
ervaring hebt om te weten waar je mee bezig bent. Ik maak al jaren php
scripts en de laatste tijd met perl bezig. Dit gaat prima.
Hans
--
pas op, nomailwanted is een spamtrap.
Hans Wolters wrote:
> On Thu, 29 May 2003 07:19:53 +0000 (UTC), robert
> <{n.i.w.s}@allyourbass.org.invalid> wrote:
>> Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
>
> [netjes/mooi coden]
>
>>> Raar, maar dat idee kreeg ik ook toen ik ooit iets in Perl moest
>>> doen:
>>> het is gewoon een zootje.
>>
>> Maar dat komt omdat jij geen Perl-programmeur bent. De meeste, zo
>> niet
>> alle, mensen die klagen over de onleesbaarheid van Perl zijn stuk
>> voor stuk
>> personen die:
>> - brakke code van iemand anders moeten onderhouden (majordomo,
>> anyone?);
>> - zelf te weinig kennis hebben om er netjes in te programmeren;
>> - nogsteeds in het Perl-4 tijdperk leven;
>>
>> Als je de taal fatsoenlijk beheerst, valt er in Perl prima _netjes_
>> te
>> programmeren; de taal biedt er in ieder geval alle mogelijkheden
>> voor (en
>> dát is IMO bij PHP anders).
>
> Het is in bijna elke taal mogelijk om netjes te coden, mits je idd
> genoeg
> ervaring hebt om te weten waar je mee bezig bent. Ik maak al jaren php
> scripts en de laatste tijd met perl bezig. Dit gaat prima.
Ik daag je uit een netjes programma te schrijven in BrainFuck :)
Mark
Daniel Tryba
29/05/03, 13:05
robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > if(Modifier.isPrivate(modifier))
> > {
> > fields[i].setAccessible(true);
> >
> > Object Tst=classname.newInstance();
> > Object tmp=fields[i].get(Tst);
> > System.err.println("\t Value: "+tmp.toString());
> > }
> > }
>
> Mag je de waarde ook aanpassen?
Ja: fields[i].set(Tst,"bar");
--
Daniel Tryba
Daniel Tryba
29/05/03, 13:20
Marcus <doei@bannerswapnl.com> wrote:
>>> Bovendien is PHP kennelijk zo makkelijk dat allemaal prutsers erin
>>> gaan programmeren (geldt ook voor ASP/vbscript), waardoor we er weer
>>> bergen veiligheidslekken bij hebben.
>>
>> Inderdaad, al die populaire talen zijn gewoon niet 1337 genoeg meer.
>>
>> Gelukkig is Perl zo inzichtelijk dat formmail.pl al jaren geleden
>> gefixed is :)
>
> Dat was ook geprogrammeerd door een beginner. Bovendien helpt php je met
> onveilige code schrijven (zoals dat je even makkelijk een website opent
> ipv een file, met (ik meende) fopen(),
Vrijwel alle functies die iets met het fs doen kunnen gebruik maken van
de url wrapper, dat houd in dat je oa http(s) en ftp(s) maar ook ssl en
tls. Maar waarom zou dat onveilig zijn?
> of door een vals gevoel van veiligheid te geven mbv magic quotes)
Nog altijd beter dan helemaal niets, zelf zet ik magic_quotes uit maar
een absolute beginner (die ongeacht taal, toch geen aandacht besteed aan
veiligheid) heeft er IMHO zeker baad bij.
--
Daniel Tryba
Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>> Mag je de waarde ook aanpassen?
> Ja: fields[i].set(Tst,"bar");
Joechei! :P
--
robert
Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> Marcus <doei@bannerswapnl.com> wrote:
>> Dat was ook geprogrammeerd door een beginner. Bovendien helpt php je met
>> onveilige code schrijven (zoals dat je even makkelijk een website opent
>> ipv een file, met (ik meende) fopen(),
>
> Vrijwel alle functies die iets met het fs doen kunnen gebruik maken van
> de url wrapper, dat houd in dat je oa http(s) en ftp(s) maar ook ssl en
> tls. Maar waarom zou dat onveilig zijn?
Als het path van de file op één of andere reden van buitenaf geinjecteerd
wordt, kan je daarmee potentieel enge dingen uithalen. Maar natuurlijk
checkt iedereen eerst z'n formvariabelen op zinnige waarden... ;)
--
robert
Daniel Tryba wrote:
> Marcus <doei@bannerswapnl.com> wrote:
>>>> Bovendien is PHP kennelijk zo makkelijk dat allemaal prutsers erin
>>>> gaan programmeren (geldt ook voor ASP/vbscript), waardoor we er
>>>> weer bergen veiligheidslekken bij hebben.
>>>
>>> Inderdaad, al die populaire talen zijn gewoon niet 1337 genoeg meer.
>>>
>>> Gelukkig is Perl zo inzichtelijk dat formmail.pl al jaren geleden
>>> gefixed is :)
>>
>> Dat was ook geprogrammeerd door een beginner. Bovendien helpt php je
>> met onveilige code schrijven (zoals dat je even makkelijk een
>> website opent ipv een file, met (ik meende) fopen(),
>
> Vrijwel alle functies die iets met het fs doen kunnen gebruik maken
> van de url wrapper, dat houd in dat je oa http(s) en ftp(s) maar ook
> ssl en tls. Maar waarom zou dat onveilig zijn?
Op zich is het niet zozeer onveilig als dat het een beveilingslek is.
Stel ik heb site X die dit fopen probleem heeft. Ik heb site Y die een
SQL injection probleem heeft. Dan roep ik site X aan met als file de URL
waarmee ik site Y aanval. Toon nu als beheerder van site X maar eens aan
dat jij dat niet was (en als je me dan makkelijk te tracen vindt, ik kan
het ook met meerdere sites X doen natuurlijk).
>> of door een vals gevoel van veiligheid te geven mbv magic quotes)
>
> Nog altijd beter dan helemaal niets, zelf zet ik magic_quotes uit maar
> een absolute beginner (die ongeacht taal, toch geen aandacht besteed
> aan veiligheid) heeft er IMHO zeker baad bij.
*baat,
Maar juist die beginner zou dat moeten worden geleerd. In perl heb je bv
tainted variabelen, dat is tenminste een echte check, ipv alleen op
quotes te checken.
Mark
Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> Marcus <doei@bannerswapnl.com> wrote:
>> of door een vals gevoel van veiligheid te geven mbv magic quotes)
> Nog altijd beter dan helemaal niets...
Het probleem is dat magic_quotes in een externe config aan- of uitgezet
moet worden. Da's een behoorlijk probleem als je als developer op systeem A
werkt, waar het aan staat, dan je code op systeem B zet, en er automatisch
vanuit gaat dat het daar ook aan staat.
Dat valt alleen te ondervangen als je overal in je code checkt of bepaalde
configuratieopties wel of niet aan staan, óf, in het geval van SQL, te
werken met placeholders ('SELECT * FROM TABLE WHERE username = ?').
--
robert
Hans Wolters
29/05/03, 14:05
On Thu, 29 May 2003 12:12:35 +0200, Marcus <doei@bannerswapnl.com> wrote:
> Hans Wolters wrote:
>> On Thu, 29 May 2003 07:19:53 +0000 (UTC), robert
>> [netjes/mooi coden]
>> Het is in bijna elke taal mogelijk om netjes te coden, mits je idd
^^^^^^^^^^
>> genoeg
>> ervaring hebt om te weten waar je mee bezig bent. Ik maak al jaren php
>> scripts en de laatste tijd met perl bezig. Dit gaat prima.
>
> Ik daag je uit een netjes programma te schrijven in BrainFuck :)
Ja, als je in brainf code dan mis je blijkbaar bepaalde delen van zinnen? :-)
Hans
--
pas op, nomailwanted is een spamtrap.
Hans Wolters wrote:
> On Thu, 29 May 2003 12:12:35 +0200, Marcus <doei@bannerswapnl.com>
> wrote:
>> Hans Wolters wrote:
>>> On Thu, 29 May 2003 07:19:53 +0000 (UTC), robert
>
>>> [netjes/mooi coden]
>
>>> Het is in bijna elke taal mogelijk om netjes te coden, mits je idd
> ^^^^^^^^^^
>>> genoeg
>>> ervaring hebt om te weten waar je mee bezig bent. Ik maak al jaren
>>> php scripts en de laatste tijd met perl bezig. Dit gaat prima.
>>
>> Ik daag je uit een netjes programma te schrijven in BrainFuck :)
>
> Ja, als je in brainf code dan mis je blijkbaar bepaalde delen van
> zinnen? :-)
>++++++++++[-<+++++++++++>]<+.----------.+++++++++++.+++.>++++++++[-<-
-------->]<+.------------.>++++++++[-<+++++++++>]<+.++.>++++++++[-<---
------>]<---.>++++++++[-<+++++++++>]<.-------.+++.>++++++++[-<--------
>]<----.>++++++++[-<+++++++++>]<.---.+++++++++++++++.>+++++++++[-<----
----->]<---.>++++++++[-<+++++++++>]<+.+++++.----------.+.+++++++++++++
..--------------.---..+++.>++++++++[-<-------->]<----.>+++++++++[-<++++
+++++>]<---.-----.----.+++++++++++++++.>+++++++++[-<--------->]<---.>+
+++++++[-<+++++++++>]<.---.+++++++.-------.++++++++.------------..++++
+++++++.>++++++++[-<--------->]<----.>++++++++[-<+++++++++>]<-.+++++++
+.----------.-.>++++++++[-<-------->]<----.>++++++++[-<+++++++++>]<-.-
-.+++++++.-------.>++++[-<+++++>]<+.>++++[-<----->]<-.+++++++++.>+++++
++++[-<--------->]<+++.>+++++[-<+++++>]<+.>+++++[-<+++++>]<.>+++++++[-
<------->]<--.>+++++++++[-<+++++++++>]<++.----.+++..+++++++.
Mark
Nico Coesel
29/05/03, 17:20
Ronald Paul <usenet@rcpaul.nl> wrote:
>nico@puntnl.niks (Nico Coesel) schreef:
>
>>Is het niet zo dat IE geen referer mee geeft?
>
>Niet per definitie.
>
>>Ik heb daarmee eens problemen gehad namelijk...
>
>Naast of er een optie in de browser aanwezig is waarmee je het sturen
>van referers uit zet, kan het ook nog van andere dingen afhankelijk
>zijn. Maar IE geeft standaard gewoon referers.
>
>Nou ben ik wel benieuwd, wat voor problemen waren dit?
Ik heb iets gemaakt waarmee een frame weer in de frameset wordt
geladen (als er bijvoorbeeld direct vanuit een zoekmachine naartoe
gesprongen wordt). Daarvoor heb ik de referrer nodig om te bepalen
welke URL werd aangeroepen. En IE geeft die niet mee.
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vind U op www.adresboekje.nl
Jan Ehrhardt
29/05/03, 18:20
Nico Coesel in nl.internet.www.server-side (Thu, 29 May 2003 15:20:55
GMT):
>Ronald Paul <usenet@rcpaul.nl> wrote:
>
>>Naast of er een optie in de browser aanwezig is waarmee je het sturen
>>van referers uit zet, kan het ook nog van andere dingen afhankelijk
>>zijn. Maar IE geeft standaard gewoon referers.
>>
>>Nou ben ik wel benieuwd, wat voor problemen waren dit?
>
>Ik heb iets gemaakt waarmee een frame weer in de frameset wordt
>geladen (als er bijvoorbeeld direct vanuit een zoekmachine naartoe
>gesprongen wordt). Daarvoor heb ik de referrer nodig om te bepalen
>welke URL werd aangeroepen.
Daarvoor heb je de referrer helemaal niet nodig mits je het client-side
oplost. Als je dit probleem server-side wilt tackelen is de HTTP_REFERER
onbetrouwbaar. En niet alleen IE.
Jan
--
Dropdown and pushup menu's - http://cgi.monitor.nl/cms.html
Daniel Tryba
29/05/03, 23:20
robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> >> Mag je de waarde ook aanpassen?
> > Ja: fields[i].set(Tst,"bar");
>
> Joechei! :P
Leuk voor debuggers :)
--
Daniel Tryba
Daniel Tryba
29/05/03, 23:35
robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > Vrijwel alle functies die iets met het fs doen kunnen gebruik maken van
> > de url wrapper, dat houd in dat je oa http(s) en ftp(s) maar ook ssl en
> > tls. Maar waarom zou dat onveilig zijn?
>
> Als het path van de file op ??n of andere reden van buitenaf geinjecteerd
> wordt, kan je daarmee potentieel enge dingen uithalen. Maar natuurlijk
> checkt iedereen eerst z'n formvariabelen op zinnige waarden... ;)
Zonder checks zijn zelfs een simpele echo gevaarlijk.
--
Daniel Tryba
Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>> > Vrijwel alle functies die iets met het fs doen kunnen gebruik maken
>> > van de url wrapper, dat houd in dat je oa http(s) en ftp(s) maar ook
>> > ssl en tls. Maar waarom zou dat onveilig zijn?
>>
>> Als het path van de file op ??n of andere reden van buitenaf
>> geinjecteerd wordt, kan je daarmee potentieel enge dingen
>> uithalen. Maar natuurlijk checkt iedereen eerst z'n formvariabelen op
>> zinnige waarden... ;)
>
> Zonder checks zijn zelfs een simpele echo gevaarlijk.
En dat voor een 'weblanguage' ;)
--
robert