[Review] SRCDS Webconsole
(SRCDS = Source Dedicated Server, POC = Proof of Concept)
Ik ben tijdje terug eindelijk eens begonnen met een POC van het idee wat ik al een aantal jaar in m'n hoofd heb zitten, namelijk een web console. Voorheen had ik dit ook al gerealiseerd, maar werd de verbinding telkens opnieuw geopend zodra er een commando verstuurd werd.
Nu maak ik gebruik van NodeJS, wat prima werkt. Het idee is dat er een soort van rcon web console ontstaat. Dingen als chat berichten worden dus niet terug gestuurd van de server naar de website.
Ik heb op het moment een POC online gezet, en er draait een garry's mod servertje localhost welke gebruikt kan worden om dit systeem op te testen. Het geheel zou moeten werken op alle SRCDS servers.
Linkje naar de webpage en hier het linkje naar de login gegevens van de test server. (als deze het niet doet, staat de server waarschijnlijk uit, en zou je het op een ander tijd stip weer even moeten proberen :))
Het gaat hier niet om het design, maar puur om het systeem wat erachter draait.
Nu heb ik meteen een vraagje, op het moment word d.m.v. php de login gegevens van de server geëncrypt opgeslagen in de database. De key van deze encryptie word terug gegeven aan de client (de webbrowser). De client stuurt deze vervolgens naar de socket.io server die aan de hand van de key en de encryptie in de database, de login gegevens decrypt en verbinding maakt. Dit heb ik gedaan om het geheel zo veilig mogelijk te maken.
Heeft iemand misschien een idee hoe ik het beter zou kunnen doen? Of zou het zoals het nu is, prima zijn?
Bij voorbaat dank!
ziet er verder netjes uit, werkt snel alleen zou het wel logischer zijn om de nieuwste berichten onderin te zien net als in de console zelf. Werkt net iets fijner dan bovenin.
De token ziet er vrij random uit (base64_encoded en gesplitst in twee delen, bij mij was het 2 cijfers en vervolgens a-Z0-9 en de speciale tekens waar niet direct iets in gevonden konden worden). Ziet er té random uit om die te kunnen bruteforcen, maar daar zou je wel een beveiliging tegen moeten maken voor de zekerheid.
Bedankt voor de tips! Ik heb kwa escaping en design vrij weinig aandacht besteed met de achterliggende gedachten dat het nu leuk is om een beetje te 'ouwehoeren' op de test server, maar later mensen dit dan bij hun eigen game server zouden doen zeg maar. Ik zal het wel even aanpassen, omdat meerdere mensen er gebruik van maken.
De berichten ga ik inderdaad ook nog even laten appenden i.p.v. prependen.
De token is de key van een encryptie die in de database staat, gecombineerd met een ID van het kollom uit de database. Zodra je bijv. inlogt, worden de login gegevens van de game server (ip + pass) geencrypted en in database gezet. De key van deze encryptie is de key die jij tegen gekomen bent. Deze key word inderdaad random aangemaakt uit kleine letters, hoofdletters en speciale karakters.
De NodeJS server ontvangt de token die je browser erheen stuurt, haalt de ID eruit, haalt de database entry op met die ID, probeert de encryptie te decrypten. Of dit gelukt is, word geverifieerd met een aantal checks waaronder het IP adres waarmee je de gegevens poste en waarmee je verbonden bent naar de NodeJS server. Zodra de login gegevens gedecrypt zijn, word de encryptie uit de database verwijderd (password blijft dus niet opgeslagen), stel de token is onjuist en de encryptie is niet decrypted, word hij ook verwijderd (om brute force te voorkomen). Dit is ook meteen de reden waarom ik vroeg of het handig is om dit zo te doen, of het anders aan te pakken.
Thnx voor de input!
Edit
De punten zijn aangepast. In en output worden nu geëscaped en de nieuwe input voor de console komt onderaan te staan.
Gewijzigd op 10/02/2014 23:38:30 door Cake Masher