Beiträge von cottton

    Ja, die nutzen nix dynamisches.
    In Codelgnitter steht:

    PHP
    // ...
    public function initialize()
    	{
    		$this->_ci_autoloader();
    	}
    // ...


    und in der func _ci_autoloader():


    Also wird da irgendwo in der config ein array mit filenames geladen.
    Genauso wie bei Yii:

    PHP
    private static $_coreClasses=array(
    		'CApplication' => '/base/CApplication.php',
    		'CApplicationComponent' => '/base/CApplicationComponent.php',
    		'CBehavior' => '/base/CBehavior.php',
    		'CComponent' => '/base/CComponent.php',
    		'CErrorEvent' => '/base/CErrorEvent.php',
    		'CErrorHandler' => '/base/CErrorHandler.php',
    // ...


    =(
    ABER
    ich hab gerade bei Yii im autoloader was gesehen: die nutzen die Namespaces als Pfad, wenn die Klasse nicht in der config existiert.
    Heißt, dass die Klasse selbst den Pfad im Namen hat.
    Und das ärgert mich jetzt, weil ich weiß, dass das ne Lösung ist, aber ich mich um Namespaces drücken wollte :D
    damn!

    sorry, wollte das eigtl noch nachschieben, habs dann aber vergessen =)


    beim erstellen eines Objekts von Test (also bei $x = new Test()) wird __construct ausgeführt.
    Daher $obj = new Test($SYS)
    Mit der Variante - der Referenz - kannst Du innen den Wert ändern und außen.
    Löschen auch. Einfach mal ausprobieren.

    Mir viel gestern noch was auf: diesen Ablauf/Keyexchange/ect kann man nicht mit PHP/JS lösen.
    Denn per ManInTheMiddle kann ja theoretisch das JS verändert werden,
    und damit ist der PrivateKey nicht mehr sicher, weil der ja in ner var steckt -.-

    In meinem Framework (irgendwie gefällt mir der Name nicht mehr) hab ich folgenden Aufbau:

    Alles läuft über Module. Und ganz am Anfang werden über einen Loader sämtliche Module geladen.
    Dabei geht der Loader wie folgt vor:
    - geh in den Order modules/default/
    - für jeden Ordner : include Datei (was die class darstellt) welche genauso heißt wie der Ordner
    - wenn class *name* eine Methode onload() besitzt : ausführen
    - include alle zusätzlichen Dateien aus diesem Ordner

    Heißt also, dass alle Module in einem eigenen Order liegen, so wie alle zugehörigen Dateien.
    Die Datei, die genauso wie der Ordner heißt, ist die "Hauptklasse".
    Zusätzliche Dateien sind auch meist Klassen wie zB UserController ect.

    Bsp:
    User - ist die "Hauptklasse"
    UserControllerMain - steuert den Grundablauf des Users (login ect)
    UserControllerForgotPassword - steuert speziell den Ablauf der Forgot-Password-Function

    Das Problem:

    PHP
    class UserControllerForgotPassword  extends UserControllerMain  {...}


    ^damit will PHP via autoload die Klasse UserControllerMain laden was ja richtig ist,
    aber meine func in der autoload ist nicht dafür ausgelegt:

    PHP
    spl_autoload_register(
                function($class){
                    (include_once PATH_INC_MODULES_DEFAULT.$class.'/'.$class.'.php')
                    or
                    (include_once PATH_INC_MODULES_OTHERS.$class.'/'.$class.'.php');
                }
            );
    Zitat

    Warning: include_once(includes/modules/default/UserControllerMain/UserControllerMain.php): failed to open stream: No such file or directory in C:\xampp\htdocs...


    Die eigtliche Datei liegt in:

    Zitat

    includes/modules/default/User/UserControllerMain.php


    class User wird also als erstes geladen.
    class UserControllerForgotPassword VOR UserControllerMain, wegen der Sortierung (UserControllerF* vor UserControllerM*)
    Jetzt könnte ich die UserControllerMain in UserController_Main umbenennen, aber das ist dämlich :D

    Und ich dachte eigtl, dass ich wiedermal beim schreiben dieses Posts schon selbst drauf komme,
    aber ... nö -.-
    brauch also mal nen Schubser =)

    PHP
    $SYS['hallo']['geht'] = "funktioniert";
    class test{
        function systeminfos(){
            global $SYS;
            print_r($SYS);
        }
    }
    $ausführen = new test;
    $ausführen->systeminfos();


    durch global wird es verfuegbar. hab aber vergessen, ob es auch aenderungen nach draussen uebernimmt :)
    musste mal testen

    edit:
    oder so (wie ich es nutze)


    durch das erste & in den parametern wird SYS als referenz von aussen "aufgenommen".
    bei der zuweisung in $this->SYS =& wird wieder eine referenz zum eingehenden aufgebaut, wodurch es auf den ggleichen inhalt wie aussen zeig.
    heisst:
    wenn du drin was aenderst, ist es draussen auch geaendert.
    und ungekehrt.

    Da das Thema momentan "aktuell geworden ist" ....

    Ich weiß wohl immer noch nicht genug, aber war erstaunt über was ich gerade gelesen hab.
    Auf das Thema "PFS (Perfect Forward Secrecy)" hat mich gerade The Scout gebracht.
    Was steckt dahinter: http://de.wikipedia.org/wiki/Diffie-He…BCsselaustausch
    (und http://www.heise.de/security/artik…cy-1923800.html)

    Und ich dachte WTF! Ich bin davon ausgegangen, dass bei SSL(also den ganzen Zertifikats-Kram) diese Methode genutzt wird!
    Nu hatte ich mich mal hingesetzt und das hier (oben) besprochene Script geschrieben, aber dann liegen lassen, weil ich dachte "das machste eh nich besser".
    Jetzt lese ich, dass die "Alice und Bob"-Geschichte so gut wie nicht genutzt wird. Stattdessen werden "geheime"-Schlüssel übers Netz geschickt!

    Das bringt mich wieder dazu die Sache aufzurollen.
    Die momentan wichtigste Aufgabe: mit dieser Methode Schlüssel generieren (oder besser gesagt mit Werten rechnen), die groß genug sind:

    Zitat von wiki


    In der tatsächlichen Anwendung werden Zahlen mit mehreren hundert Stellen benutzt.

    Stimmt. Aber beim heartbleed-"bug" ist ja noch das Problem, dass die Zertifikate Müll sind, WENN ich das richtig verstanden hab (da u.U. glaub ich die Schlüssel ausgelesen werden konnten).
    Dewegen müssen ja alle Serverbetreiber erstmal die Lücke schließen, dann neue Zertifikate ran(?dunno),
    und dann erst müssen wohl die Benutzer neue PWs einrichten.
    Ganz schöne Dampfe da am Kacken :D

    pepper ändern: nein. Der muss immer gleich bleiben.
    Und wie gesagt: die SESSION-Daten sind auf dem Server. Nur wer die SESSION-id in die Finger bekommt, kann sich als User-x ausgeben.
    Um dann noch an die Daten ranzukommen, müsste der Angreifer wohl (ungetestet) noch weiter gehen: man müsste das Script dazu bringen die Daten anzuzeigen.

    Einfach mal testen: erstelle eine SESSION, und gehe in den Ordner C:\xampp\tmp (wenn xampp genutzt wird).
    Sortiere nach "Änderungsdatum" und öffne die zuletzt geänderte Datei im Editor (Datei sieht in etwa so aus: sess_fdnphmbs70qjn0hj7cpbh7isf2)
    Der String der da drin steht kann decodiert werden mit unserialize().
    Aufbau:
    | == trenner ( key|value )
    s:8 == string von 8 Zeichen
    i:1 == int 1 zeichen
    N == null
    b == bool
    ...

    Hat was Basiii.
    - [disabled] normaler Nutzer, der vom Admin deaktiviert wurde (also der Datensatz noch vorhanden) -> Meldung beim Login ->disabled wegen ...
    - [~inactive] beim Login auffordern die Daten zu aktualisieren/bestätigen
    - bei einem gelöschten Benutzer ist sowieso nix möglich

    probier mal das hier:

    Die db macht das nicht von alleine. Die macht immer nur soviel, wie ihr gesagt wird.
    Und schätze nen cron willste nicht.

    Aber geh anders ran: kein bool, sondern ein Zeitstempel.
    mal ganz grob:
    select id, name, ..., lastactive from tbl where ....

    if(time()-lastactive < x){
    ist nicht mehr aktive
    }

    EDIT: Du kannst das auch noch besser lösen

    SQL
    SELECT lastactive
    FRON tbl...
    WHERE 
     id = :id
     AND NOW()-lastactive > :x

    Ja - wie gesagt in meinem ersten post: http://www.w3schools.com/html/tryit.asp…5_video_js_prop

    Du brauchst somit:
    - auf der linken Seite die Links (zB mit onlick="...")
    - ein container (also <video>) in der mitte mit einer id="..."
    - per javascript (onclick="...") löst Du eine function aus, die den video container in der Mitte "nimmt" (getElementById) und die src (Zieldatei) ändert
    - dann evtl mit autoplay oder der function play abspielern

    =)

    The Scout
    http://www.heise.de/newsticker/mel…us-2172516.html

    Zitat


    Insgesamt kommt die Studie zu dem Schluss, ... . Auf den übermäßigen Gebrauch von Frameworks ist hingegen zu verzichten, da sie Entwicklern beim Beheben von Fehlern eventuell im Weg stehen könnten, wenn sie nicht genügend mit ihnen vertraut sind. Statt dessen sollen Programmierer häufig Codereview betreiben und allgemeine Regeln zur Verbesserung der Softwarequalität befolgen.


    Der gesamte Beitrag und die Studie ist nicht wirklich "bereichernd". Aber dem Satz zu den Frameworks stimme ich zu =)