De MySQL functie MAX() kan je hierbij wel eens uit de brand helpen.

Je zult moeten groeperen op de topic_id, overigens lijkt mij orderen op ID ook geen goed idee.

In dit geval hoeft isset niet gebruikt te worden. De query-string wordt namelijk (op een hele verkeerde manier) van de string afgehaald met een string replace. Als de query string leeg is, vervang je een lege string met een lege string, niets aan de hand dus.

In de documentatie staat ook iets anders interessants:

Citaat

'QUERY_STRING'
The query string, if any, via which the page was accessed.

Ik denk dat je daarmee wel uit de voeten kunt..

Volgens de documentatie bestaat de parameter 'REQUEST_QUERY' helemaal niet:

http://www.php.net/manual/en/reserved.variables.server.php

In JavaScript zijn puntkomma's niet verplicht dus dat maakt niet uit.

Zou je de HTML ook eens kunnen posten? Heb je JavaScript nog niet helemaal doorgelezen, maar dat zou nog wel eens kunnen helpen.

@Alexjeee: Met alle respect, maar als je geen echt idee hebt over het probleem is je hulp niet erg nuttig, ook al is het vriendelijk.

Oké, we kunnen eens een poging wagen.

We hebben in ieder geval een gebruiker, en deze zal een gebruikersnaam, wachtwoord en bijvoorbeeld e-mail adres hebben. Daarnaast hebben we om in te loggen een loginformulier. Als dit formulier wordt verzonden, levert dit een request op. Het request dient beantwoord te worden met een response. Laten we voor het afhandelen en het beantwoorden van requests een controller in het leven roepen (denk aan MVC). Dan kunnen we nu maken, een user en een repository waar de users uit worden gehaald en in worden opgeslagen:

class User {
     private $username;
     private $password;
     private $email;


     public function getUsername() {
          return $this->username;
     }
     
     public function getPassword() {
         return $this->password;
     }


     public function getEmail() {
         return $this->email;
     }
}


class UserRepository {
    
    public function getUserByUsername($username) {
        // Get user from some datasource
    }
}

Vervolgens een representatie van de request, response en de view:

class Request {
        
    public function getParameter($name) {
        return ($_SERVER['REQUEST_METHOD'] == 'POST') ? $_POST[$name] : $_GET[$name];
    }
    
    public function isPostRequest() {
        return $_SERVER['REQUEST_METHOD'] == 'POST';
    }
}


class Response {
    
    public function writeResponse(View $view) {
        $view->render();
    }
}


class View {
    private $viewName;
    private $viewData;
    
    function __construct($viewName, $viewData) {
        $this->viewName = $viewName;
        $this->viewData = $viewData;
    }


    public function render() {
        extract($this->viewData);
        include('views'. $this->viewName .'.php');
    }
}

En dan nog de echte code, de UserController:

class UserController {
    
    private UserRepository $userRepository;
    
    public function login($request, $response) {
        $succeed = false;
        if($request->isPostRequest()) {
            $user = $this->userRepository->getUserByUsername($request->getParameter('username'));
            
            if($user->getPassword() == $request->getParameter('password')) {
                $succeed = true;
            }
            
            $response->writeResponse(new View('user/login', array('succeed' => $succeed)));
        }
    }
}

Allemaal 'dingen', zoals je ziet. Kun je hier iets mee?

Wat er in de tutorial wordt gezegd over de zelfstandige naamwoorden is waar. Alle objecten zijn object (Sherlock), en objecten duid je aan met zelfstandige naamwoorden.

Als jij een loginsysteem maakt heb je te maken met een user. Dit object zul je vrijwel zeker nodig hebben. De user zal alleen hoogstwaarschijnlijk een domeinobject zijn, en daarom niet zelf de methode login() kennen. Kun je geen andere casus bedenken? Deze is een beetje te technisch.

@Fils: Mooie wijziging, en bedankt voor de referentie!

Ik bedoel met het berekenen van de SALT waar deze vandaan komt. Bijvoorbeeld statisch (daar leek het op, altijd dezelfde), random (opslaan samen met het wachtwoord) of berekent uit gegevens van de gebruiker (gebruikersnaam, id, e-mailadres).

@Fils:

Citaat

Ik schrijf niet dat je wel MD5 moet gaan gebruiken. Ik licht alleen toe wat het probleem is met MD5.

Ik geef niet aan dat je het wel moet gebruiken. Het is zeker beter een sterker hashing algoritme zoals SHA512 te gebruiken. Je hoort mij niet zeggen dat iedereen MD5 moet gebruiken en dat zal ik ook niet doen.

Wat betreft je pepper en secret key. Als je gebruik maakt van een salt doe je dat met een reden. Namelijk om het gebruik van rainbow-tables en soortgelijke aanvallen tegen te gaan. Als je vanuit daar redeneert kun je simpelweg zeggen dat een pepper en secret key geen toegevoegde waarde hebben. Je kan ze er best bij zetten maar ze hebben geen nut. Als je vervolgens in je blog ervan gebruik maakt, vind ik dat een beetje slordig staan. Daarom probeer ik je uit te leggen waar een salt goed voor is.

Ps. Hoe bereken je de salt? Of is deze statisch?

@Fils: Ik schrijf niet dat je wel MD5 moet gaan gebruiken. Ik licht alleen toe wat het probleem is met MD5. Daarbij is het overigens ook zo dat er wat problemen in MD5 zijn gevonden die het nog sneller mogelijk maken hashes te berekenen.

Een zogenaamde pepper heeft geen toegevoegde waarde. Het gaat erom dat je iets aan het wachtwoord plakt (liefs user-specifiek). Of dat nu vooraan, achteraan of in het midden van het wachtwoord staat maakt niet uit. Vooraan en achteraan zetten is dan ook onzin.

Over je SHA1 en MD5 blog:

Als ik de code bekijk lijkt de "secret key" gewoonweg een salt te zijn. Daarnaast is de "pepper" niet van toegevoegde waarde. Doordat je een salt toevoegd hebben rainbow-tables minder inpakt. Wachtwoorden als test komen namelijk wel voor in rainbow-tables maar testmijnfantastischesalt213 komt hoogstwaarschijnlijk niet voor. Daarbij is een hash nooit te decrypten. Om het wachtwoord te achterhalen heb je nu overigens niet je salt nodig. Je hebt alleen heel veel rekencapaciteit nodig.. Als de salt bekend is wordt het wel iets makkelijker wachtwoorden te achterhalen.

Overigens zijn er twee redenen waardoor MD5 wordt afgeraden:
- Er zijn gigantisch veel rainbow-tables beschikbaar voor MD5. Dit kun je echter oplossen met een goede salt.
- MD5 is voor de huidige computers een extreem snel algoritme. De werkelijke waarde (of een collision) van een 128-bit MD5 salt is daardoor relatief snel gevonden.

Hoe komt iedereen er bij dat het aan de hosting zou liggen? Het is relatief gezien een hele eenvoudige website.

Het menu moet ook veel sneller kunnen laden hoor. Maar als je hem even weghaalt kun je ontdekken of daar het probleem in zit.

Het goede nieuws is, de query's worden uitgevoerd op een database-object ($db in je index). Het aantal uitgevoerde query's zou je eens kunnen tellen, en de query's die worden uitgevoerd zou je eens kunnen loggen.

Citaat

Daar ben ik het niet mee eens.

Ik kan bijvoorbeeld op mijn server, "zware PHP-code's" draaien zonder moeite. Zet ik deze codes op een server met trage hardware, dan krijg ik het zelfde resultaat.

Dat klopt helemaal. Maar als je de website bekijkt, mag dat nooit een zware pagina zijn om op te bouwen. Dus het probleem ligt dat in de software en niet aan de hardware. Natuurlijk kun je er dan wel een hoop extra hardware onder hangen, maar dat lost het probleem niet op en is zonder van je geld.

Wat gebeurd er als je het categorieënmenu eens weghaalt? En dan, vanzelfsprekend, ook het laden van de data voor het menu.

Het ligt aan de laadtijd van de index-pagina, dat is overduidelijk. De server specs zullen daarvan niet de oorzaak zijn, daarvoor is deze laadtijd te lang.

Drie verschillende oorzaken kan ik bedenken:
- De PHP-code is erg traag, waarschijnlijk door veel database query's.
- De database is erg traag, door slechte configuratie of een slecht schema.
- De server staat onder zware load.

En dan staan ze op volgorde van waarschijnlijkheid...

Kun je de PHP code van de index pagina, om eens te beginnen, eens posten?

De betreffende tool van Ferhat is inderdaad een mooie manier om dit eens te bekijken. Zijn conclusies kloppen alleen wat minder. Als je de resultaten bekijkt, wordt er in mijn geval 15 seconde gewacht op de index-pagina. Bij het opbouwen van die pagina is er dus iets bijzonder traag. Waarschijnlijk ligt dat aan je PHP-code (?) of aan je database.

Wat Fils zegt is zeker een goed idee.

Ik heb je script in ieder geval even opgeknapt, en daarbij ook die syntax error in de if-lus opgelost:

<?php


include("connect.php");
session_start();


$_SESSION["projecten_id"] = (int) $_GET["projecten_id"];


$projecten = mysql_query("SELECT p.*, a.project_afbeeldingen, b.project_bestand FROM `projecten` AS p, `project_afbeeldingen` AS a, `project_bestanden` AS b WHERE `projecten_id` = ". $_SESSION["projecten_id"] ." AND a.item_id = p.item_id AND p.bestand_id = b.bestand_id");
if (!$projecten) {
    echo sprintf("Query failed; %s", mysql_error());
}


$project = mysql_fetch_array($projecten);


?>
<?php echo $project['project_titel']; ?><br>
<img src="<?php echo $project['project_afbeelding'] ?>" height="250" width="325"><br>
<?php echo $project['project_langeomschrijving'] ?><br>


<?php if ($project['bestand_id'] > 0): ?>
    <a href ="<?php echo $project['project_bestand'] ?>">Download bijlage<br>
<?php endif ?>

De query heb ik verder niet naar gekeken en een beetje mijn twijfels bij. Ik zou deze in ieder geval omschrijven naar een duidelijke query met joins.

Switch-statements zijn voor situaties als deze bedoeld, maar een if-else lus doet ook prima zijn werk.

Waarom zoveel reacties op zoiets eenvoudigs? En waarom de 'er is iets fout gegaan' melding? Kan een rand() tegenwoordig een waarde retourneren buiten zijn marges? Ik dacht het niet...

De Eclipse IDE biedt standaard ondersteuning voor Andriod development. Echter, de Eclipse IDE wordt door de meeste Java ontwikkelaars niet ervaren als een goede IDE. Door je Andriod application te bouwen met Maven (een buildtool) kun je ook prima ontwikkelen in een andere IDE zoals Netbeans of IntelliJ, heb ik mij laten vertellen.

Een blogpost die daarop ingaat:

http://www.vogella.com/articles/Andro…en/article.html

Andriod ontwikkeling is in Java, en ontwikkeling voor de iPhone is Objective-C.