Beiträge von ilou

    Und zwar wie baut man so eine Anwendung vom HTML her grundsätzlich auf

    Das ist so gesehen komplett dir überlassen. Ich habe in meinen electron-Apps bisher immer auf Vue.js oder Angular zurückgegriffen, die sich dann um das Laden einer Datei kümmern (Stichwort Routing). So habe ich am Anfang eine kleine Datei, in der meine Scripts geladen werden, die dann wiederum mittels Routing die entsprechenden Unterseiten einfügen.

    Allerdings braucht man nicht zwingend ein solches Framework, es reicht eigentlich das eigene Wissen über JavaScript und wie man mit JavaScript Inhalte austauscht, bzw. aus Dateien lädt. Hier hilft vielleicht das Stichwort Browser History API.


    So gesehen kannst du also entweder alles in eine Datei schreiben, macht aber aufgrund der Möglichkeit, Seiten mittels JavaScript reinzuladen, wenig Sinn.


    wie greife ich vom JavaScript auf NodeJS zu?

    Erstmal ist das eine spezielle Frage, die nicht viel mit dem Problem, neue HTML-Dateien zu laden, hat. Node.js ist zwar serverseitig, dient hier aber eher dazu, auf Systemnahe Komponenten zugreifen zu können. Um da mal ein paar Beispiele zu nennen: Zugriff aufs Dateisystem (fs), Zugriff auf das Betriebssystem (OS) oder auch Dinge wie die Möglichkeit C++-Addons zu nutzen.


    Je nachdem, wie du nun vor hast deine Anwendung aufzubauen, kannst du entweder in electron einen extra Webserver starten. Soweit ich weiß, hat electron nämlich keinen eigenen. Dazu sollte erstmal das Node.js-Modul http genügen. Falls du was mehr brauchst, solltest du dir mal das Modul express anschauen. Alternativ legst du die HTML-Dateien in einen Ordner und bindest sie mit JavScript generell ein. Das geht, wie eben beschrieben mit der Browser History API ganz gut.


    Nun muss man zwischen zwei Fällen unterscheiden:

    Du nutzt einen Webserver in electron: Dann gehst du eher auf die Schiene, dass du keine direkte Kommunikation zwischen electron und JavaScript im Frontend brauchst. Du könntest mit einer Template-Engine die Dateien so rendern, dass sie die Inhalte anzeigen, die sie anzeigen sollen.

    Zweiter Fall ist die Nutzung eines Routing im Frontend: Hier könntest du dann mit etwas mehr Aufwand über den sogenannten IPC-Channel (Inter-Process Communication) kommunizieren. Ich nutze meist JSON-Objects, die die Daten beinhalten und dann eben Vue.js, um die Daten im Frontend zu verarbeiten. Da bist du dann aber frei.


    Natürlich kannst du auch den IPC-Channel in Fall 1 nutzen, um Inhalte zu ändern oder Ähnliches.


    Zu deiner letzten Frage kann ich dir leider nichts sagen, da ich mich nicht mit den genutzten Libraries auskenne und außerdem weder den Code, den du nutzt, noch einen Fehler habe, an dem man so in etwa herausfinden könnte, woran es scheitert.


    Mit freundlichen Grüßen

    Marc

    Wo genau liegen die Unterschiede zwischen LXC und KVM?

    KVM und LXC verfolgen zwei unterschiedliche Virtualisierungsmöglichkeiten. KVM (Kernel-based Virtual Machine) ist dabei als virtuelle Maschine zu betrachten, während LXC nur eine Container-Virtualisierung darstellt.


    Container-Virtualisierung heißt, dass dein "Server" auf dem Host-OS basiert, also auf seinem Kernel.

    KVM hingegen hat eine weitere Schnittstelle (Hypervisor) zwischen dem Host-OS und dem "Guest-OS", also dem Betriebssystem auf deinem Server. Hier liefert das Guest-OS seinen eigenen Kernel, ist also nicht auf den Kernel des Betriebssystems, auf dem es virtualisiert wurde, angewiesen.


    Um das ganze veranschaulichen zu können (hier am Beispiel von Docker):

    Virtuelle-Maschinen_vs-Docker-Container_Crisp-Research

    Hier sieht man dann, dass bei einer vollwertigen virtuellen Maschine (also wie KVM) auf dem Server das Host-OS installiert ist, in dem dann der Hypervisor eine Abstraktion des Host-OS zu dem Guest-OS in der VM vornimmt.

    Bei Containern sieht man dann, dass die Virtualisierungen direkt auf dem Host-OS vorgenommen werden und keine Abstraktion stattfindet. Bei Docker ist es dann so, dass man eine App als Container starten kann. Sie beinhaltet dann kein vollwertiges Betriebssystem sondern nur die benötigten Abhängigkeiten:

    Dieser wird als isolierter Prozess auf dem Host Betriebssystem ausgeführt und teilt sich den Linux-Kernel mit anderen Docker Containern. Durch die strickte Isolation können mehrere Container auf dieselben Kernel-Ressourcen zugreifen. Für jeden Container lässt sich jedoch exakt definieren, wie viele Ressourcen (Prozessor, RAM, Bandbreite) ihm zur Verfügung stehen.

    Ich hoffe dir kann das helfen.

    Was genau willst du machen? Anhand dessen, dass du deine Config nicht öffentlich zugänglich machen willst, schließe ich fast daraus, als wolltest du dort irgendwelche Zugangsdaten für irgendwas speichern.


    Soweit mir bekannt ist, kannst du keinerlei Daten, die im Frontend benötigt werden, nicht nicht zugänglich machen.


    Und sofern ich mit meiner ersten Annahme richtig liege, würde ich auch dringend davon abraten, solche Daten auszuliefern.

    Also willst du, dass man deine Dateien nicht aufrufen darf, der Browser aber damit arbeiten soll? Das ist nicht möglich. Du kannst nicht einerseits sagen, dass niemand die Dateien lesen darf, der Browser sie aber zum Ausführen lesen soll.


    Vor allem: Was ist daran so schlimm?

    Ich würde Port 80 von Port 443 in der Config trennen und für beide einzelne Server-Blöcke hinzufügen. Dann kannst du dann hingehen und mit

    Code
    1. server {
    2. listen 80;
    3. server_name change.me;
    4. return 301 https://change.me$request_uri;
    5. }

    immer von Port 80 (HTTP) auf Port 443 (HTTPS) weiterleiten.


    Der Code 301 beim return steht außerdem für "Moved Permanently", was so viel bedeutet, wie leite weiter, diese Seite gibt's nicht (mehr).


    EDIT: Das $requestUri in der URL beim return ist der "Pfad" der hinter der Domain steht. Also bei change.me/test/subpage/irgendwas wäre $requestUri dann /test/subpage/irgendwas. nginx ersetzt dir das dann intern.

    Einfach Peinlich!

    Worum ging es dir hier genau? Ich blicke da irgendwie nicht durch, was du gerade zeigen wolltest. Das Impressum ist vorhanden (funktioniert auf der einen Seite nicht, wegen falschem Routing vermutlich) und per Frame sind hier auch keine Seiten auf anderen eingebunden. Und das besagt doch der Artikel, den du da vorgelegt hast, dass man das ausweisen muss, wenn man fremden Inhalt per Frame einbindet. (Soweit ich das verstehe)


    Abgesehen davon: minecraft-server.eu und hytale.spiele-server.eu sind doch jeweils was ganz eigenes. Nur da es vom gleiche Betreiber kommt, ist das Design halt gleich.


    Und schließlich stellt sich mir noch die Frage, was das ganze jetzt mit dem eigentlichen "Projekt" hier zu tun hat. Ist irgendwie leicht Offtopic, mMn.

    Also, das Problem, das wir hier aktuell haben ist folgendes. Deine React-App weiß, dass es die Route /contact gibt, dein Webserver allerdings nicht. Da jetzt dein Webserver aber vor der React-App liegt, gibt dir der Webserver ein 404 aus.
    Heißt einfach ausgedrückt, dass du deinem Webserver sagen musst, dass er versuchen soll, eine Datei aufzurufen, die die React-App startet und dann kümmert sich danach React um das Routing der Webseite. Bei express geht das in etwa mit

    Code
    1. app.use((req, res, next) => {
    2. res.write(yourIndexFile);
    3. res.end();
    4. next();
    5. });


    Bei yourIndexFile muss die Datei, in der die React-App gestartet wird, zum Beispiel mittels Filesystem eingelesen werden.

    In dem Code erstellst du also einfach nur eine Middleware, die Express beim Aufruf der Seite nutzen soll. Hier also einfach das Ausgeben der index-Datei, damit die React-App gestartet wird.


    Wie das ganze bei Apache funktioniert, weiß ich leider nicht. Vermute aber, dass es da ebenfalls solche Möglichkeit gibt, das Routing von Allen URLs auf eine Datei weiterzuleiten.

    Das ist weniger ein Problem von React selber, sondern mehr ein Problem deines Webserver, den du verwendest. Vielleicht kannst du dazu noch was sagen. Nutzt du nginx/Apache dafür oder sogar etwas in Node.js? Und wie sieht die Konfiguration dessen aus?

    Das war aber nicht die Diskussion hier. Die Diskussion ging darüber, in welcher Sprache der Server "gemodded" werden kann. Und in dem Blogpost der gestern raus kam wurde darauf hingewiesen, dass eben C# als Programmiersprache für das Spiel genutzt wird und Java für den Server. Somit ist naheliegend, dass Java verwendet wird um seinen Server zu erweitern.


    Das Ingame-Scripting hingegen kann dann tatsächlich auch mit Skriptsprachen wie Lua, JavaScript oder Anderem erfolgen. Aufgrund der Einfachheit vermute ich an der Stelle mal Lua. Aber das bleibt abzuwarten.

    Dann hast du irgendwas umgestellt Microsamp . Bei mir ist die Webseite responsiv und passt sich auch meinem Handy (OnePlus 3) an. Das macht auch schon allein deswegen Sinn, da deren Design quasi das Design des WSC ist (also wie das hier im Forum), nur eben angepasst auf deren Bedürfnisse. Heißt, Sie haben nur das Design farblich angepasst und das Header-Image geändert. Mehr fällt mir jetzt auch auf Anhieb nicht auf.

    Wenn man sich dann noch genauer das Stylesheeet ansieht, merkt man auch, dass das soweit vollständig ist, bzw. scheint.


    Einziger Punkt ist ggf., dass das Design am Handy die volle Breite nutzt. Das sieht nicht so zu 100% gut aus, aber mehr auch nicht.

    Hey,


    hiermit melde ich mich auch mal in diesem Forum nochmal zu Wort. Einige werden jetzt schon wissen, weshalb :/


    Du sagtest zu Anfang, dass du wenige moderne Forensoftwares findest, die Open Source sind. Dazu kann ich dir hier erstmal NodeBB nennen, welches eine - im Gegensatz zu der noch kommenden Software - bereits fertige Forensoftware ist. Du findest dieses Projekt unter Anderem hier: https://github.com/NodeBB/NodeBB


    NodeBB setzt dabei vor Allem auf die Möglichkeit der Single Page Application, allerdings nicht in einem solchen Umfang, dass Inhalte live nachgeladen werden. Soweit ich da richtig informiert bin, lädt NodeBB intern in einen Container einen Teil der Seite, der lediglich über einen Webserver gegeben wird. Um da allerdings genauer ins Detail zu gehen fehlt mir das genaue Wissen über NodeBB.

    An für sich bietet NodeBB ein meiner Meinung nach einfaches, schlichtes Design, das aber nicht groß den von dir genannten Augenkrebs hervorruft.


    Eine weitere Alternative für eine Forensoftware, bzw. genauer ein Content Management System (CMS) ist die sich von mir in Entwicklung befindliche WebSuite, welche man ebenfalls frei zugänglich auf GitHub findet: https://github.com/NodeLabIT/WebSuite-Core


    In meinem Fall setze ich zu 100% auf JavaScript, Server- wie Clientseitig. Serverseitig wird eben Node.js verwendet und Clientseitig setze ich (noch) auf Vue.js 2. Diese beiden einzelnen "Systeme" verbindet hier socket.io. Hier werden jegliche Daten, die auf der Webseite angezeigt werden (sollen), über socket.io angefragt, Serverseitig "bereitgelegt" und dann via socket.io wieder zum Client gesendet, wo diese dann in Vue.js final verarbeitet werden können und in die in Vue definierten Seiten eingepflegt werden.

    So kann ich beispielsweise direkt auf bestimmte Aktionen jedem (oder auch nur speziellen Nutzern) eine aktualisierte Version der Seite liefern. Wird beispielsweise in einer Unterhaltung eine Nachricht von Nutzer xy geschrieben, kann ich diese innerhalb weniger Augenblicke an jeden Nutzer in dieser Konversation verschicken. Ob diese Nachricht dann direkt angezeigt wird, oder aber erstmal nur eine Information ausgegeben wird, dass eine neue Nachricht vorhanden ist, weiß ich noch nicht. Da ist allerdings alles möglich.


    So positiv sich das jetzt aber alles anhört, so negativ kann man es auch sehen. Unter dieser Kombination leidet beispielsweise die Suchmaschinenoptimierung immens. Dadurch, dass das System ein Haufen aus bisher nicht gerenderten (JavaScript)-Templates der Seite besteht, wird die Indexierung einer Webseite ersichtlich schwierig. Zwar führen immer mehr Suchmaschinen auch JavaScript aus, allerdings nicht in diesem Umfang wie hier. Abhilfe schafft hier ein seitens uns entwickeltes System basierend auf phantomjs. Wir prüfen bei Zugriff auf den Webserver ob die Anfrage von einem Bot/einer Suchmaschine kommt. Falls ja, wird über phantomjs auf unsere Seite zugegriffen, welches den JavaScript-Code ausführen kann und, sobald die Webseite fertig geladen hat (dazu nutzen wir einen boolean, der auf bisher manuell auf true gesetzt werden), die fertig gerenderte Seite zurück gibt.


    Und damit wären wir erst bei einem von vielen Problemen bei diesem System.

    Ich selber sehe in einem solchen System die Verwendung von den node-Modulen als recht kritisch, da diese ziemlich weit verzweigt sein können. Express beispielsweise bietet lediglich einen Webserver, der aus insgesamt 30 (direkten) dependencies besteht, welche erneut aus etwaigen weiteren dependencies bestehen. Dann hast du letztlich einen riesigen Baum an dependencies, die du nicht alle Überwachen kannst. Somit bieten diese Module quasi eine recht einfache Möglichkeit Schadcode in die Seite einzubetten. Vielleicht bin ich an dieser Stelle auch einfach zu ängstlich.


    Das hat mich unter anderem allerdings auch dazu verleiten lassen auf Docker zu setzen. Docker hat in meinem Fall den Vorteil, dass ich dem Nutzer ein universell auf jedem Server funktionierendes System bieten kann, das sich unter Anderem durch die Nutzung von phantom.js und argon2(id) als sehr vorteilhaft erweist.


    Nachteil generell an Node.js ist: Ist dein Code nicht robust wird's schwierig. Bei PHP ist hier der Vorteil, dass wenn auf einer Seite ein Fehler auftritt, dann funktioniert diese eine spezielle Seite nicht. Bei Node.js ist dann aber erstmal das gesamte System offline. Zwar kann man das beispielsweise mittels dem Built-In Cluster von Node.js vorbeugen, allerdings bringt auch dieses wieder einige Probleme mit sich, die je nachdem einiges an Improvisation verlangt. So musste ich beispielsweise den socket.io-Server in dem Master verlagern, da ich andernfalls keine durchgehende Verbindung zwischen Client und Server herstellen konnte, da die Socket-Verbindung immer zwischen den unterschiedlichen Workern hin und her gesprungen ist und dadurch die Verbindung immer neu aufgebaut wurde, bzw. abgebrochen wurde.


    Ich kann also bei einer Umsetzung mit Node.js nur empfehlen, genau zu überlegen, was man wie machen möchte und ggf. auch überlegen welche Probleme das mit sich bringen kann, da es andernfalls schnell kompliziert werden kann.


    Mit freundlichem Gruß

    ilou

    Wenn ich es richtig sehe hast du beim ersten INNER JOIN beim ON das U vor "UID" groß geschrieben. Deswegen findet der die Tabellenspalte nicht.

    Inwiefern ist die Aussage, dass sich das "nicht einfach ins Board einfügen lässt" zu verstehen? Aufgrund dieser Aussage denke ich, dass ihr auf eurer Webseite ein CMS wie das WSC oder Xenforo nutzt. Falls dem so ist, so wird die Entwicklung noch mal um einiges komplizierter als sie ohnehin schon für euch ist, da ihr (speziell für das WSC) ein (für unerfahrene) aufwändiges Paket aus Seiten-Templates, Configs und PHP-Dateien zusammenbasteln müsst.


    Vielleicht wäre es also hilfreich zu wissen, welches System ihr genau nutzt um euch dahin gehend helfen zu können.


    Mit freundlichen Grüßen

    ilou