Door zeker te weten of jouw DB gegevens kloppen en de verbinding wordt gemaakt kun je iets doen als:

if($con == false)
{
echo 'DB verbinding mislukt';
exit();
}

Zover ik weet is dit niet een hele grote bug, las het ook op NU.nl waar het iets uitgebreider werd beschreven. Hackers zouden niet echt misbruik kunnen maken omdat de gegevens van jouw account en games gewoon op jouw eigen harde schijf staan in jouw Xbox. Ik denk niet dat iemand dit dus zou kunnen misbruiken..

Toch nog knap gedaan van die 5 jarige jongen, ik had ook gelezen dat doen die 1 jaar was hij al de beveiliging op zijn vader mobiel kon omzeilen^^ Zijn vader zelf zit in de IT branche dus die zal wel trots zijn

Citaat van casb

Jammer, niet responsive. Waarom niet?

Probleem voor zijn concept is dat hij dus alleen de outgame responsive kan maken, dat is dus wel inderdaad een idee.
Ingame responsive maken zou volgens mij niet kunnen doordat je met een iframe een andere site ophaalt en die dus responsive moet zijn.

Leuk project, alhoewel ik nog wel wat zou doen aan qua SEO etc.
De site is simpel en erg duidelijk, wat natuurlijk erg goed is. Alleen scoren EU domeinen niet goed in Google, wellicht een .com domein te gaan halen?

Citaat van WebMobiel

Wat is de oplosssing, toevallig heb ik presies het zelfde probleem :)?

Ik raad je aan om een WYSIWYG editor te gebruiken zoals CKEditor of TinyMCE. Deze zijn gewoon veel handiger aangezien je zelf niet zoveel werk hoeft te doen.
Uit ervaring kan ik spreken dat het ook nog eens makkelijk is om bijvoorbeeld CKEditor te gebruiken.

Volgens mij ligt het aan de kabel, waarschijnlijk geeft hij niet het juiste door waardoor je zo'n grijs/zwart beeld krijgt.
Ik gebruikte zelf een AV kabel welke het prima deed en nu een HDMI kabel welke ook prima werkt.

Nogmaals als het verkeerd resultaat geeft, moet je het gaan debuggen. Zet ergens var_dump() neer(met de variabelen erin) en kijk wat eruit komt. Zo weet je of de query wel het goede resultaat ophaalt of niet...

" SELECT klantnummer,wachtwoord FROM customers WHERE klantnummer = '".$_POST['klant']." "

Dat stukje moet natuurlijk nu wel na de isset en na het stukje dat je $_POST omzet naar variabelen. Ook zou ik de input van de user beveiligen.'

Zou je jouw hele code kunnen posten op pastebin.com en de link hier delen?
Verder is jouw code, naar mijn mening, iets te omslachtig qua 'efficiëntie' en zou ik een inlog systeem anders aanpakken.

Qua debuggen zou ik nu even eens var_dump uitproberen, dus:

var_dump($gegevens['klantnummer'], $gegevens['wachtwoord'], $klant, $wachtwoord);

Zo kun je al kijken of de gegevens ook echt kloppen, verder snap ik niet echt waarom je het klantnummer beveiligd?

Citaat van victor

Reza Helaas? In sommige gevallen is het juist goed, aangezien je veilig een omgeving kan verkennen. Je brengt zo geen mensen in gevaar.

Zelf vraag ik me af hoe dit mogelijk is. Een tijdje terug heeft al het vliegverkeer rond Ijsland stil gelegen door een aswolken. Kunnen die drones daar wel tegen?

http://en.wikipedia.org/wiki/Drone_attacks_in_Pakistan

Zeker mooie beelden, heel erg mooi om het van dichtbij te zien i.p.v. as wolken vanuit de verte.
Die drones zijn inderdaad in dit soort gevallen een mooie uitvinding.( Helaas worden ze ook gebruikt voor militaire aanvallen )

Citaat van WebMobiel

Hallo Reza,

Bedankt voor je uitleg, al moet ik zeggen ik snap hier dan weer minder van...

Gr,
Frenzo

In het eerste voorbeeld die je liet zien(PDO) gebruik je een PDO prepared statement. Wat ik liet zien in mijn voorbeeld is ook een voorbeeld van een MySQLI prepared statement.

In MySQLI werkt het helaas 'irritanter' doordat je verschillende methodes erbij moet toevoegen wil je bijvoorbeeld resultaat uit je query halen.
Standaard(bijvoorbeeld een insert in je DB) is het prepare(), bind_param() en execute(). Dit is nog het zelfde als bij PDO.

Bij MySQLI komt echter nog het stukje(bijvoorbeeld bij een select voor je DB) dat je jouw resultaat moet 'opslaan'(store_result()). Daarna moet je, wat je eerder via select had gekozen in de query, samenbinden in een variabel(bind_result).
Om het uiteindelijk nog als resultaat te krijgen moet je nog fetch() gebruiken, en zoals gewoonlijk(volgens mij ook bij PDO) het afsluiten met close()

Wat je nu hebt gepakt zijn twee voorbeelden waarvan de eerste al een voorsprong heeft op de tweede.

PDO is een paar opzichten vooral beter dan MySQLI, als voorbeeld dat PDO meer databases ondersteund.
Alleen zie ik, dat je al bent begonnen met MySQLI. Ik zou dan niet halverwege een project de overstap naar PDO maken, wat je kan doen is net zoals in voorbeeld 1 beginnen met prepared statement.

Met bijvoorbeeld jouw gegeven voorbeeld wordt het ongeveer zo:

//$query = $db->query("SELECT * FROM users WHERE gebruiker = '".$_POST['gebruiker']."'");
$stmt = $mysqli->prepare("SELECT id,naam,gebruikersnaam FROM users WHERE gebruiker = ?");
$stmt->bind_param('s', $_POST['gebruiker']);
$stmt->exeucte();
$stmt->store_result();
$stmt->bind_result($userId, $userName, $userUName);
$stmt->fetch();
$stmt->close();

Citaat van godkiller

HEEY,

hij geeft nu een andere foutmelding weer.

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

hoe los ik dat op

Als je de desbetreffende code geeft kunnen we je helpen, verder is je huidige code erg onoverzichtelijk en ook nog eens 'ouderwets'.

Zou je de foutmelding kunnen posten, graag ook met regelnummer.

Waarschijnlijk kan er geen resultaat opgehaald worden en daarom krijg je met fetch_assoc() een foutmelding.

http://stackoverflow.com/questions/6017…njection-in-php : Hier raden ze preprared statements aan, dit is dan ook het veiligste om te doen en in mijn ogen het makkelijkste aangezien je niks meer met real_escape_string hoeft te doen of met trim etc.

Wil je het toch zonder prepared statements doen raad ik je aan op te zoeken welke functie voor wat precies bestemd is. htmlspecialchars() is bijvoorbeeld voor een HTML input en trim() kan bijvoorbeeld enters verwijderen in een string.
Stel dat je alleen een getal wilt laten invoeren kun je een controle doen met is_numeric() of met ctype_digit(), zo kan de gebruiker alleen nog maar cijfers invoeren.

Je laatste vraag kan ik wel beantwoorden

Het lijkt mij logisch als MySQL inderdaad sneller is dan MySQLI/PDO. Vooral omdat MySQL ligt werkt en niet erg uitgebreid is, terwijl bij MySQLI en PDO vooral meer komt kijken als je naar de OO kant kijkt.

PDO is in paar opzichten beter dan MySQLI, echter zou ik toch als je zo min mogelijk code wilt gebruiken kiezen voor MySQLI.
Als je bijvoorbeeld geen preprared statements gaat gebruiken en je het toch veilig wilt doen moet je de quote() functie gebruiken. Het probleem bij de quote functie is dat het alles in single quotes zet, in de db krijg je dus 'amsterdam'.

Dit kan je vermijden door substr() te gebruiken alleen geeft dit ook meer code...
Helaas kan ik je vraag met een snellere query niet beantwoorden, heb even lopen Googlen maar kon niks in die richting met PDO vinden.

Edit: Ik zou persoonlijk ook voor een vaste SQL taal kiezen, zelf was ik begonnen met PDO en daarna ben ik overgegaan naar MySQLI. Ik zeg dit omdat bijvoorbeeld prepared statements in MySQLI en PDO sterk overeenkomen maar bijvoorbeeld de bind param functie schrijf je in beide talen anders. Wat ik vooral vaak verkeerd deed toen ik over switchte naar MySQLI

Het was volgens mij al wat langer bekend dat Apple onder vuur lag in Europa i.v.m. hun garantiebeleid. Ik las zelf op NU.nl dat Apple inmiddels een melding heeft geplaatst op hun site dat Europese klanten wel recht hebben op twee jaar.

Persoonlijk raad ik af om alles uit een DB te selecteren(met een asterik bedoel ik), maar om je toch te helpen.

$data = $mysqli->query("SELECT * FROM users");
$arrayData = $data->fetch_array();