Jetzt das HTML-Seminar als
Video-Tutorial
mit über 210 Videos,
Gesamtspielzeit über 24 Stunden
Video-Kurs HTML5+CSS+Webdesign
jetzt bekomme ich ein weiteren fehlercode, $fetchModer = ??? der kann wohl was nciht finden oder wiedergeben ?
einfach mal Fehlermeldung lesen, was ist daran nicht zu verstehen? Tipp: schau dir deinen dsn mal an bzw. lass dir das Ergebnis ausgeben und vergleich es damit wie das Ding aussehen soll.
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.
Kann man CSS-grid heutzutage bedenkenlos verwenden, zumindest die von mit gepostete Minimalstruktur?
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:
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).
Interessenhalber: Was ist denn der URL-Kontext?
Wenn eine URL z.B. im href-Attribut eines a-Elements ausgegeben wird. Für URLs gelten spezielle Regeln, nicht alle Zeichen sind da erlaubt, siehe Fortsetzung zu der von mir in #4 verlinkten Seite.
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.
alle vars mit htmlspecialchars() ausgeben.
Da fehlt noch die Behandlung des URL-Kontexts (mit http_build_query() oder urlencode()).
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) 
Mit deinem jetzigen Code wird das mit responsivem Design immer schwerer.
Nein, unmöglich. Wie gesagt, der Checkbox-Hack ist nicht barrierefrei und damit ist es völlig sinnlos den Ansatz weiter zu verfolgen.
Vorweg: wenn du ein Posting einmal abgeschickt hast, änder es doch bitte nicht mehr. Es ist sehr verwirrend wenn man den Code zum testen kopieren will und auf einmal ist der weg.
Ich habe einfach den PSR4-Autoloader von php-fig.org kopiert: https://www.php-fig.org/psr/psr-4/examples/.
Ok, jetzt verstehe ich was der Code macht - das kann aber natürlich nicht funktionieren wenn der Namespace fehlt (wie in #1, dort wird in der index.php kein Namespace verwendet!).
Dies ist die Ordnerstruktur zur Klasse Router die ich mit dem Autoloader laden möchte: app/core/Router.php
Nun steht in der Router.php dieser Namespace: namespace App\Core;
Wenn ich im Autoloader mir die $class direkt zu Beginn ausgeben lasse, wird einfach nur den Klassenname ausgegeben. In diesem Fall also Router.
Dann machst du irgendwas falsch, bei mir funktioniert der Code von der angegebenen Quelle. Auch passt die Ordnerstruktur nicht zum Namespace bzw. dem $prefix im Autoloader. Bleib doch bitte mal bei einer Klasse und einem Namespace und ändere den nicht ständig - das ist sehr verwirrend und macht es quasi unmöglich den Fehler zu finden. Poste bitte auch mal den Code mit dem sich das Problem nachvollziehen lässt (einschließlich der Pfade wo was liegt).
Wenn ich den Namespace nun in der index.php bei der Instanziierung der Klasse nochmal explizit angebe ändert sich auch nichts daran.
Den Namespace musst du in der index.php natürlich auf jeden Fall angeben, woher soll PHP sonst wissen welchen Namespace du meinst? Ob du da am Anfang der Datei namespace …; verwendest, beim Aufruf der Klasse mit new … den Namespace voranstellst oder mit use …; arbeitest ist dabei egal.
ZitatWenn ich vom Autoloader folgenden Codeblock entferne kann ich mir zumindest den Pfad zur Datei ausgeben lassen, welche eingebunden wird, wenn diese existiert:
Das kommt daher dass im Autoloader der Namespace nicht ankommt - der Autoloader ist nur für den angegebenen Namespace zuständig, ohne diesen bricht er natürlich ab.
Dann habe ich mir gedacht, dass es an dem direkten Aufruf über C:\ liegt und habe direkt http://localhost/project anstelle von __DIR__ bei $base_dir genommen
Das ist natürlich Käse. Du brauchst auf jeden Fall lokale, absolute Pfade - mit einer URL kommst du nicht weit: probier mal das PHP-Script per URL aufzurufen, was siehst du? Richtig, nichts - genau das gleiche sieht PHP wenn es die Datei per require einbindet. Ganz schlechte Idee, am besten sofort wieder vergessen.
Aber: warum liegen die Klassen überhaupt in einem Verzeichnis das per HTTP erreichbar ist? Das einzige was in dem per http erreichbaren Verzeichnis liegt ist die index.php (sowie Bilder/JS/CSS), alle weiteren Scripte liegen in einem Verzeichnis weiter oben.