Beiträge von tk1234

    __construct( $dsn = 'mysql:host=127.0.0.1;dbnameshop,charset=UTF8', $username = 'DB_USERNAME', $password = 'DB_PASSWORD' )

    Die Fehlermeldung passt nicht zum Code und der dsn ist immer noch Käse. Einer der drei Fehler darin ist das falsche charset (richtig wäre utf8mb4), den Rest siehst du hoffentlich selbst - wenn nicht solltest du überlegen ob das Programmieren wirklich das richtige für dich ist, simple Syntaxfehler sollte man auch selbst finden, dafür sind Foren nicht da.

    Ich habe mein Projekt gerade ohne jegliche Änderungen auf mein Webserver hochgeladen und über den Browser aufgerufen. Nun kommt der gleiche Fehler wie zu Beginn: Die Klasse kann nicht gefunden werden, obwohl der Pfad zur PHP-Datei stimmt.

    Da der Webserver vmtl. unter Linux läuft könnte es an einem Klassiker liegen: Groß- und Kleinschreibung bei Dateinamen und Verzeichnissen nicht konsequent beachtet (Linux unterscheidet hier, Windows nicht) - mehr lässt sich so völlig ohne Kenntnis von Code und Datenstruktur nicht sagen.


    Zum Thema Dateien außerhalb vom document-root ablegen muss ich auch noch was nachtragen: dass große Shop-System alle ihre Dateien innerhalb des Root-Verzeichnisses hätten (-> #9) stimmt nicht: Shopware z.B. hat da mit der Version 6 umgestellt, wenn die Domain nicht auf das public-Verzeichnis zeigt sondern auf die Ebene darüber, bekommt man lediglich eine Fehlermeldung. Das muss natürlich nicht repräsentativ sein, oft wird es aber historische Gründe haben da eine Umstellung der Verzeichnisstruktur immer einen gewissen Aufwand mitbringt.

    Das funktioniert so weit auch alles ganz toll, allerdings möchte ich gerne die 5 Hauptpunkte in fetter Schrift hervorheben und dabei habe ich das Problem, dass das dazugehörige Aufzählungszeichen (also 1., 2., etc.) nicht fett dargestellt wird.

    Du sagst dem Browser ja nicht dass die Zahlen fett sein sollen, du musst ol oder li schon fett formatieren (für ul dann wieder zurücksetzen). Und lass die style-Attribute weg, die sollten die absolute Ausnahme sein.

    gibt es eine Möglichkeit eine bestimmte Session zu beenden?

    Nein. Du kannst in einem Script nur die eigene Session bearbeiten, fremde Sessions kannst du natürlich nicht beeinflussen. Dir bleibt nur mit Flags zu arbeiten anhand derer bei jedem Seitenabruf abgefragt wird ob die Session noch weiterlaufen darf oder nicht. Aber was hast du eigentlich wirklich vor? Warum pfuscht der Admin im Passwort eines Benutzers rum? Bei einem vergessenen Passwort ist es ok wenn ein temporäres(!) Passwort gesetzt wird - in deinem Fall kennt der Benutzer aber ja sein Passwort (sonst wär er nicht angemeldet).


    Habe das mit diesem Code versucht:

    unset($_SESSION[$benutzer_id])


    leider funktioniert dies nicht. Ich erhalte auch keine Fehlermeldungen.

    "Funktioniert nicht" ist keine Fehlerbeschreibung und eine Fehlermeldung bekommst du nur wenn $benutzer_id oder $_SESSION[$benutzer_id] nicht existieren - außerdem änderst du damit ohnehin nur deine eigene Session.

    Beachte auch den obersten Beitrag unter "User Contributed Notes".

    Nur als Hinweis: da die Anmerkungen im Handbuch abhängig von der Bewertung sortiert sind, kann sich die Reihenfolge verändern - sinnvoller ist es also direkt auf den Eintrag zu verweisen den man meint (einfach auf die E-Mailadresse klicken).

    Das wird ja dann übergeben und in den ssh2 Befehl eingefügt. Der dann rein theoretisch so aussehen müsste:

    (Habe $folder mal ersetzt)

    $output1 = ssh2_exec($connection, 'rm -r ' . escapeshellarg('/media/Mitarbeiter/../../../../media/Mitarbeiter/Admin/Test/'));


    Das macht ja irgendwie wenig sinn.

    Jein. Der Pfad wird vom System dann entsprechend übersetzt und es wird das richtige Verzeichnis gelöscht. Aber warum übergibst du überhaupt eine vollständigen Pfad wenn du eigentlich nur einen Teil brauchst? Und warum die ganzen »../« davor wenn »/media/Mitarbeiter/Admin/Test« das gleiche bewirken würde ohne dass die Gefahr bestünde dass man sich mit den Ebenen (und damit den »../«) verzählt?


    Aber unabhängig davon, ich habe es dir schon mal in einem anderen Thread geschrieben (warum hat in diesem niemand darauf hingewiesen?!): du hast immernoch eine gravierende Sicherheitslücke in deinem Code wenn du relative Pfadangaben zulässt und den kompletten Pfad angibst. Die Gefahr dass dir jemand das komplette System platt macht besteht durch das weglassen von sudo nicht mehr, du darfst aber trotzdem nur den Pfad unterhalb von »/media/Mitarbeiter« übergeben und darfst in dem übergebenen Wert auf keinen Fall »../« zulassen, damit nicht beliebige Verzeichnisse gelöscht werden können (halt alle die der verwendete Benutzer löschen darf).


    Evtl. wäre es auch sinnvoll bei der SSH-Verbindung (bei der mir ohnehin nicht ganz klar ist wofür die notwendig ist, liegen die Daten nicht auf dem Rechner auf dem der Apache läuft?) keine Verbindungen mit Passwort zuzulassen sondern nur welche über Public Keys.

    Wenn ich mal was einwerfen darf: mit Pixel-Angaben für die Breakpoints in den media-Querys seid ihr auf dem völlig falschen Dampfer. Die richtige Einheit hier ist em, löst euch von der Vorstellung dass x Pixel der Breite von Gerät y entsprechen!

    PLZ und Stadt ist kein Problem.

    Doch, zumindest wenn du halbwegs brauchbare Ergebnisse brauchst. Bei der ersten von dir angegebenen Seiten stimmt immerhin die Stadt (PLZ ist falsch), die zweite Seite vermutet mich an einem Ort rund 200 km von hier … Die Zuordnung einer IP zu Ort oder gar PLZ ist sehr ungenau und (je nach Provider) oft unbrauchbar.

    Die musst du dann in einer Datenbank abfragen und dann hast du die Straße. ( vielleicht auch Hausnummer)

    Die Datenbanken sind meistens nicht kostenlose.

    Google Maps hat, soweit ich weiß, eine entsprechende API, die bis zu einer gewissen Anzahl an Aufrufen sogar kostenlos ist - wie viele die Zugriffe auf den Standort überhaupt zulassen weiß ich aber nicht (ich habe die Anfragen dafür generell unterdrückt). Wobei ich jetzt auch garnicht weiß wie genau das bei Desktoprechnern (idR ja ohne GPS) überhaupt ist.

    Es stellt sich aber die Frage wofür Dekiblago das überhaupt braucht: der Benutzer kennt seine Adresse und irgendeine falsche Adresse bringt ihm auch nichts.

    Was für Verzeichnisse genau hast du den im Kopf? Die nicht erstellt werden sollten.

    Ernsthaft? Natürlich alles was außerhalb des vorgegebenen Verzeichnisses (bei dir wohl »/media/AzubiFiles«) liegt. Wäre vielleicht nicht ganz so toll wenn du auf einmal z.B. in /usr/bin o.ä. neue Verzeichnisse (bzw. sogar Dateien wenn ich mir anschaue was du sonst noch so machst) angelegt werden - da du mit sudo arbeitest wäre das (ohne entsprechende Vorkehrungen) überhaupt kein Problem.


    Bitte überleg dir ganz genau ob du das wirklich umsetzen willst, mir schein nicht so als wärst du dir im Klaren darüber was für Sicherheitsscheunentore du da aufreißt!

    Leider verstehe ich das nicht ganz so genau? Wie genau würde man das in meinem Code anwenden? Oder in einem anderen Code der ähnlich aufgebaut ist?

    Was genau hast du an dem Beispiel im Handbuch zu escapeshellarg() (die Funktion brauchst du) nicht verstanden? Da steht zwar nur ein kurzes Beispiel aber das Prinzip sollte klar werden: die Variable mit dem Pfad darf nicht direkt in den Shell-String eingebaut werden sondern muss vorher durch die Funktion gejagt werden.


    Und vergiss nicht mein PS aus #14 zu beachten!

    Inwiefern meinst du das?

    Einfach den Ordner ohne "sudo" erstellen?

    Nein (das sudo hat da zwar nichts zu suchen, hat mit dem eigentlichen Problem aber nichts zu tun). Die Behandlung von Kontextwechseln ist eigentlich das wichtigste bei der Programmierung, das gilt nicht nur wenn man das Script etwas auf der Kommandozeile ausführen lässt sondern z.B. auch wenn man mit Datenbanken arbeitet oder auch wenn man Inhalt in die HTML-Ausgabe schreibt. Auf die einzelnen Arten von Kontextwechseln wird in der Fortsetzung des verlinkten Artikels eingegangen, auch zum Thema Shell gibt es ein Unterkapitel.


    PS: dass du auf jeden Fall auch sicherstellen musst dass nicht beliebige Verzeichnisse erstellt werden können ist hoffentlich klar …

    Der Code dafür ist dann wie folgt:

    Mutig. Sehr mutig. Oder *richtig* dämlich. Such es dir aus. Mit dem Code kann ein Angreifer beliebigen Code auf deinem Rechner ausführen - und das mit root-Rechten! Da fehlt die Behandlung des Kontextwechsels, zudem sollte der Webserver keine sudo-Rechte haben (bzw. die Möglichkeit haben solche Befehle auszuführen).

    Danke für deine Antwort. Was bedeutet in dem Fall die "1, 2"?

    Nichts besonderes, wichtig ist nur dass die erste Zahl kleiner ist als die zweite da nach den beiden Zahlen (aufsteigend) sortiert wird.

    Und würde das dann auch so sein das Erst "Admin" ganz oben ist, dann "Sonstiges" und dann "Mitarbeiter"?

    Wenn es mehr Werte sind kannst du FIELD() verwenden:

    SQL
    ORDER BY FIELD(Rang, 'Admin', 'Sonstiges', 'Mitarbeiter')

    Bei mehreren Felder wäre es aber evtl. sinnvoll eine eigene Tabelle mit den Rängen zu haben und dort ein Feld für die Sortierung mitzuführen (in der ursprünglichen Tabelle steht dann nicht der Rang im Klartext sondern nur die ID aus der Rang-Tabelle).

    okay und warum empfiehlst du dies so zu tun?


    Ich sehe da aktuell noch keinen Grund dies so zu tun. Selbst große Shopsysteme haben all ihre Scripte innerhalb des Root-Verzeichnisses.

    Wenn Dateien nicht per http erreichbar sind, können sich auch nicht durch einen Konfigurationsfehler ausgeliefert werden. Dass der PHP-Interpreter mal nicht funktioniert (und damit PHP-Dateien im Klartext ausgeliefert werden) ist natürlich extrem unwahrscheinlich aber bei anderen Dateien kann es schon mal vorkommen dass man mal vergisst ein Verzeichnis zu sperren. Bei größeren Systemen schauen idR viele Leute drüber und Fehlkonfigurationen fallen da normal auf - bei selbst geschriebenen Scripten ist das nicht so. Zudem sind die großen Systeme meist über lange Zeit gewachsen und können nicht mal eben einfach komplett umgekrempelt werden außerdem funktioniert das auch nur wenn die Systeme im obersten Verzeichnis einer Domain installiert werden müssen, sobald eine Installation auch in tieferen Verzeichnissen möglich sein soll (z.B. example.com/shop/), ist das mit fertigen Scripten nicht mehr möglich. Bei Eigenenwicklungen ist es imho aber nicht verkehrt nur die Dateien direkt erreichbar zu machen die auch erreichbar sein müssen.

    Wie meinst du das?

    Wenn du http://localhost aufrufst, wird vmtl. der Inhalt des Verzeichnisses C:/xampp/htdocs aufgerufen. Damit Scripte und auch z.B. Cache-Dateien o.ä. nicht über den Browser erreichbar sind, gehören die in C:/xampp/scripte (oder so, wie genau ist eigentlich völlig egal, nur halt nicht unterhalb von htdocs).

    Wobei ich eher ganz außerhalb von C:/xampp arbeiten würde aber zum Glück muss überhaupt nicht mit Windows arbeiten und habe damit hier überhaupt kein c:/ (geschweige denn XAMPP) :)