Posts by Darsstar

Dein komt ons wel leuk vertellen wat het is...
Nu is er wel genoeg gediscussieerd over het "OS" gedeelte...
(verdient zo ongeveer een eigen topic als je het mij vraagt)

Script is gewijzigd...

Ik heb een aantal mysql_fetch_object() functies in het script geplaatst...

*gaat weer ontopic*
Ok, geen Kohana...
Wel OOP?

Citaat van Dein

Dat denk ik niet, aangezien veel hier nog niet mee overweg kunnen.
Mijn doel is, dat de gebruiker zelf niet meer in de code moet duiken voor simpele dingen (installatie, titel, gegevens,...)

Maar jullie moeten nu wel niet verwachten dat dit binnen de zoveel maanden klaar is, ik durf er geen deadline op te plakken.

Daar heb je views voor? :p

Maar hoe dan ook succes

Nice, denk er wel aan dat je een trap onder je kont krijgt als het blijkt dat de source code zuigt!

Ben je verder van plan die kennis die je na een paar uitleggen van mij hebt opgedaan te gebruiken?
*doelt op Kohana*

Citaat van MrMees

Darsstar: Wat maakt het verschil tussen op ID of op naam selecteren?

Verder is het ook een beetje vreemd als je een uniek veld hebt voor een bepaalde user dat niet hoort te veranderen (gericht aan iedereen die het zou kunnen veranderen in de database) en een ander veld gebruikt om users te identificeren...
Zeker wanneer je bedenkt waar id voor staat!

Even logisch nadenken kan soms al veel opleveren :p

De errors er uit halen?
isset($_SESSION['id'] &&
je vergeet isset() af te sluiten... (niet alleen daar)

if(isset($_COOKIE['id']) && ctype_digit($_COOKIE['id']) && isset($_COOKIE['gebruikersnaam']))
// kan korter als:
if(isset($_COOKIE['id'], $_COOKIE['gebruikersnaam']) && ctype_digit($_COOKIE['id']))
// zoals niels dus al zei...

de else die false returned weg halen...
en de "return FALSE;" net op het einde van de functie zetten... (niet in een if)

De datum en gebruikersnaam niet uit de database selecteren...

Zodra je ingelogd bent (je login script) session_regenerate_id() aanroepen...

Zorgen dat je $mysqli ook echt bestaat...

de $ voor mysql_real_escape_string($_COOKIE['gebruikersnaam']) weghalen...

$_SERVER_REMOTE_ADDR veranderen in $_SERVER['REMOTE_ADDR']

Op id selecteren, niet op gebruikersnaam...
Ook vind ik het geen goed idee om de gebruikersnaam in de cookie en sessie op te slaan, het id is genoeg...
Wil je nog een extra waarde neem dan de hash van iets... (ip + browser + id + datum geregistreerd bijvoorbeeld)

$_session['id'] met hoofd letters schijven...
consequent blijven is trouwens ook wel handig... ($_SESSION['id'] en $_SESSION['ID'] zijn verschillende variabelen)

<script language="javascript">  updateTime('tijdsduur', <?php echo $microseconds; ?> + time.getTime(), ''); </script>

tada?
$microseconds is het aantal microseconden dat je wilt dat je countdown aftelt... (seconden * 1000)

zou moeten werken...

Veel succes iedereen!

Verder zou het ook fijn zijn als de layout breeder is...
Er is een CSS framework genaamd 960 oid, dat is 960 pixels breed.
De reden daar achter is omdat je 960 door zoveel hele getallen kunt delen (met een heel getal als antwoord).
Ik vond dat ik dat even moest melden, of je hun mening deelt en 960 ook een mooie breedte vind of niet, veel succes!

<?php


// hier is je nieuwe array structuur...
$cities = array(
    'palermo' => array(
        'morphine' => rand(10000, 15000),
    ),
);


$func = create_func('&$value,$key', '$value = "`$key` = $value";')


foreach($cities AS $city => $fields)
{
    $fields = array_walk($fields, $func);
    mysql_query("UPDATE `Smuggling` SET ".implode(', ', $fields)." WHERE `city` = '".mysql_real_escape_string($city)."'");
}

Zoiets zou ik gebruiken...
Dat wilt niet zeggen dat er geen fouten in de bovenstaande code kunnen zitten, ik heb deze namelijk niet gestest.
Het gaat om het idee...

Eens denken...
1 query vs. net zoveel queries als dat je leden hebt...
(ok, je voert maar 1 query uit, maar je haalt het meerdere keren op)

Wat denk je dat beter is?
1 query natuurlijk! :p

Voor het aantal leden weet ik het niet heel zeker, maar ik denk dat COUNT() daar de beste optie voor is...

haal "WHERE `login` " eens weg...

diestro
Ik heb hier al genoeg aan hoor...

Db-maffia
het uitroep teken zat inderdaad op de verkeerde plaats...

SC-Webmedia
Ik denk dat je net de verkeerde md5() weg hebt gehaalt...

@TS

if(md5($_POST['pass']) != md5($data->pass)) //zal minder vaak kloppen dan:


if($_POST['pass'] != $data->pass)

Ik hoop maar dat je alleen dacht dat het wachtwoord als plaintext (geen md5 hash) in de database staat...

Edit:
Die code hier boven is een voorbeeld...
Die gaat dus geen oplossing zijn...
Lees het " SC-Webmedia" gedeelte voor de oplossing...

dan zou een "echo mysql_error();" na de query handig zijn...

Het formulier binnen de for loop plaatsen lijkt me handig...

Brrrrrrrrr!

$_REQUEST...

*begint te rillen*

$_REQUEST is niet fijn wanneer je niet van CSRF houd, zoals ik...

Ook raad ik je aan je code te indenten...

Maar wat zegt een mysql_error() ons?

$bool = mysql_query("UPDATE songs SET title = $songtitle, maker = $songmaker, url = $songurl WHERE id = $songid") or trigger_error('MySQL error: '.mysql_error());

Het zet backslashes voor karakters die een betekenis hebben in een query...
Hoe het in je database komt te staan zal niet anders zijn dan waarmee je begon (dat is als je niet opeens besluit meerdere functies te gebruiken die het zelfde doen, dan krijg je leuke backslashes in de naam)

http://www.php.net/in_array

if(in_array('ja', array($own['beheerder'], $own['...'])))

bijvoorbeeld...

NOOIT USER INPUT VERTROUWEN!!!

Daar komt het op neer...
Ga er altijd van uit dat je leden alleen het slechtste met je voor hebben...
Dus als je user input in een query wilt stoppen moet je deze escapen om te zorgen dat de query onschadelijk is...
mysql_real_escape_string() (houd rekening met je character set), mysql_escape_string() en addslashes() zijn hier voorbeelden van...

Wist u al van deze tips?
Een groot aantal.
Zo ja, welke (nr.)?
3, 4, 7, 8, 9, 11, 12, 16, 18, 19 (Ook InnoDB vanwege relaties!), 20 (ORM en Sprig voor Kohana), 21 (deels)
Ooit tegengekomen maar vergeten:
5, 14
Zo nee, ga je na het lezen hier iets aan doen?
Ja, ik ga wat met dat ip adressen opslaan als integers spelen.
Eigen tips of tricks:
Normaliseren!
Voorbeeldje:

--
-- Tabel structuur voor tabel `users`
--


CREATE TABLE `users` (
  `id` int(7) unsigned NOT NULL auto_increment,
  `username` varchar(255) character set latin1 NOT NULL,
  `password` char(128) character set latin1 NOT NULL,
  PRIMARY KEY  (`id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;


-- --------------------------------------------------------


--
-- Tabel structuur voor tabel `user_weapons`
--


CREATE TABLE `user_weapons` (
  `user_id` int(7) unsigned NOT NULL,
  `weapon_id` int(7) unsigned NOT NULL,
  `amount` int(7) unsigned NOT NULL,
  PRIMARY KEY  (`user_id`,`weapon_id`),
  KEY `weapon_id` (`weapon_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


-- --------------------------------------------------------


--
-- Tabel structuur voor tabel `weapons`
--


CREATE TABLE `weapons` (
  `id` int(7) unsigned NOT NULL auto_increment,
  `attack` int(7) unsigned NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;


--
-- Beperkingen voor gedumpte tabellen
--


--
-- Beperkingen voor tabel `user_weapons`
--
ALTER TABLE `user_weapons`
  ADD CONSTRAINT `user_weapons_ibfk_2` FOREIGN KEY (`weapon_id`) REFERENCES `weapons` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  ADD CONSTRAINT `user_weapons_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

Door de tabel user_weapons hoef je niet alle namen van wapens meer in de users tabel te zetten.
Koop je een nieuw wapen?
Update het veld 'amount' als er al een rij bestaat. (een tweede invoegen voor de zelfde user gaat niet =])
Of maak een rij voor de user die het wapen koopt!