je host is contacteren voor de volledige path zoals ik je al zei via Skype.
terwijl via mijn ftp verbinding zie ik de mappen
Maar dat is waarschijnlijk een relatief pad. Ik denk dat je voor een cronjob voor de verwijzing naar een PHP-bestand een absoluut pad moet opgeven.
Om erachter te komen welk pad je zou moeten opgeven zou je ergens tijdelijk een test-scriptje neer kunnen zetten met de volgende inhoud:
<?php
echo getcwd();
?>(wat je misschien ook kan doen is phpinfo() raadplegen, maar dit komt in feite op hetzelfde neer)
De afgedrukte waarde vertelt je hoe de aanloop van het absolute pad naar je publieke webdirectory luidt.
Indien je cronjob scripts buiten je webdirectory staan (wat waarschijnlijk wel verstandig is, op die manier kunnen eindgebruikers deze niet rechtstreeks aanroepen) moet je hier rekening mee houden natuurlijk (je zult dan de waarde die uit getcwd() rolt enigszins moeten aanpassen).
Mocht het nog niet gelukt zijn, in jouw geval zou de cron de volgende opbouw moet hebben
/usr/bin/php-cli /home/gangstermaffia/public_html/v3/crontjuh/cron_hour.phpWe hebben een helpdesk waar je met dit soort vragen bij terecht kan, he 
Zoals eerder aangegeven is het waarschijnlijk een slecht idee om cronjobs in de publieke webdirectory te zetten, omdat eindgebruikers deze "cronjob" dan ook kunnen aanroepen en effectief uit kunnen voeren.
Nu kun je dit script uitbreiden met allerlei controles dat deze niet te vaak wordt uitgevoerd, maar je zou deze ook gewoon op een geschiktere plek kunnen zetten.
Volgens mij kan je ook prima controleren of het script via de CLI wordt aangeroepen. Dan zit je ook erg safe.
Maar het script buiten de webroot plaatsten, is het beste. Alleen zijn er soms nog webhosting-bedrijven die dat niet toestaan.
Ow nee hoor, dat staan we zeker toe - het zou inderdaad een goede tip zijn om de locatie van deze bestanden aan te passen!
Een CLI-check kan zeker geen kwaad voor de zekerheid
<?php
if(php_sapi_name() === 'cli') {
// CLI
} else {
// mag niet met een browser benaderen, foei!
}
?>Zoals ik al (min of meer) eerder zei, indien het script op de goede plek staat zijn dit soort controles overbodig.
En het lijkt mij wel een redelijke aanname dat je mag verwachten dat (dit soort) bronbestanden ook echt op de goede plek staan. Anders heeft iemand zijn werk gewoon niet goed gedaan. Het lijkt mij onverstandig om dit soort fouten (eindeloos) te ondervangen en hiermee je code langer (en daarmee complexer) te maken.
Maak een directory buiten je document root aan en geef deze de naam "cron" of wat dan ook. Dit laat weinig ruimte voor twijfel over wat het doel is van de PHP-bestanden die hier in staan. Het is ook meteen aan de buitenkant duidelijk wat voor doel het dient - hiervoor zou je niet eens de code in hoeven te duiken.
Als het niet mogelijk is om buiten je webdirectory te geraken en de hostingpartij kan dit ook niet voor je regelen lijkt het mij tijd om eens om je heen te kijken naar andere partijen en/of jezelf af te vragen of je niet teveel de hand op de knip houdt bij de keuze voor je hostingoplossing.
Thomas, zulke controles kunnen zelfs juist handig zijn. Want wat als iemand door een 'remote file inclusion' de cronjob kan aanspreken die buiten de webroot staat? Met en check of deze via de CLI wordt uitgevoerd ben je er zeker van dat niemand hem via de browser uitvoert.
@binkkie een ander proces voert de PHP uit, deze is mogelijk niet vertrouwd met de gangbare paden/locaties van jouw PHP-bestanden. Je zou een include-path kunnen toevoegen in dit script zodat je toegang hebt tot je gangbare PHP-bestanden of je zorgt ervoor dat je includes en requires ook voorziet van volledige paden.
Want wat als iemand door een 'remote file inclusion' de cronjob kan aanspreken die buiten de webroot staat?
Dat is een ander probleem wat ook op een andere plaats opgelost dient te worden.
Wat je hierboven in feite zegt is: "Wat als je site zo lek is als een mandje". Tsja. Minder brakke code schrijven?
Het is wel een ander probleem, maar een extra veiligheidslaag kan zeker geen kwaad. Wat dacht je van een zero-day exploit in een CMS waar je niet zelf aan de code wilt sleutelen?
Het klinkt overdreven, maar cronjobs behoor je alleen maar als CLI uit te kunnen voeren, in mijn ogen, of via een whitle-listed IP voor ontwikkeldoeleinden.
Het klinkt overdreven, maar cronjobs behoor je alleen maar als CLI uit te kunnen voeren, in mijn ogen.
Mee eens. En dit kun je op verschillende manieren inrichten.
Normaal gesproken kan geen PHP-script aangesproken worden buiten de webdirectory. Je hebt dan een impliciete afscherming door de bestandslocatie.
Het eerder genoemde voorbeeld van remote file inclusion is een beetje gezocht, en waarschijnlijk is dan het kunnen uitvoeren van crons het minste van je problemen. Het ontbreken van enige basisvoorzieningen in de veiligheid van je website/webapplicatie is niet echt zo'n fantastische uitgangsstelling, want dan maakt het verder echt niet uit hoe je dingen inricht...
Wanneer je het script in de webdirectory zet, wat in het algemeen niet zo'n strak plan is, omdat het sowieso niet de bedoeling is dat dit script rechtstreeks aangeroepen kan worden, introduceer je zelf de noodzaak om dit script vervolgens weer dicht te timmeren met extra, en expliciete, controles.
Het lijkt mij gewoon handiger, eenvoudiger en minder werk om alle cronscripts op één locatie buiten de webdirectory te zetten.
Wat zou jouw argumentatie zijn om cronscripts willens en wetens in de webdirectory te zetten? Behalve als je niet anders kan, en dan zou je je kunnen afvragen hoe bekwaam je hostingpartij is...
Toevoeging, van de user contributed notes op php.net:
Note, that the php-cgi binary can be called from the command line, from a shell script or as a cron job as well! If so, the php_sapi_name() will always return the same value (i.e. "cgi-fcgi") instead of "cli" which you could expect.
Als je dan toch volhardt in een opzet met php_sapi_name(), controleer dan ook wat de exacte waarde is - deze kun je ook opvragen middels de constante PHP_SAPI. Deze kan per omgeving verschillen (wat mij betreft nog een reden om dit soort controles met hardcoded waarden te vermijden en scripts gewoon op de goede plek te zetten).
Heb je nog geen account? Registreer je nu en word deel van onze community!
