Citaat van ThomasBlom

Maar wanneer ik een POST request naar de API stuur, waar dezelfde code wordt uitgevoerd, wordt dit niet opgeslagen.

Dan zou ik daar eens naar kijken :).

Citaat van ThomasBlom

De cookie zou je ook zelf kunnen maken. De kans dat je een session_key goed hebt gegokt die ook nog geldig is, is nogal klein. Toch is die aanwezig denk ik.

Daarom zul je aanvullende voorzieningen moeten treffen waarmee je met grotere zekerheid kunt stellen dat je met een zekere gebruiker van doen hebt. Enkel een sessie-id lijkt mij sowieso niet echt verstandig/voldoende voor deze check.

Misschien kun je op een of andere manier makkelijk gebruik maken van het feit dat je HTTPS gebruikt - al het dataverkeer wordt encrypted verstuurd/ontvangen. Je zult dan waarschijnlijk wel (extra) informatie moeten onthouden zodat je dingen kunt controleren, dus ik denk dat je dan toch (deels) aangewezen bent op de gebruikmaking van een database.

Ook lijkt het mij verstandiger om elke page-access de database te raadplegen om te kijken wat de status van een gebruiker is. Indien je deze informatie (rol, privileges etc.) in je sessie opslaat kun je hier niet direct op acteren, maar zul je moeten wachten totdat de sessie getimeout is of dat een gebruiker uitlogt. Of je moet functionaliteit hebben die iemand geforceerd uitlogt, maar dat lijkt mij de verkeerde insteek (borduurt verder op een andere tekortkoming: het "blijven hangen" van informatie in je sessie).

Enkele kanttekeningen:
--single-transaction werkt alleen voor databases met (enkel) tabellen met de InnoDB engine. Gebruik voor MyISAM-gebaseerde databases --lock-tables

Daarnaast wil je er waarschijnlijk ook voor zorgen dat er geen actieve gebruikers in het systeem/de systemen bezig zijn op het moment van het maken van de backup(s). Bijvoorbeeld door downtime aan te kondigen en te zorgen dat deze systemen op die tijdstippen ook niet toegankelijk zijn.

Het gebruik van > backup.sql (dus het gebruik van het groter-dan-teken) kan op sommige systemen voor problemen zorgen. Beter is wellicht het gebruiken van -r <file> of --result-file=<file>.

Citaat van Laura

Noot: soms dien je wel not te authenticeren (in te loggen) voordat de database backup begint.

Dit kun je ondervangen door het uitlezen van een .cnf bestand middels --defaults-file=/path/to/db.cnf

Hiermee voorkom je ook dat wachtwoorden gelogd worden (als je van plan was om gemakshalve deze credentials op te nemen in je shellscript wat misschien een minder goed idee is).

En maak altijd eerst een image / backup :p.

Citaat van ThomasBlom

Nadat ik ben ingelogd, navigeer ik naar een andere pagina. Daar krijg ik geen session als resultaat.

Bevindt deze andere pagina zich in het pad /tmp, oftewel, navigeer je naar iets van de vorm http(s)://domain.com/tmp? Want dat (die, en onderliggende directories) is het geldigheidsdomein wat je instelt voor je sessie-cookie middels session_set_cookie_params(). Daarbuiten "bestaat" deze niet.

Je zou altijd je cookies kunnen inspecteren via je browser. Grote kans dat daar dan gewoon een sessie-cookie tussenstaat met path "/tmp".

Waaruit blijkt dat de sessies niet wordt gestart, of hoe (en waar) controleer je dit?

I'm confused.

Wat hebben session cookies (client side) te maken met de fysieke sessie bestanden (server side)?

Het gaat ook om een secure domein (4e parameter)?

Citaat van AarClay

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:

Citaat van user

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

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

Citaat van AarClay

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?

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.

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.

Citaat van binkkie

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

Sidenote: iwstats, is dat een zelfgebouwd ding? Lijkt er wel op, een aanroep van http://iwstats.nl/data/checklogin.php levert:

Notice: Undefined index: username in /home/brandld176/domains/iwstats.nl/public_html/data/checklogin.php on line 12


Notice: Undefined index: password in /home/brandld176/domains/iwstats.nl/public_html/data/checklogin.php on line 13
null

Da's niet zo best.

Ik hoop dat je je er ook echt van vergewist hebt dat het aan de hosting ligt, en niet aan de applicatie. In het laatstgenoemde geval heeft het schakelen van host mogelijk niet zoveel zin :p.

Misschien moet je (los van rechten zodat je toegang hebt tot de bestanden) ergens expliciet in de configuratie van je webserver aangeven dat je toegang mag hebben tot een directory buiten /var/www.

En als dat niet lukt zou je kunnen overwegen om het bestand weg te schrijven op een plek zodat de website er wel bij kan.

In beide gevallen denk ik echter dat je via configuratie zult moeten aangeven dat een proces ergens toegang toe mag hebben want het klinkt niet alsof het aan de rechten ligt - de applicatie(s) zullen zichzelf restricties hebben opgelegd op welke plekken zij (van zichzelf, dus niet op grond van rechten) mogen kijken. Dit is althans mijn vermoeden.

Misschien is dit een oversimplificatie van de oplossing maar ik kan zogauw twee manieren bedenken. In beide gevallen is de crux dat je een soort van "weken-dimensie" opspant zodat je altijd evenveel entries hebt.

1. via de query
Indien je een aparte tabel hebt voor de weken waarin je een LEFT JOIN kunt doen tegen je data op week-id. Is er geen entry krijg je netjes een NULL-kolom. Een wellicht minder nette variant hiervan is dat je dit op een andere manier binnen de query deze dimensie opspant met statische waarden (en een UNION ofzo?) of met een subquery (waarbij je iets met DISTINCTe weeknummers doet?). Maar wat ik zo in de gauwigheid zie is dat het weeknummer geen aparte entiteit is in je data.

2. in code
Vul per team standaard een array met nullen ter lengte van het aantal weken en prik dan de resultaten in op de goede week. Ik denk dat dit het makkelijkste is op dit moment.

Observatie: omdat de week/het weeknummer blijkbaar een belangrijke rol in dit geheel speelt is het misschien verstandig om deze (mogelijk redundant) in een aparte kolom / tabel op te slaan zodat je hier (stukken) makkelijk(er) mee kunt rekenen.

Citaat van M.Beers

Dat vervolgens andere hierover lopen te janken dat het niet goed zou zijn tja daar zijn de moderators voor die dit prima kunnen bepalen of iets wel of niet nuttig is..

Moderators hebben niet tot taak reacties te censureren maar kunnen discussies threads wel bijsturen. Tenzij een reactie heel erg offtopic gaat zouden deze in overleg aangepast of verwijderd kunnen worden. Maar niets is zo laf als deze maar gewoon zonder boe of bah verwijderen. Als je dat doet als moderator dan snap je niet helemaal hoe je je als moderator hoort te gedragen.

Ik had mij eigenlijk al teruggetrokken uit deze "discussie" precies vanwege de sentimenten die hier lijken te leven. Je woordkeuze ("janken") onderstreept dit ook - je staat niet open voor een andere insteek maar in plaats daarvan worden reacties onterecht ontdaan van (potentiële) waarde en inzicht waarbij mensen die de moeite nemen om te reageren voor schut worden gezet. Dat lijkt mij niet de bedoeling van een forum?

Als moderators ergens voor zouden moeten waken is het wel het onterecht denigreren van reacties, want dat zijn misselijke infantiele spelletjes die dit, of welk forum dan ook, onwaardig zijn.

Daarnaast ben je zelf met allerlei technische termen en constructies aan het strooien die beginnende OOPers mogelijk weinig zegt. Je zou natuurlijk ook kunnen uitleggen wat dit alles betekent en hoe je het toe zou moeten passen. Op een manier die uitgaat van minder kennis van zaken.

Wat was je oplossing?

Daarnaast: realiseer je je goed dat PDO niet specifiek geschreven is voor welke database dan ook.

Het gevolg hiervan is dat PDO ook niet op voorhand geconfigureerd is voor (optimaal) gebruik van welke database dan ook. Het is dan ook verstandig om veel zaken expliciet in te stellen bij creatie van het PDO-object.

Het venijn zit hem bij PDO dus in de staart. Ook al roept/claimt iedereen dat PDO makkelijk te gebruiken is omdat het handjevol klassen elke keer hetzelfde is onafhankelijk welke database je gebruikt (wat voor voordeel dat heeft is mij bijster, want de SQL is meestal database-specifiek), PDO gebruikt per database een aparte driver met database-specifiek gedrag. Dit laatste wil men gemakshalve nog wel eens vergeten of weet dit simpelweg niet.

Voordat je bekend bent met alle/de meeste details van de MySQL-driver ben je wel een paar weken verder.

Net onder het wateroppervlak regelt de driver een heleboel zaken waar je geen erg in hebt of die mogelijk niet zouden werken zoals je normaal zou verwachten. Dit kan resulteren in onverklaarbaar gedrag wat bijna altijd prima te herleiden valt naar (het ontbreken van) driver-configuratie.

Zorg dus dat je je hier vertrouwd mee maakt, of, als je toch enkel een MySQL-database gebruikt , overweeg dan het gebruik van MySQLi.

De quotes (enkele aanhalingstekens) om de kolomnamen verwijderen.

Heel concreet, en nogal overvloedig, verander regel 6 naar:

$sql = $this->db->prepare("INSERT INTO users.logs (user_id, opponent_id, amount, detail, type_log) VALUES (? ,? ,?, ?, ?)");

Voor kolomnamen dien je geen quotes te gebruiken of, en dit is MySQL-specifiek (dacht ik) en/of maakt een en ander niet echt veel beter leesbaar, je plaatst deze tussen `backticks`.

Beginnen met een framework (dat wil zeggen: starten met oop programmeren door meteen een framework in te duiken) is toch een beetje via de zijdeur binnenkomen. Het zal ook per persoon verschillen hoe makkelijk zij dingen oppikken omdat er al een aantal lagen abstractie zitten tussen wat je doet (basishandelingen in PHP en database) en wat je programmeert (het voorbeeld wat je aanhaalt, een query opbouwen aan de hand van een database access layer of wat dan ook).

Dat is allemaal goed en wel maar je mist dan potentieel fundamentele kennis van de werking. Nu hoeft dat niet per se een belemmering te vormen, je hoeft niet te weten hoe een verbrandingsmotor werkt om een auto te kunnen besturen maar ik zou daar toch een onbehaaglijk gevoel bij krijgen als iemand slechts vertrouwd is met wat apentruuks in een framework en daarbuiten niet zoveel.

Zo kende ik iemand die redelijk goed kon werken binnen Drupal, maar geen idee van het concept "sessies" of "webservers" had. Dan mis je wat mij betreft toch wat bagage.

Wanneer iemand halverwege een boek begint te lezen kun je niet verwachten dat ze het hele verhaal compleet begrijpen.

Maar goed, in deze thread wordt de bal toch een beetje overgespeeld naar elkaar dus ik denk dat ik het hier maar bij laat met het zeggen dat we het eens zijn met elkaar in die zin dat we het niet eens zijn met elkaar.

@MBCompany dat zal wel werken, maar dan voer je (wederom) elke keer een query uit om een kolom op te vragen. Waarom lees je niet alle data van een user in 1x uit? Ook voer je nog steeds geen controle uit of er uberhaupt een resultaat is met ee num_rows check ofzo. Het ophalen van de userdata zou je al direct bij de creatie van het user-object kunnen doen, waar je ook meteen de controle uitvoert of de user wel bestaat. Vervolgens zou je een get methode kunnen maken die uit het object de eerder opgeslagen informatie ophaalt. Dat scheelt je een hoop queries...

Citaat van D.Oomens

Moet je echt alles afkraken FangorN?

Nee, ik heb gewoon een lage tolerantie voor ongefundeerde stellingen.

Citaat van Patrick

Omdat toevallig één persoon niet gebruikt maakt van de techniek zoals jij dat doet wilt niet per definitie zeggen dat het fout is...

Dat zeg ik ook niet. En dit argument kun je ook 180 graden draaien. Het gebruik van een framework is niet per definitie beter. En het gebruik van zelf een minimale opzet schrijven is niet per definitie slechter maar ik bespeur een zeker... ongegrond enthousiasme voor eigen favoriete framework X (het vogeltje zingt zoals het gebekt is, I suppose).

Werken met een framework zegt ook niets over de kwaliteit van eigen geschreven code. De scriptkiddies die gisteren baggerscripts schreven hebben ook een skillup gehad en schrijven nu baggercode in frameworks. Vroeger waren dit handgranaten, nu hebben ze de beschikking over middellange afstandsraketten.

Ik geloof wel in een bepaalde volgorde. TS moet bij het begin beginnen en niet tig hoofdstukken overslaan. Eerst maar eens wat in native (OOP) PHP worstelen voordat je meer complexiteit introduceert anders zie je door de bomen het bos niet meer.

Speaking of which, als ik andere topics bekijk mogen sommigen ook wel eens bij tijd en wijlen terugbladeren in hun kookboek. Dat kan nooit kwaad.