Ik neem aan dat dat een codesnippet is die een AJAX-response genereert?
Met de header zeg je dat je JSON retourneert, maar je echo'd $ab['image_data'], dus in de broncode daarvan staat waarschijnlijk "Array()" ofzo? Heb je de data in je response al bekeken? En wat voor (formaat van de) response verwacht de aanroepende partij?
Ik associeer script altijd met een enkel bestand met code die een enkele taak heeft. Eentje die ook vaak voor speciale doeleinden of op speciale tijdstippen wordt uitgevoerd.
Bijvoorbeeld: een importscript, een script om een database te dumpen et cetera.
Op het moment dat iemand aan een complete webapplicatie refereert als een script dan temper ik (al dan niet onbewust) al mijn verwachtingen.
Vooral als de auteur van deze code zelf spreekt over "scripts" en "scripting" zou ik waken voor het kopen van een kat in de zak.
Een andere serieuze indicatie waarbij getwijfeld moet worden aan de kwaliteit van het aangebodene is wanneer de aanbieding is opgesteld met een gebrekkige interpunctie of een zinsopbouw die doet denken aan een chatdienst.
Als je geen aandacht besteedt aan iets simpels, hoe kun je dan verwachten dat iemand aandacht besteedt aan iets complex?
een maffia spel zonder bugs en fouten
Ik weet verder niet hoe je jouw hosting hebt geregeld, mogelijk is al jouw code naar een noodserver gemigreerd waar er nog een oude PHP versie actief is maar dit is natuurlijk een noodoplossing. Deze server zal ook niet eindeloos onderhouden gaan worden en ook bestaat de kans dat deze op den duur (onaangekondigd) wordt gebumpt naar PHP 7+ dus het wordt hoog tijd voor een plan B denk ik :).
Maar veel te lastig te onderhouden op den duur.
Toch alleen als er regelmatig iets verandert in de databasestructuur?
Waarom zou je alles niet centraal opslaan in één database?
Dit is niet per definitie een probleem, totdat je een keer een lokale kopie nodig hebt van een specifiek hostname - dan zul je *alle* data binnen moeten harken terwijl je mogelijk maar een fractie nodig hebt? Het maakt een database een stuk minder mobiel / transporteerbaar.
Als je trouwens één database hebt voor meerdere hosts zou dit dus ook inhouden dat er een extra criterium in deze data moet zitten om de verschillende domeinen te kunnen onderscheiden? Dit is extra complexiteit die waarschijnlijk geen positieve invloed heeft op de performance. Tenzij de data voor elke site hetzelfde is, which begs the question, waarom zijn daar dan meerdere sites voor nodig?
Het hangt natuurlijk van de applicatie af of de opzet met een enkele database geschikt is, dit is niet een vraag met één universeel antwoord, maar een enkele database voor meerdere sites wordt al snel een baksteen, vooral als de sites veel (verschillende) content hebben. Je moet dan continu alles overal naar toe zeulen.
Op eenzelfde manier wil je waarschijnlijk ook bijbehorende media (documenten, filmpjes en afbeeldingen et cetera) gescheiden houden, zodat je al deze informatie per hostname vrij kunt selecteren en verplaatsen.
Ik heb het over één source die op meerdere hostnames draait, hé.
Ja, we hebben het allebei nog steeds over hetzelfde. Ik heb toevallig in het verleden gewerkt met zo'n constructie, maar dan wel met meerdere databases. Het betrof elektronische leeromgevingen. Elke hostname had toch wel een aparte insteek, met aparte cursussen en content, terwijl de codebase hetzelfde bleef. Dit was als ik het mij goed herinner niet het geval voor de media - en dat was best wel een ramp...
Heb jij een voorbeeld van een product (codebase) waarbij het volgens jou geoorloofd is om deze in een enkele database te stoppen terwijl de verschillende sites (niet triviale en) verschillende content hebben? Ik kan geen voorbeeld bedenken. En dan dus echt een database die de hostnames hun uiterlijk en inhoud geeft uiteraard, niet een gezamenlijke database die door meerdere sites als informatiebron (denk aan statistieken of meetgegevens) wordt gebruikt, ik snap dat je daarvoor één database wilt, zodat je één bron blijft houden. Maar toch niet als de content per site verschilt?
En je zou dus ook best beide kunnen hebben, zolang je maar in het oog houdt wat zinnig is om te delen, en wat beter is om gescheiden te houden.
Hopelijk start je je sessie ook ergens met session_start() - in elke script waar je $_SESSION gebruikt?
Waar wordt $_SESSION['captcha']['chosen'] bepaald, en wat zit hier precies in? Een cijfer tussen (van en met) 0 en (tot en zonder) 8? De bestandsnaam van een afbeelding?
Want in captcha.php lijkt het erop dat je $_SESSION['captcha']['chosen'] gebruikt als bestandsnaam, maar in het onderstaande codefragment ga je er vanuit dat het een cijfer bevat? Dat lijkt mij sowieso niet kloppen? Vervolgens gaat $pos dan helemaal de mist in, waarschijnlijk krijg je undefinex index waarschuwingen?
Hm, hier zat nog een $arr-mapping tussen. Die wijst van een index naar een afbeelding?
Zet anders het melden + weergeven van fout(melding)en eens aan, en/of controleer je errorlogs...
EDIT: de oriëntatie van de GD coördinaten en die van een HTML image submit is in ieder geval hetzelfde - beide hebben linksboven de oorsprong (0, 0).
NB het enige wat eigenlijk interessant is om te onthouden in de sessie is het actieve gebied van het juiste plaatje, zie niet helemaal waarom je alle positie informatie in de sessie zou moeten gooien? En dan heb je $_SESSION['captcha']['chosen'] waarschijnlijk ook niet meer nodig...
EDIT: na een header('Location: ...') hoort normaal een "exit", en dat zouden dan de laatste twee operaties van een actie moeten zijn. Nu wordt heel het script afgedraaid, inclusief het produceren van HTML en het opnieuw aanroepen van captcha.php via deze HTML, wat allemaal nogal overbodig is. Zorg dus ook voor een juiste programmaflow waarbij je verschillende acties (het weergeven van een formulier, het verwerken van dit formulier et cetera) ook echt gescheiden houdt.
In die gevallen zou ik één database gebruiken, en die gebruiken.
Ik hoop dat je één database per website bedoelt. Eén codebase met meerdere databases op basis van hostname is helemaal niet zo vreemd.
Heeft er toevallig iemand enkele site's waar ik goede PHP, HTML, MYSQL(i) Javascript Tutorials kan vinden.
Wil namelijk starten met eigen scripting.
Maar waar komt deze wens vandaan? Heb je ergens een website of applicatie gezien waarvan je dacht "Dit wil ik ook kunnen maken"? Of misschien een wat realistischere vraag "Hoe zou dit in elkaar zitten?". Met name dat laatste lijkt mij bijna een noodzakelijke voorwaarde: een soort van nieuwsgierigheid die wil weten hoe dingen werken. Daarnaast helpt het ook als je enig abstract denkvermogen hebt en ook kan een nette werkhouding helpen.
Het kan natuurlijk ook andersom: je hebt een idee van iets wat je zou willen bouwen - je hebt een soort van concept in gedachten maar weet niet direct hoe je dit zou moeten verwezenlijken. Vervolgens ga je dit stapsgewijs in elkaar zetten door technieken te verkennen, kleine testjes uit te voeren totdat je komt tot een werkend prototype wat je vervolgens verder afwerkt. Enige creativiteit is dus ook een vereiste.
Ik heb nu al een aantal kenmerken genoemd en als die totaal niet resoneren met jouw persoonlijkheid dan is de programmeerwereld misschien niet voor jou weggelegd. Dit wil niet zeggen dat je het niet zou moeten proberen uiteraard!
Het voornaamste bezwaar wat ik tegen tutorialsites heb is het volgende: deze leggen vaak alleen maar theorie uit, of misschien zelfs alleen maar wat voor letters en andere symbolen je zou moeten inkloppen. Alsof je een soort van toverformule uit je hoofd leert. Dit is dan meer een soort van veredelde typecursus dan een tutorial(site). Vergelijk het met een spreektaal: als je alle grammatica en een redelijke woordenschat hebt (de theorie) betekent dat niet dat je ineens vloeiend Frans kunt spreken (de praktijk).
Daarnaast: deze leggen alleen maar uit hoe iets goed gaat. Klop de code letterlijk over en je hebt een contactformulier. Oeps, je bent een punt-komma of ander symbool vergeten, of er zitten gewoon fouten in het voorbeeld - zelfs in 2e en 3e edities van drukwerk zitten nog fouten! En nu staar je compleet ontredderd tegen een blanco scherm aan en je zou bij God niet weten hoe je dit moet aanpakken omdat dit iets is waar je nog nooit eerder tegenaan bent gelopen en nog belangrijker, je hebt nooit geleerd hoe je dit soort problemen die tijdens het programmeren ontstaan zou moeten oplossen. Je hebt namelijk nooit geleerd om te debuggen. Ik denk dat je van dit laatste eigenlijk nog het meeste leert omdat dit je dwingt om door te dringen tot de kern van hoe dingen werken, en hoe ze niet werken :p.
Ook is het vaak moeilijk om tutorials op waarde te schatten. Het komt geregeld voor dat iemand zijn/haar ware geloof aan het prediken is waarbij ze nogal van het pad zijn afgeraakt en verstrikt zijn geraakt in hun eigen materie. Raadpleeg altijd meerdere bronnen over hetzelfde onderwerp zodat je op een gegeven moment dingen kunt gaan (af)wegen en je je eigen mening kunt vormen over een onderwerp of methodiek.
Maar wat @Tim zegt is misschien nog wel het beste, zoals hierboven ook al aangehaald, kies een onderwerp, verzamel je gereedschap, en ga bouwen. Een gedegen basiskennis van HTML, CSS, JavaScript, (en vervolgens) PHP, MySQL en het HTTP-protocol helpen hierbij natuurlijk enorm. Je zou deze volgorde bij je reis kunnen aanhouden. Misschien wil je wel direct in PHP en databases springen, maar als je de voorgaande dingen niet begrijpt wordt dit gewoon heel erg gecompliceerd. Dingen hebben nu eenmaal een zekere volgorde. Begin bij het begin. Als jij een boek in het midden openslaat dan kun je ook niet verwachten dat je het hele verhaal begrijpt/overziet of kunt volgen.
Of laat iemand een audit doen :).
De beste code is transparante code waarbij je kunt zien dat deze veilig is. Dit in tegenstelling tot "closed source" code die soms werkt volgens het principe van security through obscurity.
Neemt trouwens niet weg dat er een heleboel open source baggercode bestaat.
De vraag is niet zozeer hoeveel je test, maar of je op een juiste manier test :].
Als je je bedient van het credo filter input, escape output bij het schrijven van je code en je dit ook continu in je achterhoofd houdt dan kom je waarschijnlijk al een heel eind.
ps ik ben op zoek naar een goede en snelle manier om PHP om te bouwen van 5.6 maar 7.2 wie weet er een oplossing
Die is er niet echt. Je zult een analyse moeten maken van je code en kijken of de pijlers waarop je applicatie is gebouwd het geheel kunnen blijven dragen. Anders heeft het niet zoveel zin om deze om te bouwen en kun je beter opnieuw beginnen.
Daarnaast is hier geen universeel recept voor. Dit hangt echt af van de code waar het om gaat. Mogelijk was deze al zwaar verouderd in PHP 5.6 in welk geval je heel hard zou moeten nadenken of het echt de moeite waard is om die meuk om te schrijven.
Ook software heeft een houdbaarheidsdatum. Mogelijk zijn de principes die werden toegepast inmiddels achterhaald, werken ze simpelweg niet meer, of werken ze anders. Je kunt hier dus (waarschijnlijk) niet zomaar een PHP 7.2 saus overheen gooien.
En om eerlijk te zijn geeft de opmerking "ik heb geen errors, enkel een wit scherm" mij niet de indruk dat je veel ervaring hebt met debugging wat van pas kan komen als je toch besluit alles nagenoeg 1:1 om te gooien, want dan begint de pret waarschijnlijk pas :).
Ik verwijs mijn klanten via mijndomein.nl naar shop.kleding.nl/mijnwinkelnaam en boven in de balk blijven mijn klanten mijndomein.nl zien.
Als ik het bovenstaande goed begrijp, is dat inderdaad niet mogelijk tenzij je op een of andere manier verhult (of wilt verhullen) dat je gewoon op een andere website zit. Waarom je dat zou willen doen mag Joost weten.
Als het puur om de adresbalk gaat zou ik zeggen: gebruik een iframe. Maar je zit dan op jouw website in wezen gewoon op een andere website. En mogelijk klaagt je browser dan over allerlei cross origin blabla. Ik zou (hi)er gewoon niet aan beginnen denk ik.
Mogelijk zijn er andere oplossingen? Misschien heeft dat shop.kleding.nl een feed of webservice waarmee je content van een specifieke winkel in kunt laden?
Ik heb een aantal websites gezien waar dit wel bij gaat.
Ben nog steeds benieuwd naar hoe dat er dan uitziet.
Ik heb een aantal websites gezien waar dit wel bij gaat.
Voorbeelden? View Source?
Dit zal toch geen ranzige constructie met frames / een iframe zijn hopelijk?
Los daarvan: wil je dit eigenlijk wel (en, ter verduidelijking, zou je misschien een concreet voorbeeld willen geven, bijvoorbeeld: ik navigeer naar X, en wil Y in mijn navigatiebalk zien)?
In wezen zou elke unieke pagina (unieke URL) verschillende content moeten hebben. Je wilt voorkomen dat URL A en URL B (waarbij A en B van elkaar verschillen) dezelfde content bevatten, tenzij je op een of andere manier aangeeft dat het een een (exacte) kopie is van het ander, bijvoorbeeld met behulp van canonical pages.
Het lijkt me echter niet de bedoeling dat je doet alsof alle pagina's het adres http(s)://jouwwebsite.com/ hebben. Waarom zou je dat willen? Of ik begrijp niet wat je probeert te bereiken.
Als je niet de eigenaar bent van het (oorspronkelijke) domein en/of als dit domein geen voorzieningen heeft om je naar jouw domein te redirecten dan gaat de vlieger waarschijnlijk niet op.
Is dit niet meer een CSS aangelegenheid?
Als je wilt dat er iets gebeurt met de li op het moment dat je over de a hovered, zou dat dan niet een stijlregel zijn in de vorm van:
#cssmenu li a:hover { /* hier de CSS */ }
Proof of concept:
<?php
/*
https://www.ictscripters.com/Thread/24570-Hulp-bij-LI
*/
?>
<!DOCTYPE html>
<html>
<head>
<title>CSS test</title>
<style type="text/css">
* { color: #000000; font-family: sans-serif; font-size: 10pt; }
#menu { height: 25px; line-height: 25px; }
#menu ul { list-style-type: none; margin: 0; padding: 0; }
#menu ul li { display: inline-block; float: left; background-color: #ffcccc; }
#menu ul li a { display: block; text-decoration: none; text-align: center; padding: 0 15px; min-width: 75px; }
#menu ul li a:hover { background-color: #ffaaaa; }
</style>
</head>
<body>
<div id="menu">
<ul>
<li><a href="#">een</a></li>
<li><a href="#">twee</a></li>
<li><a href="#">een hele lange titel asdf asdf</a></li>
</ul>
</div>
</body>
</html>Ook zou je kunnen gaan nadenken om een soort van siteboom te maken van alle pagina's, je pagina's SEO-vriendelijke(re) namen geven. Vervolgens heb je dan waarschijnlijk ook een lijst van (zichtbare) pagina's en de actieve pagina zodat je de bovenstaande lijst kunt genereren met een simpele foreach-lus.
Een check voor het toevoegen van een class voor de actieve pagina doe je dan terloops.
EDIT: en ja, het zou dus logischer zijn om de actieve li te stylen.
Ik heb wel een aanpassing gedaan in het opslaan van het wachtwoord (hash) met de database, met de aanpassing wordt het wachtwoord opgeslagen en geeft de code voor het inloggen nu een goed resultaat.
Wellicht interessant voor de kijkers thuis wat deze aanpassing nu precies was. Controleer je nu ook of je precies één resultaat hebt voordat je je query-resultaten ophaalt bij het inloggen? Het lijkt mij nogal belangrijk dat dit alles 100% correct geschiedt (vooral als het de veiligheid en beveiliging van je website betreft), hier enkel hash/verify saus overheen gooien lijkt mij onvoldoende. Misschien is het ook interessant om wat code te plaatsen hoe alles er nu ongeveer uitziet?
En bottom line was dus (inderdaad) dat het geen probleem was met password_hash() / password_verify() maar een issue ergens onderweg met je database. Het is belangrijk dat dit soort "waarheidsvinding" op een goede en grondige manier gebeurt, want hier leer je gewoon het meeste van.
Haal is de ucfirst en strtolower weg van u loggie. Misschien vindt hij de juiste gebruikersnaam niet
Sja hij controleert sowieso niet of er precies één resultaat is. Hij haalt meteen een resultaat op :/.
Ik heb debugging uitgevoerd op alle connecties en data binnen het script. De mogelijkheid die ik nu heb toegepast werkt naar behoren. Waarom PASSWORD_BCRYPT niet werkt(te) ben ik nog niet uit.
Maar heb je dat nu al in afzondering getest, zonder tussenkomst van een database?
Het doel van debugging is mede om dingen uit te sluiten. Met een test die geen database gebruikt, dus gewoon een test met password_hash() i.c.m. PASSWORD_BCRYPT en password_verify() kun je uitsluiten of het nu echt hier aan ligt. En dit lijkt mij onwaarschijnlijk, omdat PASSWORD_DEFAULT standaard ook van bcrypt gebruik maakt. Dit kun je ook aan de hash zien, hier zit namelijk het algoritme en de cost in verwerkt. En dit kun je ook testen.
<?php
// levert bijvoorbeeld $2y$10$zrgHKhyvih.WoEt5mB85X.zG1/TOOyN1xJURjQXhfTGis4JvbncbC
echo password_hash('test', PASSWORD_DEFAULT);
// levert bijvoorbeeld $2y$10$8EbRJ99.CHc0vkdinYD8uOuOiQ2ZETvzCIW6IT1NTvSrCvosOzXaO
echo password_hash('test', PASSWORD_BCRYPT);
?>(NB in het bovenstaande fragment zijn het algoritme en de cost identiek, ondanks het feit dat je verschillende algoritme-constantes opgeeft)
Voer deze test eens uit op jouw webserver en kijk of de algoritmes ($2y$) of de cost ($10$) van elkaar verschillen.
En zelfs dat zou niet uit moeten maken, want de enige plaats waar je password_hash() gebruikt is bij het opslaan of wijzigen van het wachtwoord. Moet je wel deze zelfde hash als uitgangspunt nemen om het gehashde wachtwoord opnieuw te berekenen met password_verify() uiteraard. Dus als de bovenstaande test verschillende resultaten oplevert en je gebruikt dan een andere hash als waarmee de wachtwoord-hash is opgesteld... tja, dan ben je toch echt appels met peren aan het vergelijken.
Dus, ik vermoed nog steeds dat er iets bij het opslaan of uitlezen van je database-data misgaat.
Gewoon maar van algoritme wisselen omdat je niet weet wat er misgaat... weet niet of dat slim is :/.
Okay, dat werkt misschien, maar dat verklaart niet waarom het voorheen niet werkte.
Er begint mij al iets te dagen.
Hoe was het wachtwoord opgeslagen in de database?
Hoe luidt de kolomdefinitie voor deze wachtwoord-hash? (heeft deze genoeg ruimte?)Genereer je de hash (gegenereerd met behulp van het wachtwoord uit het loginformulier) op dezelfde manier als bij de opgeslagen wachtwoord-hash het geval was? Dat wil zeggen, met hetzelfde algoritme en ook dezelfde opties?
Escape je de DATA-delen in de SQL-query met de daarvoor bestemde escaping-functies?
Komen overal (database, database-connectie, formulier-data, HTML-bestand en -headers?) de gebruikte character encoderingen overeen?
Het lijkt mij zeer belangrijk dat je niet alleen zorgt dat iets werkt, maar ook dat je snapt wat er gebeurt en daarmee ook kunt verklaren waarom het werkt. Simpelweg omdat iets werkt, maakt het nog niet juist.
EDIT:
De bovenstaande code lijkt mij onjuist. Het lijkt erop dat je een onversleuteld wachtwoord ophaalt uit de database en het wachtwoord uit je formulier hasht? Is dit niet de omgekeerde wereld? Het hele idee van password_hash() is juist dat je wachtwoorden versleuteld opslaat en deze daardoor nooit naar het origineel te herleiden zijn. In een loginformulier zou dus ook nooit password_hash() moeten voorkomen, maar enkel password_verify() waarbij je het wachtwoord (uit het formulier) verifieert aan de hand van de hash (uit de database).
Daarnaast controleer je nog steeds niet of $inlog resultaten oplevert...
Zorg eens voor wat debugging zodat je precies achterhaalt wat er misgaat? Dit lijkt mij nogal belangrijk.
Dat klopt ook want je krijgt een gehashde variant retour waar een salt op is toegepast. Je berekent dus een eindresultaat op grond van een aantal cryptografische bewerkingen. Vervolgens test password_verify() of er een gelijkwaardig (maar dus mogelijk verschillend) resultaat berekend kan worden met behulp van het oorspronkelijke wachtwoord en een hash hiervan waar deze functie ook weer informatie uit kan halen zodat deze weet hoe er met het oorspronkelijke wachtwoord gerekend dient te worden.
Zet het maar eens in een loop:
<?php
for ($i=0; $i < 10; $i++) {
$hash = password_hash('test', PASSWORD_BCRYPT, ['cost' => 12]);
echo $hash.'<br>';
if (password_verify('test', $hash)) {
echo 'cake<br>';
} else {
echo 'no cake<br>';
}
}
?>[end]
Dit levert bijvoorbeeld:
$2y$12$Ge6qV1J4r9HjcTe4oIgzsO5ZIIyWTFMNQb676T.u638FKVBsDA.Xa
cake
$2y$12$XnzXjpNecdXnrvnRdIibGOK5cKPBPnDLz24GaGcnaRSgpT8rzTzla
cake
$2y$12$2G302P20vFq.SFuv5GrLw.6KeXVePjZE8Wg7HTalYdDv1stJXsKhK
cake
$2y$12$VLP2U1Tz1Cfxa37UkpNewe.QfGB4z.6QU9gilP4C/4dXKm7PhHf32
cake
$2y$12$5dNoalz/vcPZ4ZG8hLv6geu85yahCrPWu3AOz4TpjFEJZG4Cozj4y
cake
$2y$12$lgSfDga67v605rAqK5wghuhiRmfiY.GU.gTSI5Uf.i..1y9JkJSqi
cake
$2y$12$Z1owJcJNHdXUtE6S7S..zua9nXLhvmdig9Bs7To0IU1JEnmXj7wOm
cake
$2y$12$SFtBrblTprcYiTVtfifbAusvi1KcDVzyDuvcJsjDRMa8jTODWIX3.
cake
$2y$12$eg1prXKjujZiIpKoEdjbKe6UU7c6EfuNFRlTblhKqMGcdYH5Civ6O
cake
$2y$12$xg8RzhNVqkvYuls.M6tKTuZTmRkTxlMIvtBEN63hg233Vo4FRQzN.
cake
[end]
Laten we het eens over een andere boeg gooien. Waaruit blijkt dat je login-functionaliteit niet werkt, je zegt dat je een melding krijgt dat de wachtwoorden niet overeenkomen? Het enige wat je hoeft te doen is te kijken wat password_verify() teruggeeft. Als dit true is, dan was het (oorspronkelijk) ingevoerde wachtwoord juist.
De hashes verschillen als het goed is dus altijd, maar password_verify() toetst of deze gelijkwaardig zijn.
Allereerst, heb je vastgesteld dat je PHP-versie nieuw genoeg is? Minimale versie is 5.5.0.
Vervolgens, heb je al het een en ander gedebugged? Is het loginscript verder foutvrij?
En dan maak je je het jezelf wel erg moeilijk met het kopiëren van allerlei variabelen.
Ook lijkt het mij niet nodig dat je $_POST['ww'] escaped (en trimt?) omdat je deze variabele toch niet in een SQL-passage stopt.
Daarnaast controleer je niet of je query wel resultaten heeft (of liever gezegd, precies één resultaat oplevert).
Het ophalen van alle kolommen is wellicht ook overkill als je enkel het wachtwoord en/of enkele andere kolommen nodig hebt.
Maak anders eerst eens een heel simpel test scriptje:
<?php
$hash = password_hash('test', PASSWORD_BCRYPT, ['cost' => 12]);
if (password_verify('test', $hash)) {
echo 'cake';
} else {
echo 'no cake';
}
?>[end]Hier zou:
Citaatcake[end]
Uit moeten rollen.