de invoer ook om te converteren naar YYYY-MM-DD?
Als ik het oorspronkelijke bericht lees is dit volgens mij ook wat de topicstarter wil.
DATE_FORMAT()
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.
Hoe je DATA escaped hangt van de context af waar je deze DATA gebruikt.
Maar wellicht moet deze hele discussie naar een ander draadje verhuisd worden.
Het is een misvatting om te denken dat je klaar bent met escapen wanneer de data in de database zit. Dit moet je gewoon altijd en overal doen, tenzij je een (gedocumenteerde) reden hebt om dit niet te doen.
Het altijd consequent escapen van wat voor DATA dan ook is ook veel makkelijker, ik heb al eerder uitgelegd waarom.
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.
Nou, nee dus. Data in je database kwam oorspronkelijk ook uit $_POST. Deze -of liever gezegd, ALLE input- zou je dus nog steeds op dezelfde manier moeten behandelen. Altijd.
En alles van tevoren al onklaar maken (het escapen van input) is hiertoe geen oplossing.
Het is helemaal niet erg als er potentieel "gevaarlijke data" in je database zit, zolang je deze maar op een uniforme manier behandelt. Wanneer je output altijd escaped is dit namelijk geen enkel probleem. Natuurlijk moet je zoveel mogelijk vantevoren valideren (filter input) maar dat neemt niet weg dat je alle data op dezelfde manier blijft behandelen. Dit houdt niet op als het de database in gaat.
Niet zozeer of uitsluitend uit voorzorg, maar meer om je werkwijze te simplificeren en te standaardiseren. Het is gewoon veel makkelijker om alles gewoon consequent te escapen, tenzij je een speciale (en gedocumenteerde) reden hebt om dit niet te doen.
Zoals eerder aangegeven, als je dit niet overal doet dan kan elke keer de vraag rijzen of je bewust niet ge-escaped hebt of dit per ongeluk vergeten bent. Je zou hier dan elke keer over na moeten denken en jouw code moeten herinspecteren. Ain't nobody got time for that.
Dit creëert ook een groter bewustzijn. Eigenlijk zou je je te allen tijde moeten afvragen als je met DATA uit een externe bron werkt of deze ge-escaped moet worden. Een externe bron kan ook jouw database zijn, deze bevat namelijk (indirect) ook USER DATA. Een goede instelling is om deze nooit te vertrouwen. Zelfs niet als deze in je database zit.
Het is echter niet de bedoeling dat je op voorhand alles voor een bepaalde context escaped waar je deze DATA niet direct voor gebruikt. Zo is het niet verstandig om bijvoorbeeld htmlentities() over tekst heen te gooien als deze de database in gaat omdat je die op den duur mogelijk gebruikt/weergeeft in een HTML-context. Vermijd het escapen van input, het (bredere) devies is nog steeds
filter input, escape output
Met de nadruk op output, oftewel, als je data in een bepaalde context gebruikt, dan is het zaak om te escapen. Je zou je in ieder geval altijd moeten afvragen of er ge-escaped moet worden en dit dan ook altijd doen, en zoniet, zou je een aantekening moeten maken die aangeeft waarom dat daar niet nodig of gewenst is.
Natuurlijk kun je de behandeling van DATA wel wat versoepelen op het moment dat geregistreerde gebruikers deze invoeren omdat je dan al iets beter weet wie deze personen zijn, maar dit zou nooit mogen resulteren in het zomaar accepteren van wat voor data dan ook of het blindelings verwerken hiervan, dit zou nog steeds aan alle (veiligheids)regels moeten voldoen. Je zult die data nog altijd valideren (filter input) en escapen in queries (escape output).
Zolang je alle delen die afkomstig zijn van een externe bron (de DATA delen in je SQL) op de juiste manier escaped dan is het onmogelijk om de werking van de query te veranderen. Hier hoef je dus helemaal geen ingewikkelde constructies voor te maken. Wanneer je met MySQLi werkt vergt het enkel wat discipline en als je van PDO gebruik maakt dan gebruik je als het goed is / ben je veroordeeld tot prepared statements. Ook daar geldt dat als je dit op de wijze toepast zoals het bedoeld is er eigenlijk niets mis kan gaan.
Neemt niet weg dat je altijd waakzaam moet zijn en je je altijd af moet vragen:
- in welke context je zit
- waar de data vandaan komt
- of er een speciale reden is om niet te escapen (in wat voor context dan ook), en dit anders wel te doen
Persoonlijk zou ik hem dan ook nog als int casten.
Dat heeft niet zoveel zin. Als de data afkomstig is van een externe bron is het beter om de waarde gewoon te valideren. Voldoet deze niet aan het formaat dan gewoon afkeuren / programma staken. Een typecast probeert vaak recht te buigen wat al krom is. In het gunstigste geval levert dit dan een query op die weliswaar syntactisch correct is, maar semantisch nog steeds onzinnig is.
Neem bijvoorbeeld code.php?id=aap en je verwacht dat $_GET['id'] een getal bevat (vaak een auto increment id). Een typecast van "aap" levert je dan het cijfer 0 op. Een query met die informatie levert dan nog steeds niet het gewenste resultaat op. Valideren is bijna in alle situaties beter.
Het geven van typehints is dan wel leuk enzo, maar tenzij je PDO::ATTR_EMULATE_PREPARES uitzet wordt volgens mij niet van het zogenaamde binary protocol gebruik gemaakt in communicatie met je (MySQL) database. Dit had dacht ik tot gevolg dat alles gewoon als string wordt behandeld en dan zijn die typehints dus nogal loos.
# Anti SQLi (SQL Injection)
Vervolgens wordt een array van verboden waardes gegeven. Realiseer je je goed dat dit een blacklist is. Het nadeel van blacklists m.b.t. securityzaken is dat als je een case vergeet dat daarmee je beveiliging effectief om zeep is. Het is beter om te definiëren wat wel toegestaan is in plaats van wat niet toegestaan is.
Overigens is het gebruik van real_escape_string() alleen veilig in combinatie met quotes, het een is niet veilig zonder het ander. Ook dienen alle character encoderingen in de pas te lopen want escaping-functionaliteit is hier zwaar van afhankelijk.
Nee, met escaping bedoel ik meer het ontdoen van enige speciale betekenis van tekstpassages in een bepaalde context.
Escaping is belangrijk om zaken als SQL-injectie tegen te gaan. Het beste lijkt mij gewoon om dit altijd consequent te doen, ook al is het soms niet direct nodig. Het voordeel hiervan is dat je DATA in queries altijd hetzelfde behandelt, en je je dus ook niet elke keer hoeft af te vragen of een passage bewust niet was ge-escaped, of toch per ongeluk was vergeten.
Kun je $stock_statuses niet gewoon doorgeven aan je template en daar dan een for-loop doorlopen?
Of, alternatief...
Template engines zijn leuk enzo, maar kun je dit niet ook gewoon via PHP doen? Qua syntax en code doe je namelijk nagenoeg hetzelfde.
Desnoods gooi je hier een object-saus overheen zodat je $status->name, $status->rate et cetera kunt gebruiken maar dan kun je nog steeds volstaan met enkel PHP.
Zou bovenstaande code (met name de database queries) niet in een transactie moeten staan? Wat als iemand meerdere keren tegelijkertijd (parallel) een coinflip doet?
Hoe zit het met escaping in zowel HTML als SQL?
En kun je $flipJ niet gewoon als HTML retourneren (waarom een json_encode)?
Nog veel belangrijker dan wat en hoe je iets programmeert zijn de keuzes waarom je iets op een bepaalde manier programmeert.
Actually, bij voorkeur zou alle zoekfunctionaliteit via GET moeten lopen, dit navigeert namelijk een stuk makkelijker (geen waarschuwingen van je browser of je de POST data opnieuw wilt versturen als je terugbladert in de historie), kun je zoekopdrachten bookmarken et cetera.
De truuk is dat je alle GET informatie ook definieert in het formulier.
De action van het formulier zou dus gewoon "index.php" moeten zijn (en de method "GET"), vervolgens voeg je een hidden veld toe aan je formulier met name "p" en value "nieuws". Deze wordt vervolgens na submitten samen met je zoekveld teruggeplakt in de action-link.
@Aaron heeft in zoverre gelijk dat het wel netter zou zijn om een zoekmachine vriendelijke URL te hebben voor de nieuwspagina, dus /nieuws o.i.d. in plaats van index.php?p=nieuws, maar voor de rest maakt het voor optimalisatie niet zoveel uit, omdat zoekmachines toch niet zelf (zoek)formulieren gaan invullen en die links gaan volgen voor zover ik weet.
(en in dit laatste geval is je action dus gewoon "/nieuws" en heb je geen hidden veld nodig)
Het oorspronkelijke bericht is waarschijnlijk bedoeld als kattebel, dan ga je ook geen compleet boek schrijven, maar maak je kort duidelijk wat je kunt en wat je zoekt. De topicstarter maakt dit in een paar zinnen duidelijk, en dat is toch wel lovenswaardig. Geen lange lulverhalen maar kort en to-the-point.
Om hier vervolgens een kilo zout overheen te gooien is lichtelijk overdreven.
Toegegeven, eerste indrukken zijn dan misschien belangrijk, maar om iemand te beoordelen op zo'n eenmalige confrontatie is op zijn zachtst gezegd kortzichtig.
Het is natuurlijk heel makkelijk om een (te) snel oordeel te (vormen en te) geven over iemand die je niet kent (hoi internet), maar dat is dan ook nauwelijks ergens op gebaseerd.
Relax eens een beetje gasten.
"samentrekking" is wellicht een slechte vertaling van "afkorting" en Kürzel betekent in wezen hetzelfde. Mogelijk wordt daar een afkorting verwacht voor welke competie er wordt gespeeld? Bijvoorbeeld CL voor Champions League en EC voor Europa Cup? En wellicht was Kürzel een onvertaalde placeholder tekst ofzo, is dat voetbalsysteem van origine Duits toevallig?
Zoek anders eens naar wat sample data of een voorbeeld van wat je daar in kunt vullen. Maakt het systeem / de code / het formulier zelf daar niets duidelijk over? Wat voor melding krijg je als je daar iets / niets invult?
Oftewel, als je dit een beetje gestructureerd wilt aanpakken:
1. zorg je dat je applicatie een single point of entry heeft, dit bereik je o.a. met een .htaccess bestand die alles naar de voordeur van je applicatie doorstuurt
2. maak hierbij gebruik van een autoloader en organiseer je functionaliteit in klasses, bijvoorbeeld als volgt
3. vervolgens moet je alles aan elkaar knopen door middel van routing in je applicatie
Hoe uitgebreid dit laatste moet zijn hangt sterk af van de mate van vrijheid die je wilt hebben in de naamgeving van je URLs.
Je zou het met een groot switch-statement kunnen doen zoals @Ferhat.Remory eerder aanhaalde als je het aan de PHP-kant wild hard coden, wat nog steeds de voorkeur heeft boven lopen prutten in je .htaccess bestand waarschijnlijk, of je bouwt dit zelf verder uit, ofwel in code, ofwel deels in een database in een soort van boomstructuur.
Het voordeel van deze hele voorgaande opzet (.htaccess die alles naar index.php stuurt) is dat deze je voorbereidt op het verder afhandelen van een page-request in PHP zelf. In PHP kun je dit vervolgens helemaal programmeren zoals jij wilt. Dat is het hele doel van deze aanpak.
Je zou ook bijvoorbeeld de hele URL kunnen beschouwen en kijken of hier (voor deze URL-omgezet-in-een-klassenaam) een router(-klasse) voor bestaat, die de URL verder ontleedt en door kan mappen naar een klasse die de paginacontent verder genereert. Bestaat de router niet, eet je een stukje van de URL op en herhaal je dit proces. Hiermee heb je dan ook meteen het probleem opgelost wat bij dit soort URLs komt kijken, namelijk welk deel van de URL is "vast", en welk deel van de URL zijn in feite parameters voor het "vaste" deel.
Op het moment dat je geen autoloader gebruikt en/of een constructie met file_exists() hanteert dan heb je mogelijk ergens een afslag gemist waarbij je efficiënt gebruik kunt maken van een consistente naamgeving voor klassen. Je kunt namelijk een autoloader combineren met class_exists() - volgens mij was dit nog steeds / vele malen efficiënter dan file_exists(). Als je aangewezen bent op file_exists() dan wil dit in ieder geval / mogelijk zeggen dat er geen lijn zit in de naamgeving van je bestanden...
Maar een VPS lijkt mij wel een goed alternatief wanneer iemand weinig ervaring heeft. Ik bedoel, in dat geval hoef je minder kennis van zaken m.b.t. serverbeheer te hebben en kun je je aandacht richten op andere zaken? Een VPS kan best de uitkomst zijn na over en weer vragen.
Sorry dat ik het zeg, maar (op die van AarClay na) de meeste antwoorden op tigermaffia zijn vragen slaan werkelijk waar nergens op of zijn totaal niet inhoudelijk.
Hm, heb je mij antwoorden ook bekeken?
Dus als ik meer info wil over het opzetten van een marktplaats voor illegale praktijken op het deep web heb jij ook advies?
Het gaat op forums niet alleen over het beantwoorden van de vraag, maar er mogen ook tegenvragen gesteld worden om te achterhalen of de vragensteller wel nadenkt over wat 'ie doet. Dat is imo een morele / ethische verantwoordelijkheid die eenieder heeft die iemand anders denk te kunnen "helpen".
Het benoemen van potentiele nadelen van een aanpak ("heb je ook over X of Y nagedacht bij deze opzet") horen zeker bij de discussie.
Tenzij je uitsluitend wilt "faciliteren" door antwoord te geven op de vraag. Maar dan blijkt nooit of de aanpak eigenlijk wel goed was, en gaf je mogelijk enkel antwoord op de verkeerde vraag.
Of kijk is naar wat ik vroeger had; github.com/GreyDevbe/modrewrite
Waarom geen autoloader? 
En een blacklist voor URL-onderdelen? 
Een querystring parameter "route" die je meegeeft in de URL? Is ook niet nodig, lees gewoon $_SERVER['REQUEST_URI'] uit.
Wellicht is dit een beetje gedateerd allemaal?
Zie ook de tutorial.
Sterker nog, ik heb hier een hele blog reeks over. Die tutorial is slechts een snippet.
Trouwens, als je wilt dat die PHP-bestanden niet rechtstreeks benaderbaar zijn, wat ook kan gebeuren doordat namen van URL's en directories en namen van bestanden kunnen "botsen" (ook dit staat in de blogs uitgelegd) dat zet je je application directory toch gewoon buiten je webdirectory?
Harde schijf Opslagcapaciteit 1,12 TB
Geen RAID opstelling?
Enne, heb je bij je ISP wel een vast IP? Zou wat onhandig zijn als deze ineens verandert eh :).
Daarentegen, er valt zeker wel iets voor te zeggen om op die wijze een lokale ontwikkelserver te hebben. En dan liefst eentje die de live omgeving zoveel mogelijk weerspiegelt.
Ik vraag me af hoe je er in eerste instantie op komt dat je thuis je server zou willen hebben? Waaruit is deze wens ontstaan?
Ook weet ik niet of jouw Internet Service Provider hier regels voor heeft, of misschien kunnen ze je zelfs wel tegemoet komen met ondersteuning. Vraag is wel, bij welke provider zit je? En heb je al gekeken of hier informatie over is?
Zelf hosten (ofwel lokaal ofwel je eigen server in een of ander rack)... Ik weet het niet hoor. Als je dedicated hosting hebt, dan zorgen zij ook voor backups en nagenoeg 100% uptime. Dat soort garanties en voorzieningen heb je niet als je een computer aan het netwerk van je kabelboer hangt? Noch als je ergens rackspace koopt. Dan wordt er alleen maar bandbreedte gefaciliteerd en de rest mag je zelf uitzoeken lijkt mij.
Dan, waar ligt jouw expertise? Heb je ervaring met:
- systeembeheer
- programmeren
- front end design
- specifieke pakketten en de configuratie ervan
- het inrichten en beheren van content
Want, als je alles vanuit het niets opzet (waar je dit ook doet, intern of extern), zul je van al die zaken kaas gegeten moeten hebben lijkt mij.
En dan: stel dat je alle hardware zelf aanschaft. Wanneer is dan het omslagpunt qua kosten (en dan hebben we het niet eens over de tijdsinverstering) bereikt in tegenstelling tot een andere (dedicated?) oplossing?
