Citaat van mitchellve

euhm? ik denk dat ictscripters.com niet gebaseerd is op joomla ?

"Well duh".

Als ik op "login" klik, zie ik nu enkel het loginformulier, de rest van de pagina is verdwenen.

We stappen van Joomla af?

Citaat van Laura

Via XSS kun je het wachtwoord stelen.
Bv: browsers die automatisch het wachtwoord voor je invullen.
Dit kan dan worden afgevangen of bv onversleuteld verzonden eerst naar de hacker?

Hoe helpt HTTPS als je website / webapplicatie zelf vatbaar is voor XSS? XSS is volgens mij meestal "client side", de "hack" vindt meestal in je browser plaats en de te stelen data wordt vervolgens via een ander pad weggesluisd. Dit loopt helemaal buiten HTTPS om. Indien XSS mogelijk is is dit een lek in de site zelf.

HTTPS beveiligt enkel het ontvangen en versturen van data van en naar je webserver via encryptie. Daarbuiten gelden nog steeds de aloude regels.

Het is ook niet alsof je met het gebruik van HTTPS de rest van de beveiligingsvoorzieningen overboord kan gooien. Bij beveiliging lijkt het mij onverstandig om al je geld op één paard in te zetten. Het is beter om het risico te spreiden door gebruikmaking van lagen.

Volgens mij is XSS voor een heel groot deel uit te bannen door de toepassing van output escaping. Een noodzakelijke voorwaarde voor het correct werken hiervan is dat je character encoderingen van je documenten en je data op orde zijn.

Dit zijn aparte voorzieningen die je zult moeten treffen, en staan helemaal los van HTTPS die nogmaals, enkel zorg draagt voor een veilige verzending en ontvangst van data, maar dat zorgt er dus niet voor dat de data zèlf veilig is (in het gebruik), daar moet je andere maatregelen voor treffen.

Hm, kan het zijn dat het besturingssysteem voorgeinstalleerd was bij aanschaf (door de winkel waar je de PC kocht)? Mogelijk is dat dan via een disk image gebeurt.

Het kan zijn dat je BIOS van je moederbord niet nieuw genoeg is om een/die SSD te herkennen.

Om maar een dwarsstraat te noemen, mogelijk helpt een BIOS update.

Ik meen mij te herinneren dat ik in een vaag en mistig verleden een soortgelijk probleem had.

---

Het kan ook zijn dat je harddisk nog een partitie heeft met een systeem backup, nadeel van het herstellen via zo'n "factory disk" is dat je ook alle bloatware die voorgeinstalleerd was weer meekrijgt, een clean install lijkt mij dan een beter plan.

Dit zou je overigens niet moeten belemmeren een clean install te doen eigenlijk.

---

Je zou dus eens kunnen zoeken op het specifieke model van je PC en/of je moederbord, of zelfs de SSD in combinatie met dit alles om te kijken of andere mensen soortgelijke problemen hebben.

Het komt eigenlijk zelfden voor dat jij als enige dit specifieke probleem hebt :). Anderen gingen je reeds voor.

Citaat van mitchellve

@FrankY
zou je eens een screenshot kunnen posten juist wanneer je de partitie moet selecteren waar je Windows 7 wilt installeren?

Groetjes,
Mitchelll

Lees die zin nog eens langzaam over :).

Ik denk dat een foto via een mobieltje ofzo het best haalbare is :).

Als ik "windows 7 format 0x80070057" Google is dit mijn eerste hit:

Error 0x80070057 when you format a hard disk drive to install Windows 7

Dit beschrijft het probleem en geeft een oplossing.

Citaat van Ferhat.Remory

Ik heb het volgende, bekijk het maar is. Is gewoon met PHP
https://github.com/Ezdesigneu/modrewrite

Neeeeeeeeeeeeeeeeeeeeeeeeeeeee :).

Waarom doet iedereen altijd het volgende:

RewriteRule ^(.*)/$ index.php?route=$1 [L]

Hiermee "reserveer" je op voorhand expliciet $_GET['route']. Dat is helemaal niet nodig. Je kunt gewoon alles doorsturen naar index.php, en dan je REQUEST_URI ontleden met behulp van parse_url(). Je hoeft hiervoor helemaal niets in $_GET te stoppen.

Ik vind het wel interessant hoe je via die .ini files (en de verwerking ervan) een soort van tweedeling kunt maken tussen wat "URL" is en wat "variable" is, maar de uiteindelijke URL moet uniek zijn, dus aan die "slug" zou je ook een soort van pagina-type kunnen hangen ("news") met bijbehorende properties (o.a. "news id").

Ik denk dat je hier wel iets werkends mee kan maken, maar sommige dingen zouden gerefactored moeten worden en andere dingen zou ik echt aanpassen (omdat ze niet helemaal kloppen - een van de eerste dingen die ik zou introduceren is een autoloader). Ik denk ook dat ik snel bepaalde zaken zou missen (zie hieronder).

Het probleem, of liever gezegd, de uitdaging wanneer je met dit soort functionaliteit aan de slag gaat is dat je een aantal zaken tegelijkertijd moet gaan regelen.

Denk bijvoorbeeld aan:
- authorisatie (gebruikersbeheer, rechten, rollen)
- een intern link systeem waarbij links blijven kloppen als URLs veranderen (dit wordt nog wel eens vergeten)
- sitestructuur (waarbinnen je authorisatie kunt toepassen)
- flexibiliteit van het uiterlijk van je uiteindelijke pagina (denk aan het kunnen wijzigen van het hoofd-template, het dynamisch toevoegen van CSS, JavaScript of inline JavaScript)
en last but not least
- het gemak waarmee je nieuwe functionaliteit kunt ontwikkelen

@Ferhat.Remory als je een keer notities wilt vergelijken, lijkt me interessant.

Wel als je meer van dit soort pagina's hebt, anders neemt het aantal rewriterules nogal snel toe.

Maar als quickfix ga gewoon voor de eerste variant (maak aparte, expliciete rules).

Mijn alternatieve oplossing voert wellicht wat ver voor wat je op dit moment probeert te bereiken.

Waarschijnlijk is je RewriteRule niet expliciet genoeg.

/? wil zeggen "optionele slash" denk ik?
(.*) wil zeggen "match (en vang) een subpatroon van 0f of meer karakters"

Dit is wellicht te vrijblijvend in die zin dat de match sneller wordt afgerond dan je eigenlijk wilt.

Beter is wellicht een set (hele) expliciete RewriteRules die van specifiek naar algemeen gaan.
Eerst maak je dus een ReWriteRule die controleert op "mailbox/(.*)/(.*)", dan een die controleert op "mailbox/(.*)" en tot slot een die controleert op simpelweg "mailbox".

Het bovenstaande werkt altijd, maar persoonlijk zou ik dit anders aanpakken. Ik zou alles van de vorm mailbox/(.*) doorsturen naar een script, alwaar je verder uitpluist wat die (.*) dan verder inhoudt en bepaalt wat je gaat doen. Je hebt dan aan één RewriteRule genoeg, maar je moet dan dus wat meer code schrijven. Beide methoden hebben voor- en nadelen.

Leading whitespaces in codeblokken worden (nog steeds) gestript / gecollapsed.

Pls fix :(.

Je hebt om het hele values blok single quotes gezet: VALUES(' ... '). De prepared statements laag van PDO voegt zelf quotes toe indien nodig (en negeert je typehints volgens mij volledig bij het opstellen van de uiteindelijke query).

Tevens: waar komt $current_round vandaan?

Citaat van FrankY

FangorN, bedankt voor uw reactie, ik zal eens even rond snuffelen op het internet met uw lijstje.

Geen probleem. Dat zijn trouwens wel allemaal losse componenten, je zult deze dus nog wel ergens samen moeten brengen.

Om je een voorbeeld te geven van hoe je pagina's (in zijn simpelste vorm) zou kunnen opbouwen de volgende klasse Page (page.php). Deze klasse dient als sjabloon om andere klasses (bijvoorbeeld een contactformulier) op te bouwen. Hierin zou je ook je standaard navigatie + layout in kunnen stoppen.

<?php
/*
This class is abstract because it has unimplemented (abstract) methods.
It is your responsibility to implement these methods when you create
classes that extend from this class.


Assumption: everything is UTF-8 (as it should be).
*/
abstract class Page
{
    protected $action;      // the action being executed
    protected $showOutput;  // whether we should show output (render the result as a page)


    protected $title;       // the page title
    protected $output;      // the page type output


    public function __construct() {
        /*
        Decide upon a querystring ($_GET) variable that serves as a carrier to indicate
        what action should be performed. In this case we simply use 'action'.
        Here we(pre)determine what valid action should be executed by checking if the
        accompanying "action method" exists. We then store this valid action in $this->action.
        */
        if (isset($_GET['action']) && method_exists($this, 'action'.ucfirst($_GET['action']))) {
            // this is a valid action
            $this->action = $_GET['action'];
        } else {
            // this is not a valid action, revert to default action
            $this->action = 'default';
        }


        // by default, we show output
        $this->showOutput = true;


        $this->title = '';
    }


    /*
    Optional method, it is not required to implement this.
    */
    protected function init() {}


    /*
    This method prints a standard HTML document header. Note that this is not an "action method"
    and can therefore not be called from an external source (a URL).
    */
    protected function __header() {
        header('Content-Type: text/html; charset=UTF-8');
?><!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title><?php echo $this->escape($this->title) ?></title>
</head>


<body><?php
    }


    /*
    This method prints the page type output (see below)
    */
    protected function __main() {
        echo $this->output;
    }


    /*
    This method prints a standard HTML document footer.
    */
    protected function __footer() {
?></body>
</html><?php
    }


    /*
    This method executes your page type action method.
    */
    public function execute() {
        // perform last minute initialisation
        $this->init();


        // the action method to be executed
        $action = 'action'.ucfirst($this->action);


        // depending on whether we show any output, we do different things
        if ($this->showOutput) {
            /*
            If output is generated we need to build a complete and valid HTML document.
            Because the execution of the action still might alter the final document,
            we execute the action first.
            We need to save the output to print the final document in the correct order.
            For this we use output buffering.
            */
            ob_start();
                $this->$action();
            $this->output = ob_get_clean();


            // Print entire page in the right order: header - content - footer
            $this->__header();
                $this->__main();
            $this->__footer();
        } else {
            // if no output is / should be generated, we simply execute the action
            $this->$action();
        }
    }


    // required method - needs to be implemented in extended classes
    abstract protected function actionDefault();


    // for setting the document title
    public function setTitle($title) {
        $this->title = $title;
    }


    // helper function
    protected function escape($in) {
        return htmlspecialchars($in, ENT_QUOTES, 'UTF-8');
    }


    // helper function
    protected function redirect($link) {
        header('HTTP/1.1 303 See Other');
        header('Location: '.$link);
        exit; // so we never forget :)
    }
}
?>

Vervolgens maak je een class die hiervan is afgeleid, bijvoorbeeld Form (form.php). Omdat je voortborduurt op Page (page.php) doe je geen dingen dubbel:

<?php
// obviously, an autoloader should be preferred to this
require_once './page.php';


class Page_Form extends Page
{
    protected function init() {
        // define the methods that do not generate output
        if (in_array($this->action, array(
            'process',
            'noOutput',
        ))) {
            $this->showOutput = false;
        }
    }


    protected function actionDefault() {
        // set document title
        $this->setTitle('Hello World');


        $formAction = '?action=process';


        // print some HTML
        ?><h2>Hello World</h2>
        <p>Do you want to see output?</p>
        <form action="<?php echo $this->escape($formAction) ?>" method="post" accept-charset="UTF-8">
            <input type="radio" name="showoutput" id="show_output_1" value="1" checked="checked" />
            <label for="show_output_1">yes!</label>
            <input type="radio" name="showoutput" id="show_output_0" value="0" />
            <label for="show_output_0">no!</label>
            <button type="submit">go!</button>
        </form><?php
    }


    protected function actionProcess() {
        // process form
        if ($_SERVER['REQUEST_METHOD'] == 'POST') {
            if (empty($_POST['showoutput'])) {
                $this->redirect('?action=noOutput');
            } else {
                $this->redirect('?action=output');
            }
        }
        // form was not posted - return to default action
        $this->redirect('?action=default');
    }


    protected function actionOutput() {
        $this->setTitle('Showing dem outputs');


        ?><h2>Showing output</h2>
        <p>Hi there.</p><?php
    }


    protected function actionNoOutput() {
        // because no output was generated, no content type nor charset was set
        header('Content-Type: text/html; charset=UTF-8');
        ?>No output here.<?php
    }
}
?>

En tot slot maak je een index.php of een andere PHP bestand waarin je deze klasses laadt en uitvoert:

<?php
require_once './form.php';


$form = new Page_Form();
$form->execute();
?>

Dit is slechts een simpele variant, maar deze kun je uitbouwen tot een CMS. Het bovenstaande vormde de basis van het CMS dat ik als oefening aan het bouwen ben, mijn persoonlijke website maakt hier gebruik van. Deze heeft ook al een vrij uitgebreide backend waarmee je (redelijk) eenvoudig pagina's kunt maken:

Mocht jij -of iemand- hier vragen over hebben wil ik hier best het een en ander over uitleggen.

Citaat van ruttydm

Dit stuk code moet worden opgeroepen door een api, dus sql injection speelt even geen rol.

Los daarvan, zoals je op de bovenstaande manier je query opbouwt, op die wijze zou je sowieso PDO nooit moeten gebruiken. Je schiet daarbij helemaal voorbij aan de reden waarom je uberhaupt voor PDO zou kiezen en de queries "veilig" zijn (door het gebruik van prepared statements).

Het lijkt mij beter dat je die werkwijze (het rechtstreeks in een query duwen van waarden bij gebruikmaking van PDO) in het geheel afleert.

Je zou ook kunnen overwegen om zelf iets simpels in elkaar te draaien, dat hoeft in eerste instantie helemaal niet zo complex of uitgebreid te zijn.

Slideshow: gebruik een ui-plugin van jQuery (en gebruik jQuery voor JavaScript-zaken in het algemeen).

Veilig beheerspaneel: kan in eerste instantie eenvoudig; wat zou dit allemaal moeten kunnen doen?

Contact pagina: lijkt mij niet zo ingewikkeld; gebruik PHPMailer voor mail-specifieke zaken.

Pagina's creëren: wat zouden deze pagina's moeten doen? Bedoel je artikelen? Maak een klein artikel-systeempje.

Statistieken-pagina: gebruik Google Analytics. Deze hebben al wat langer ervaring met statistieken verzamelen :).

Als je een beetje handig functionaliteit "inkoopt" (dit hoeft verder helemaal niets te kosten) dan kun je snel van start. Gebruik handige tools/libraries die hun nut en waarde bewezen hebben.

En voor de opbouw van pagina's (maintemplates, paginatypes) heb je zo wat code in elkaar gefietst. Als je daar een voorbeeld van wilt dan hoor ik het wel.

Citaat van Laura

Volgens Barnes kan een aanvaller in een dergelijk geval via JavaScript het wachtwoord stelen voordat de gebruiker op inloggen klikt.

Ik ben benieuwd hoe dat dan in zijn werk gaat. Waarschijnlijk heb je dan al hele andere problemen (XSS)? Is hier een bron van? Als dit namelijk zo makkelijk is als wordt gesuggereerd, hoe verklaar je dan dat niet alle sites met dergelijke functionaliteit inmiddels over zijn naar HTTPS? Dit neigt toch een beetje naar paniekzaaierij.

Citaat van Laura

Waarom gebruik jij nog geen ssl certificaat?

Ik zou dit nog wel een leuke toevoeging vinden voor mijn homepage. Maar deze heeft enkel een uniek subdomein en zit ook op shared hosting. Waarschijnlijk gaat dat niet vliegen dan.

Al gegoogled op "WordPress responsive templates"?

Het klinkt alsof het template wat je gebruikt niet responsive is, dat will zeggen, zich niet automatisch aanpast aan (standaard) schermgroottes (ongeacht het apparaat waarmee je de site bekijkt).

Er is gigantisch veel informatie te vinden over de responsive ontwerpprincipes. Er zullen ongetwijfeld ook artikelen / tutorials zijn die specifiek zijn toegespitst op WordPress.

Ik zou dus (nogmaals) geen constructies aanleggen die met man en macht proberen recht te buigen wat krom is, je kunt veel beter hier in eerste instantie van wegsturen in plaats van dit na afloop trachten te repareren.

Hierdoor wordt je code nodeloos wolliger, wat weer zijn effect heeft op de leesbaarheid en onderhoudbaarheid.

Ook moet je niet bang zijn om dingen gewoon kapot te laten gaan in plaats van dat je buitensporig veel moeite moet doen om te doen alsof alles goed gaat, daarmee schuif je toch dingen onder het tapijt... Besteed deze tijd aan het uitdenken van simpelere en elegantere oplossingen in plaats van deze lijn van slecht ontwerp door te trekken.

Het probleem is waarschijnlijk dat includes (bestanden die eigenlijk alleen bedoeld zijn om ergens anders ingevoegd te worden) rechstreeks aangeroepen kunnen worden en vervolgens ook worden uitgevoerd.

Deze opzet is eigenlijk verre van ideaal. Als je vaker sites maakt dan zou je hier al eerder tegenaan gelopen moeten zijn en hier ook al oplossingen voor verzonnen moeten hebben?

De eenvoudigste manier om te voorkomen dat dit soort lappen code uitgevoerd worden is een conditioneel die-statement bovenin alle includes zetten. Je controleert dan op het bestaan van een constante; indien deze niet bestaat beeindig je het script.

De constante zelf definieer je in het bestand vanwaar je deze includes invoegt. Dit is volgens mij al een hele lange tijd een simpele methode voor het afschermen van (het rechtstreeks aanroepen van) bestanden...

Ik zou ook niet proberen om gebruikers nog de goede kant op te sturen met allerlei statische / hardcoded links omdat ze al van het (navigatie)pad af zijn, daarnaast zijn statische links inflexibel (mocht je de URL waaronder een pagina bereikbaar is veranderen zou je ook elke keer deze code moeten aanpassen) en daarmee nogal foutgevoelig.

Er zijn natuurlijk ook andere oplossingen denkbaar waarbij je er bijvoorbeeld voor zorgt dat je includes directory buiten je webdir valt... Het verbaast (en verontrust) mij een beetje dat je hier ogenschijnlijk pas op het einde van de bouw van een site tegenaan loopt. Enerzijds omdat dit al afgevangen had moeten zijn (maar de realisatie was er niet?) en anderzijds omdat dit eigenlijk het eerste is wat je op orde moet hebben (de organisatie van je bestanden), nog eigenlijk voordat je begint. Een vaste werkwijze bij het bouwen van sites helpt ook...

Het werkt denk ik makkelijker als je een online voorbeeld hebt, waarbij je aangeeft wat je precies probeert te bereiken.

Te meer omdat dit een nogal visueel georienteerde vraag is...