Heb je dit al gelezen?
https://redis.io/commands/auth

Niet rottig bedoeld, maar waarom een partner zoeken voor je forum die nog niet echt storm loopt? Misschien eerst even laten opbloeien? Want het ziet er nog niet echt succesvol uit en winst zal het nog zeker niet maken.

https://www.mmobomb.com/browsergames/mmorpg

Hier staan er zat die je kan spelen.
Als ze niet goed werken, dan lijkt me dat een bug die je moet melden bij de maker. Die zullen je in het algemeen vaak dankbaar zijn. Wie weet verdien je nog wel wat credits ;).

Rechten al goed gezet?

Heb je al wat diagnostische software geprobeerd, en je SSD gecontroleerd?

Je kan ze ook apart loggen, en zelf bijvoorbeeld er een ErrorID aan hangen, zodat je fouten makkelijker kan terughalen, als iemand je de foutcode doorgeeft.

Maar persoonlijk vind ik het iets van de webserver die het hoort te loggen. Er kan immers ook wat aan die kant fout gaan wat gelogd dient te worden.

Maar ook hier verschillen de meningen en is er niet één beste en vaste oplossing.

Ook kan je dergelijke PHP-scripts overschrijven...

Welke aanpak iemand kiest is net wat iemand fijner vindt. Blijkbaar kies jij voor het laatste. Maar ik vind dit meer een taak voor de webserver i.p.v. een eigen PHP-script. En helemaal als dit niet op userniveau wordt ingesteld.

Een error_log houdt elke webserver wel bij. Of en hoe je erbij kan, hangt van het hostingplatform af. En anders kan je zit wel beïnvloeden met een simpele .htaccess of php.ini. Afhankelijk wat je webserver draait (zie daarvoor de output van phpinfo() en kijk naar de 'Server API' ).

https://perishablepress.com/how-to-enable-…g-via-htaccess/
https://mediatemple.net/community/prod…ing-via-php.ini

Ik vind hem erg kaal. Er kunnen best wel wat meer plaatjes/icoontjes bij, en wat variteit in lettergroottes en -kleuren. Misschien is een minder standaard font ook een idee. En een logo maakt het geheel zeker meer af.

Maar input van buitenaf in een query dien je ook te escapen. En dat zeg je weer niet in je voorbeeld. Maar verder is het duidelijk hoor.

Kijk en daar zijn inderdaad de meningen over verdeeld.

Als iemand een fout maakt in de configuratie? So what..... Dat test je toch nooit 'live' uit?

Geen idee of de boel in PHP ook breekt?

Citaat van FangorN

Als ik het oorspronkelijke bericht lees is dit volgens mij ook wat de topicstarter wil.

Hierover verschillen de meningen, maar als er iets wijzigt in het formaat voor weergave van datums zou dit inhouden dat je queries zou moeten aanpassen. Hoe je iets presenteert zou zo dicht mogelijk bij de presentatielaag geregeld moeten worden, dus bij voorkeur in code boven gepriegel in de database.

Dan kan je er ook een configuratie-optie van maken. Dan hoef je geen queries aan te passen

Waarom wil je het in eigen formaat opslaan?

Is het niet raadzamer om de uitvoer aan te passen met DATE_FORMAT() , en de invoer ook om te converteren naar YYYY-MM-DD?

En ikzelf zie die data als input, wat je sowieso moet escapen. Misschien is er verwarring in de communicatie. @FangorN Laat anders dan een voorbeeld zien. Ik ben benieuwd.

Ja, nu heb je het over output-escaping volgens mij. Die hoor je ook inderdaad te filteren met htmlentities of htmlspecialchars.

Want het is natuurlijk niet de bedoeling dat iemand mysqli_real_escape_string() in iets anders dan een query gebruikt.. 8)7

Huh?
Welke input zie je nog meer dan mijn genoemde globals? Die moet je sowieso s
al escapen!

Als je een waarde van een fetched result hebt (bijv. $data['user']) in je WHERE-clausule, escape jij die dan ook?

Citaat van dmeigenaar

Ik heb tot dus verre niet in enkele query mysqli_real_escape_string() staan.
Enkel bij queries die wat toevoegen zoals $_POST bijvoorbeeld.

Is het dan verstandig om uit voorzorg mysqli_real_escape_string() bij elke query toe te voegen?

Alleen als je de waarde kan manipuleren, zoals bij $_POST, $_GET, $_COOKIE, $_SESSION, $_SERVER en $_ENV. De laatste twee zijn wat lastiger, maar het zou in de praktijk kunnen.

Tuurlijk. Spreekt voor sich dat ik hem toen aanbevolen om mysqli_real_escape_string() te gebruiken. Nadat ik zag dat de rest in zijn query wel prima was.

Ik heb wel eens gezien dat iemand ook een blacklist had van 'forbidden words' voor in een SQL-query. Eén daarvan was WHERE.

Toen bleek dat station Purmerend Overwhere opeens niet geaccepteerd werd..

Wat heeft het strippen van tags met sql-injection te maken?