Posts by FangorN

Citaat van wimmpie

beginnende programmeurs zijn die een shared server gebruiken

Ai. Trekken zij ook allemaal code daar vandaan om daar dan aan te werken? Hoe kun je dan garanderen dat jullie niet elkaars werk aan het overschrijven zijn? Hopelijk maak je ook gebruik van een soort van gedistribueerd versioningsysteem want het klinkt een beetje alsof dat de missende schakel is. En dat is wellicht nog een van de belangrijkste dingen die je moet regelen wanneer je met een club aan het programmeren slaat: afspraken en procedures omtrent de ontwikkeling en disitributie van code(wijzigingen).

Citaat van AarClay

De UBB-en textopmaak hier op ICTscripters werkt behoorlijk ruk.

Kun je ook aangeven wat er aan scheelt? En ergens een suggestie tot verandering/verbetering plaatsen? Dit is niet erg opbouwend, maar heb je ook een redenering waarom en wat er dan zou moeten veranderen? Deze heeft inderdaad wel een aantal quirks, maar wellicht is de kans dat er hier iets mee gedaan wordt (aanzienlijk) groter dan een zekere andere site die ik ken *kuch*.

Heb je jezelf ook al de volgende dingen afgevraagd:
- wie is je (precieze) doelgroep?
- hoe wijkt dit forum af van ieder ander (spelspecifiek) forum? kun je fortnite-spelers iets extra's bieden? oftewel, heeft dit meerwaarde t.o.v. elk willekeurig run-of-the-mill forum rond een bepaald thema?
- is een forum wel het goede medium? zit niet iedereen tegenwoordig op een ander platform (bijv. discord)?
- kun je naast een forum ook nog andere features aanmaken, bijvoorbeeld een gallerij met filmpjes waarop men kan stemmen ofzo, of die leden zelf kunnen plaatsen / linken aan account?

Enne, geen https?

En wat @AarClay zei, no offense, maar het oogt op dit moment een beetje sober.

SPA / onepage - potato potahto? :p

Bedoel je een Single Page Application? Of een soort van AJAX-applicatie? Dit (eerste) kan in principe heel lichtgewicht met wat JavaScript/jQuery en hyperlinks die naar bookmarks (page.php#chapter-x, page.php#chapter-y etc.) scrollen. Heb eventueel wel ergens een snippet liggen.

Weet niet helemaal hoe het zit met SEO maar volgens mij wordt dat tegenwoordig wel aardig ondersteund.

Waar is deze pagina precies voor bedoeld?

Hm, bovenstaande regexp doet bijna wat je wilt.

De volgende cases worden ten onrechte geaccepteerd:
1.
00.000

Ik denk dat de volgende regexp iets nauwkeuriger is, die (beter) lijkt te doen wat je wilt:
#^(0|[1-9][0-9]*)(\.[0-9]{1,3})?$#

Het bedrag voor de punt mag ofwel enkel bestaan uit het cijfer nul, of bestaat uit een of meer cijfers, maar moet dan beginnen met een cijfer gelijk aan of groter dan 1.
Indien het bedrag een punt heeft bestaat het bedrag achter deze punt uit ten minste één decimaal, en maximaal drie decimalen.

Testjes

<?php
/*
https://www.ictscripters.com/Thread/24643-check-string-op-bedrag/
*/
$tests = array(
    '0.522' => true,
    '1' => true,
    '1562.1' => true,
    '100.001' => true,
    '1.0004' => false,
    '1...50' => false,
    '1.' => false, // accepted with pattern #1
    '00.000' => false, // accepted with pattern #1
    '0.000' => true,
    '0.00' => true,
    '0.0' => true,
    '0' => true,
    '.05' => false,
    "1.250\n" => true, // gotcha
);


// #1
$pattern = '#^[0-9]+(\.)?[0-9]{0,3}$#';
// #2
$pattern = '#^(0|[1-9][0-9]*)(\.[0-9]{1,3})?$#';


foreach ($tests as $test => $expectedResult) {
    $match = preg_match($pattern, $test) === 1;
    if ($match === $expectedResult) {
        echo 'pattern '.$test.' does'.($expectedResult ? '' : ' not').' match, as expected.<br>';
    } else {
        echo '[error] pattern '.$test.' did not match expected result.<br>';
    }
}
?>

Gotchas / aandachtspunten:
* preg_match() retourneert het cijfer 1 als het patroon matcht. Het loont dus de moeite om hier expliciet mee te vergelijken ( === 1).
* little known fact: de modifier $ matcht ook één newline character (\n - zie de laatste case). Wellicht doe je er ook verstandig aan om het resultaat (misschien ten overvloede) nog te trimmen.

Wat je natuurlijk ook kunt doen is het veld voor het bedrag splitsen in twee velden: een voor het deel voor de punt, en een na de punt. Op die manier wordt de controle op het numerieke gedeelte (x2) natuurlijk ook een stuk eenvoudiger en heb je minder kans op fouten tijdens invoer.

Nu ja, als het vraagstuk of het antwoord triviaal is... soit.

Maar dat lijkt mij meer een taak voor een moderator. Volgens mij wordt op stackoverflow zo'n topic dan gelocked (te triviaal, te generiek, reeds ergens anders beantwoord (duplicaat)), maar nooit echt verwijderd.

Het komt nogal eens voor dat iemand nogal haastig een vraag stelt zonder dat er zelf eerst wat onderzoek wordt uitgevoerd. De belangrijkste reden voor een verzoek tot verwijdering is meestal het besparen van gezichtsverlies (op korte of lange termijn, bewust of onbewust).

Dit motiveert mensen helaas niet altijd tot het wat langer wachten met het stellen of uitbesteden van een vraag .

Ook gaat dit mogelijk voor problemen zorgen zodra potentiële werkgevers eens gaan Googlen op jouw naam terwijl je in je studententijd iets te fanatiek je huiswerk probeerde uit te besteden. Op dat moment gaat men wel eens over op radicalere stappen zoals het verwijderen/anonimiseren van complete accounts.

Een forum zou je ook een beetje op moeten voeden zodat je op een gegeven moment je eigen vragen, en wellicht die van anderen, kan beantwoorden.

De vraag stellen is hem beantwoorden. Dit is niet spottend of neerbuigend bedoeld, maar als je je verstand gebruikt kom je meestal al een heel eind. Probeer eerst iets zelf op te lossen. Een forum kan je vervolgens verder helpen als je toch vastloopt. Natuurlijk is het makkelijker om dingen te vragen, maar stiekem weet je zelf ook al een hoop.

Citaat van Twan025

Ook als het om een klein vraagje gaat wat binnen 5 minuten al was verholpen moet dit jaren erop blijven staan

Dat zegt meer over de vragensteller dan over het forum .

Dat is niet het punt, en nee dat vind ik niet vreemd. Een moderator zou een topic moeten kunnen verplaatsen of verwijderen, maar dat is meer uitzondering dan regel als het goed is.

Tenzij je je account opheft en je je hele hebben en houden wilt laten opschonen met al die nieuwe privacy shizzle, dat lijkt mij de enige situatie waarin je zelf dingen kunt (laten) verwijderen.

Of wanneer je je eigen posts moedwillig leegmaakt, maar dat lijkt mij dus niet de bedoeling :p.

Het doel van een forum is tevens een naslagwerk, zodat mensen met soortgelijke problemen hier terecht kunnen.

Het lijkt mij dan ook onnodig en ongepast om dingen op deze manier te verwijderen.

Op deze manier blijven (dezelfde) mensen dezelfde vragen stellen... oh wait :).

SSD's van tegenwoordig zijn al een stuk beter dan in het verleden dacht ik, ook werkt de hardware die de SSD aanstuurt nu ook meer zodat niet elke keer dezelfde geheugenplekken overschreven worden, wat slijtage verder kan voorkomen. Wat volgens mij het belangrijkste is is dat je SSD niet ramvol staat. Ik kan mij vergissen, maar als je dat ding grofweg 25-50% vrijhoudt dan kan dat volgens mij de levensduur al fors verbeteren.

Ik ben niet bekend met het fenomeen dat je schijf steeds verder zou slinken eerlijk gezegd.

Hierbij doe je een aantal aannames die deze opzet ook min of meer onmogelijk maakt he:
- je werkt samen
- je maakt gebruik van git (of een soort van "gedeeld" versioning systeem)
- er is geen mechanisme om standaard configuratie te overrulen

Op die manier kan ik ook voorwaarden verzinnen die elke aanpak buiten spel zet. Als jij de enige partij bent die een applicatie ontwikkelt en beheert werkt dit prima. En uiteraard moet je jezelf niet vastprogrammeren zodat dingen niet meer flexibel zijn. Dat heb ik ook nooit voorgesteld.

Maar nogmaals, daar ging deze hele thread niet over. De topicstarter moet gewoon zorgen dat 'ie fouten kan opvangen, anders kun je niet eens beginnen met een analyse van het probleem.

Citaat van sjaakmans

Stel je werkt samen met meerdere partijen, die hebben dan gelijk al je gegevens als je je config meestuurt naar bijvoorbeeld git. Een .htaccess daarentegen kan standaard waarde bevatten voor zowel de live- als testomgeving.

Sja, je kunt altijd uitzonderingen verzinnen.

Maar laten we dit eens verder analyseren. Wat zou hier dan op zijn minst instaan? Database credentials waarschijnlijk. Hoe erg is dat? Een lokale ontwikkelomgeving kom je niet bij, een test/acceptatie-omgeving: misschien? Als je externe connecties accepteert en/of phpMyAdmin (lol) hebt draaien ofzo kunnen ze bij de database. Wat voor baat zou een gelieerde partij hebben bij het ingooien van jullie gezamenlijke ruiten? En als blijkt dat je geen afspraken kunt maken met zo'n partij dan is het hek sowieso van de dam. De live omgeving? Daar kunnen jullie als het goed is allebei bij als je samen ontwikkelt.

Probleem?

Citaat van sjaakmans

Het lijkt mij niet logisch als je webserver echt alle errors logt.

Errors zijn er niet voor niets. Zolang je ze logt op de goede plek zie ik geen probleem. Servergerelateerde errors horen in een log thuis die zich bezighoudt met de gesteldheid van de server. Applicatiegerelateerde errors (en exceptions) horen thuis in logs die toegespitst zijn op het wel en wee van je applicatie. Zolang je zelf wat overzicht creëert kun je bijhouden wat je wilt zonder dat je door de bomen het bos niet meer ziet.

Natuurlijk kun je tunen wat je logt. Maar iets op voorhand onder het tapijt vegen lijkt mij geen goede strategie. Ik heb liever dat ik alle meldingen en waarschuwingen aan heb staan en dat ik geen meldigen krijg dan dat ik de helft uitzet en eigenlijk niet weet wat ik negeer.

Citaat van AarClay

Ook kan je dergelijke PHP-scripts overschrijven...

Yup. Maar een config.php overschrijven met een config.php waar de informatie van alle omgevingen in zit heeft geen effect. Een .htaccess die je van dev/test naar productie kopieert heeft meestal verstrekkendere gevolgen.

Bijkomend voordeel: deze config.php kun je zelfs versionen. Het .htaccess bestand niet, omdat die per omgeving verschillende inhoud heeft.

Dit is naast persoonlijke voorkeur dus ook een stuk minder foutgevoelige oplossing.

Taak voor de webserver? Dunno - dit zijn applicatie-instellingen. Die lijken mij thuishoren... in de applicatie.

Dat is wel een artikel uit 2008.

Wanneer PHP in CGI-modus draait dan resulteren het gebruik van php_flag en php_value blijkbaar in internal server errors.

Mogelijk kun je wel een php.ini instellen, of een .htaccess-bestand gebruiken, maar dan wel met het formaat <setting> = <waarde>.

Maar alle relevante directives (error_reporting, display_errors, display_startup_errors, error_log, meer?) zijn overal instelbaar (PHP_INI_ALL) dus je zou dit net zo goed in PHP zelf kunnen doen, bijvoorbeeld met een switch-statement op grond van $_SERVER['SERVER_NAME'], zodat je één configuratiebestand hebt voor alle omgevingen, in plaats van serverspecifieke .htaccess-bestanden die je wellicht per ongeluk overschrijft met alle gevolgen van dien.

Citaat van Dennii

error 500 codes maar geen errorlog

Dan zou ik eens kijken hoe dat zit, anders valt er niet zoveel te analyseren.

Heb je ergens ook een werkend voorbeeld?

In het ergste geval een E_WARNING of E_STRICT melding, in het minst erge geval wordt false geretourneerd. Dus wat merkt een gebruiker hiervan, wellicht geen datum op het scherm? Dat kan onhandig zijn, maar dan ligt tenminste niet je hele pagina in duigen.

Je moet ook gewoon kijken naar de impact van een ontwerpbeslissing. Een constructie waarbij rechtstreeks queries gemanipuleerd worden en dus over tijd anders kunnen gaan werken... I don't know man... Voor de goede orde zou je dan ook alle queries moeten nalopen waarin deze constructie wordt gebruikt wanneer deze opzet verandert, om het maar niet te hebben over gevallen waarbij dit dan ook gebruikt wordt om records te filteren en te sorteren (dat is dan natuurlijk slecht ontwerp van de query zelf uiteraard, maar als het kan gebeuren dan gebeurt het) *brrrr*.

Nope, houd functionaliteit die bepaalt hoe iets er uitrolt op het scherm maar lekker ver weg van je database. YYYY-MM-DD werkt prima in een database. Geen enkele reden om daar al vast te leggen hoe iets er uit komt te zien. Haal het eruit zoals het er in zit.

Een ander puntje voor @Jayszon010: voor datums is dat dan niet direct zo interessant, maar als er ook tijden aan komen te hangen: zorg dan ook dat alles in één tijdszone wordt vastgelegd, bij voorkeur UTC. Dit maakt het omrekenen van DATETIMEs naar andere tijdszones een stuk makkelijker, je hebt dan immers altijd hetzelfde uitgangspunt.

Dit is in zekere zin een "nadeel" van DATE en DATETIME, dit zegt je niets over de tijdszone waar dit betrekking op heeft.

Het heet dan alleen geen input. Je output DATA in de SQL-context. Dit is vervolgens weer input voor je database :). Het hangt er maar vanaf vanuit welk perspectief je kijkt.

Als je iets vanuit A doorgeeft aan B dan is dat vanuit A gezien output en vanuit B gezien input. Je kunt niet in beide gevallen spreken van "input". Alleen uit optiek van B is dit input.

Het escapen van input zou zoiets zijn als htmlspecialchars() heengooien over data die de database ingaat. Maar dat streeft het doel voorbij en heeft zijn eigen problematiek. In heel veel gevallen is het op voorhand escapen van input (en dat zal dus altijd voor een of meer specifieke contexten zijn) niet handig. Het escapen doe je doorgaans pas... als (dus net voordat) je het gebruikt in een specifieke context. Hier zijn trouwens wel uitzonderingen op, maar dat is echt maar een handjevol.

Ten einde allerlei spraakverwarring te voorkomen en het wijdverbreide devies is het dus nog steeds "filter input, escape output" en dus niet "escape input". Als jij het iets anders wilt noemen (filter banaan, escape pindakaas) mij ook best.

* zucht *

Citaat van AarClay

En ikzelf zie die data als input, wat je sowieso moet escapen.

Input filter je, output escape je.

DATA kan zowel input als output zijn.

Beschouw code.php?id=12

$_GET['id'] is invoer van buitenaf (USER DATA).
Deze kun je mogelijk filteren je om te zien of deze aan een bepaald formaat voldoet als je voor het gebruik hiervan bepaalde eisen stelt.
Bijvoorbeeld een check om te zien of dit een positief geheel getal is, ten minste gelijk aan het cijfer 1 zodat je in ieder geval een zekere garantie hebt dat het een geldig auto-increment id bevat.

$_GET['id'] is vervolgens ook uitvoer als je:
- deze weergeeft op je scherm (HTML-context)
- deze vervolgens (na validatie) verwerkt in een query (SQL-context)

Indien je deze DATA dus weer als uitvoer ergens in verwerkt dien je deze uitvoer onschadelijk te maken. Altijd en overal. Tenzij je hier een gedocumenteerde reden voor hebt om dit niet te doen.

Citaat van AarClay

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

Precies, en dan pas je dat formaat toe a.d.h.v. een PHP-functie, en niet in een placeholder in je queries, zodat het niet mogelijk is dat het foutief wijzigen van deze config variabele complete queries breekt en/of je site lamlegt.

Als je dit wel zou doen - hoe zou je dit dan op security-gebied netjes regelen? Dan zou de validatie van de format-string wel heel erg streng moeten zijn. Escapen van deze format-string wordt wellicht ook problematisch als deze karakters bevat die binnen SQL betekenis hebben.

Als je dit gewoon in PHP regelt is de impact ook veel beperkter als het format fout is, en heb je tevens voorgenoemde beslommeringen niet.