Ich möchte euch eine einfache Möglichkeit zeigen wie man schnell und einfach mit den beiden Tools PM2 und Codeship seine Anwendung auf einen Server deployed. Zunächst einmal was ist PM2? PM2 Runtime ist ein Produktionsprozess-Manager für Node.js-Anwendungen mit integriertem Load Balancer. Es ermöglicht Anwendungen für immer am Leben zu erhalten, sie ohne Ausfallzeiten neu zu laden und allgemeine Devops-Aufgaben zu vereinfachen.

PM2

Um PM2 zu installieren, kann man einfach node verwenden:

npm install pm2 -g

Für die CLI Autocompletion dann noch folgenden Befehl:

pm2 completion install

Nun fügt man seinem Node.js Projekt eine PM2 Konfigurationsdatei hinzu. Standardmäßig sucht pm2 nach den Namen ecosystem.config.js. Eine Datei kann wie folgt aussehen: 

module.exports = {
apps: [
        {
            name:”MeinServerName”,
            script: “dist/index.js”,
            env_production: {
                NODE_ENV: ‘production’
            }
        }
    ],
    deploy: {
        production: {
            user: ‘prod’,
            host: ‘server.fhstp.ac.at’,
            ref: ‘origin/master,
            repo: “https://github.com/User/repo.git”,
            path: ‘/srv/production’,
            ‘post-deploy’: ‘npm install && pm2 startOrRestart ecosystem.config.js –env production’
        }
    }
};

Die Konfigurationsdatei ist in zwei Teile aufgeteilt. In dem Bereich „apps“ geben wir an unter welchen Namen die Applikation laufen soll. Bei „script“ geben wir an mit welcher Datei die Applikation gestartet werden soll und dann können wir noch das node Environment spezifizieren. Dieser Bereich wird also gebraucht um die Applikation am Server laufen zu lassen.

Der zweite Teil (deploy) spezifiziert wie die Applikation auf unserem Server deployed werden soll. Hier spezifizieren wir zunächst mit welchen Benutzer pm2 die Applikation deployen soll. Demnach ist es ein Benutzer auf zb unserem Ubuntu Server.

Danach geben wir den Host Namen oder die IP-Adresse unseres Servers an. Die Zeilen „ref“ und „repo“ geben an von welchen Repository und welchem Branch PM2 die App clonen soll. Wo das ganze gespeichert wird gibt man bei „path“ an. Der Befehl „post-deploy“ spezifiziert dann noch was nach dem deploy unserer Applikation ausgeführt werden soll. In diesem Beispiel installieren wir zunächst die node_modules und starten danach unsere Applikation mit dem Befehl pm2 startOrRestart.

Damit man nicht immer ein Passwort eingeben muss, empfiehlt es sich einen SSH Key für den Benutzer zu erstellen. Nun kann man seine Applikation bereits von seinem Computer aus (auch am PC muss man pm2 installieren) auf den Server deployen. Beim ersten Mal muss man hierfür den Befehl pm2 deploy production setup ausführen. Nach dem ersten Setup muss man nun immer nur den Befehl pm2 deploy production ausführen.

Damit pm2 automatisch startet, wenn der Server rebootet wurde muss noch folgender Befehl am Server verwendet werden:

pm2 startup

Mit dem Befehl pm2 list sieht man nun alle laufenden PM2 Prozesse.

Codeship

Nun haben wir einen einfachen Weg unsere Node.js Applikation am Server zu deployen allerdings passiert dies immer noch nicht automatisch. Hierfür können wir das Tool Codeship verwenden. Codeship verwendet Virtuell Machines (VMs) um die Applikationen in einem isolierten Umfeld zu starten und Tests laufen zu lassen. Da jedes Projekt seine eigene VM hat können wir diese auch individuell konfigurieren. So können wir zum Beispiel pm2 installieren oder wir könnten eine Datenbank installieren.

Wenn ihr euch einen Account erstellt habt und eine Organisation erstellt habt, können wir beginnen ein neues Projekt hinzu zu fügen.

Hierfür spezifizieren wir zunächst ein Repository in dem unsere Node.js Applikation gehostet ist.

Zum Schluss müssen wir noch einen Projekttyp auswählen. Für uns reicht der Basic Typ.

Es öffnen sich nun die Codeship Einstellungen. Im ersten Tab Tests können wir die Tests die wir für unsere Applikation ausführen lassen wollen spezifizieren. Doch zunächst können wir im Bereich „Setup commands“ die Befehle angeben um die node modules und pm2 zu installieren.

Danach können wir eine Testpipeline erstellen. In diesem Beispiel starten wir die Tests einfach mit dem Befehl npm tests.

Im Tab Deploy können wir spezifizieren wie die Applikation deployed werden soll wenn die Tests erfolgreich waren. Für PM2 erstellen wir zunächst eine neue Pipeline für den Branch master.

Danach erstellen wir ein „Custom Script“ und geben einfach wieder den Befehl an, den wir auch bereits vorher schon verwendet haben.

Im Tab Build Triggers können wir nun noch angeben wann ein Codeship Build gestartet werden soll. Ich habe hier die beiden Branches master und develop angegeben. Dies bedeutet, dass für diese beiden Branches die Tests gestartet werden. Allerdings wird nur bei einem Build für den master Branch der Deployment Prozess gestartet.

Das einzige was nun noch zu tun bleibt ist den SSH Key von Codeship auf unseren Server zu kopieren. Diesen findet ihr im Tab General.

Sowohl PM2 als auch Codehsip bieten noch viele weitere Konfigurationsmöglichkeiten aber schon mit diesen wenigen Schritten haben wir einen Continuous Deployment Prozess geschaffen der uns automatisch für die beiden Branches develop und master Tests laufen lässt und für Master Commits die Applikation danach automatisch auf unseren Ubuntu Server deployed.

The post Simple Continuous Deployment für Node.JS appeared first on Mobile USTP MKL.

Jeder der im Web arbeitet kennt (sollte) das HTTP-Protokoll. Es wird überall im Web verwendet und ist daher eines der wichtigsten Kommunikationsprotokolle. Mit der Einführung der Internet of Things (IoT) wurde die Notwendigkeit, das HTTP-Protokoll zu sichern, noch größer als bisher. Die Vorteile von HTTP sind seine Einfachheit und seine breite Verfügbarkeit von Software-Implementierungen. Die Nachteile sind allerdings, dass es keine Sicherheitsimplementierung gibt.

Aus diesem Grund wurde das HTTPS-Protokoll entwickelt. HTTPS umschließt HTTP in TLS-Zertifikaten (Transport Layer Security), was der erste Schritt zum Sichern der Kommunikation über das Internet war. Aber nur die Verwendung des HTTPS-Protokolls, ist immer noch nicht ausreichend. Um die Kommunikationssicherheit auf ein höheres Niveau zu bringen, verwenden IT-Security Experten jetzt die HTTP-Response-Header. Diese sind einfache Key-Value Paare, um Sicherheitsrichtlinien von Servern auf Clients zu übertragen. Einer der ersten Security Header ist der HTTP Strict Transport Security-Header, der den Browser des Benutzers zwingt, nur HTTPS-Anforderungen für die Kommunikation mit einer Domäne zu verwenden. Außerdem haben die Entwickler von Browsern mehr und mehr Security-Header wie X-Frame-Options eingeführt. Dieser informiert den Browser darüber, wie Daten interpretiert werden müssen und wo sie angefordert werden dürfen.

Was sind HTTP Security Header?

Ein HTTP-Header ist ein Key-Value-Paar, das Metadaten über den Inhalt der Antwort beschreibt. HTTP-Security Header geben einem User Agent (z.B: Browser) Informationen über die Verarbeitung des Inhalts in der Antwort. Anbieter von Browsern veröffentlichten neue HTTP-Header, um die korrekte Interpretation der empfangenen Daten sicherzustellen und ihre Benutzer zu schützen. Im Gegensatz zu HTTPS ändert es nicht, wie die Daten übertragen werden. HTTPS verschlüsselt zum Beispiel Daten, aber die Header können User Agents beschränken, um Anfragen nur an einige vertrauenswürdige Domains statt an jede verfügbare Domain zu richten.

Unterschied zwischen HTTPS und Security Headers

HTTPS schützt nur die Daten von Requests und Responses. HTTP-Security Headers liefert stattdessen Informationen über die Daten und darüber, wie der Client damit umgehen soll. Während HTTPS für die Verwaltung sicherer Verbindungen zuständig ist, sind HTTP-Header dafür verantwortlich, wie der Inhalt angezeigt wird und von welchen Domänen ein User Agent andere Informationen wie Stylesheets, Skript-Dateien oder Bilder anfordern darf. Der Benutzer soll mit diesen Headern vor Angriffen wie Clickjacking oder Cross-Site Scripting (XSS) geschützt werden.

Die bekanntesten Security-Header

Referrer-Policy

Ein Client kann einen Referer [sic!] – Request-Header enthalten, der angibt auf welcher Webseite der Benutzer zuvor war, beziehungsweise von welchem Server der Benutzer umgeleitet wurde. Dieser Header wird hauptsächlich für Analysen verwendet und sollte niemals als Authentifizierungsmethode verwendet werden. Ein Server möchte diese Art von Informationen jedoch möglicherweise nicht teilen. Hierfür kann der Server eine Referrer-Policy verwenden. Wenn der Wert dieses Headers beispielsweise kein Verweis ist, sollte ein Client niemals einen Referer-Header an diese Site oder an die erste Anfrage an einen anderen Webserver senden.

Content-Security-Policy

Dieser Header wird verwendet um zu steuern, von welchen Domänen eine Quelle wie ein Stylesheet oder ein Skript geladen werden kann. Jede andere Domäne wird nicht in Betracht gezogen und verhindert somit einen XSS-Angriff.

Public Key Pinning

Ein Webserver kann das Risiko von Man-in-the-Middle-Attacken (MIT) reduzieren, indem er seinen öffentlichen Schlüssel, der dann in nachfolgenden TLS-Verbindungen verwendet wird, in die allererste HTTP-Antwort einfügt. Der User Agent speichert es und verwendet nur noch diesen spezifischen Schlüssel für zukünftige Anfragen. Ein Angreifer könnte jedoch den Header so manipulieren, dass ein Benutzer den falschen öffentlichen Schlüssel speichert.

X-Frame-Options

Dieser Header soll  Clickjacking-Angriffe verhindern. Mit den Optionen DENY, SAMEORIGIN oder einer Gruppe zulässiger Domänen muss ein Client überprüfen, ob ein HTTP-Inhalt in einem Frame angezeigt werden kann. Clickjacking wird durchgeführt, indem eine andere Website in einen unsichtbaren Iframe geladen und über den geladenen Inhalt gelegt wird. Wenn ein Opfer versucht, auf eine Schaltfläche zu klicken, um beispielsweise einen Dialog zu schließen, löst es eine Aktion im Iframe aus, beispielsweise eine Anmeldung an ein E-Mail-Konto.

X-XSS-Protection

Ein Webserver kann die XSS-Erkennung auf einem Client-Webbrowser aktiv aktivieren. Der Server verwendet hierfür den X-XSS-Protection-Header. Mit der Option 0 sollte ein Client den XSS-Schutz nicht deaktivieren. Wenn Sie ihn jedoch auf 1 setzen, sollte der Web-Browser versuchen, das XSS zu bereinigen und die Seite dennoch rendern. Fügt man Optionsmodus = Block hinzu, wird dem Webbrowser geraten, den Inhalt nicht zu rendern. Ein Webserver kann auch eine URL bereitstellen, um eine Erkennung von XSS zu melden. Da es noch nicht standardisiert ist, unterstützen nicht alle Browser diesen Header.

X-Content-Type-Options

Setzt ein Webserver diesen HTTP-Header mit der Option nosniff, interpretiert der Webserver MIME-Dateien nur so wie sie deklariert sind. Wenn beispielsweise eine JavaScript-Datei als reiner Text deklariert ist, sollte sie nicht ausgeführt werden.

Cross-Origin Resource Sharing

Die Cross-Origin Resource Sharing (CORS) ist kein einzelner HTTP-Header, sondern ein Set von vielen Headern. Normalerweise führt ein Webbrowser nur Anforderungen an einen Server mit demselben Ursprung durch. Wenn ein Webserver wünscht, dass eine andere Webanwendung auf seine Ressourcen zugreift, muss er den Header Access-Control-Allow-Origin mit den zulässigen Domänen angeben. Alternativ kann auch ein * zurückgeben werden. Dieser gibt an, dass alle Domänen zulässig sind.

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) ist ein serverseitiger Sicherheitsmechanismus, der z.B: Webbrowser dazu zwingt, Verbindungen nur über HTTPS herzustellen. Viele Websites wie Banken setzen auf sicheren end-to-end Transport, um die Daten ihrer Nutzer zu schützen. Leider erlauben Browser normalerweise ihren Benutzern, diese Schutzmechanismen zu deaktivieren, um nutzbar zu sein. Wenn zum Beispiel ein Zertifikat eines Webservers abgelaufen ist, erlaubt der Browser dem Benutzer zu entscheiden, ob weiterhin mit dem Server kommuniziert werden soll. Dieses Verhalten wird oft als “click(ing) through”-Security beschrieben. Mit HSTS kann dieses Verhalten verhindert werden.

Hat man HSTS konfiguriert, transformiert der Browser alle unsicheren URIs (http: //) auf HSTS-Hosts in sichere URIs (https: //), bevor die Anforderungen gesendet werden. Wenn somit irgendwo im Code eine Ressource wie ein Bild über eine unsichere HTTP-Verbindung angefordert wird, macht der Browser automatisch eine HTTPS URI daraus. Außerdem werden alle sicheren Anfragen beendet, wenn ein Fehler oder eine Warnung auftritt. Etwa 85% der weltweit verwendeten Browser unterstützen den HSTS-Mechanismus.

Schlusswort

Auch mit diesen Headern gibt es immer noch genug Sicherheitslücken die ein Hacker ausnutzen kann, aber die Verwendung reduziert dieses Risiko zumindest schon mal. Leider (wie oft in der Security) sind manche Header wie z.B: der HSTS etwas mühsam und zeitaufwendig bei der Umsetzung.

P.S. Die meisten von euch werden schonmal einen dieser Header verwendet haben, auch wenn es euch vielleicht nicht aufgefallen ist.

The post Web Security Headers appeared first on Mobile USTP MKL.

https://vue-material-old.netlify.com/#/

Das neue Vue-Material bietet ein paar coole neue Features wie zum Beispiel verbesserte Formular Komponenten oder zusätzliche Styling Optionen für zB die Snackbar. Möchte man nun die neue Version verwenden, stößt man schnell auf ein Problem. Während die Installation noch keine Herausforderung bereitstellt, sieht es bei der Konfiguration schon ganz anders aus. Aber ich beginne zunächst mal mit der Installation.

Installation

Die Installationsanleitung von Vue-Material findet ihr unter:

https://vuematerial.io/getting-started

Wie bereits bekannt können wir Vue-Material mit npm oder yarn installieren und die entsprechenden Kommandozeilen Befehle sind wie folgt:

$ npm install vue-material@beta --save
$ yarn add vue-material@beta

Um Vue-Material nun verwenden zu können öffnen wir unsere src/main.js Datei und fügen folgende Codezeilen hinzu:

import Vue from 'vue'
//import VueMaterial after Vue
import VueMaterial from 'vue-material'
import 'vue-material/dist/vue-material.min.css'

Vue.use(VueMaterial)

Bis jetzt gibt es keinen Unterschied zu der früheren Version von Vue-Material.

Konfiguration

Nach der Installation kommt die Konfiguration. Schaut man sich die Dokumentation des alten Vue-Materials an, konfiguriert man sein Theme auch gleich in der src/main.js Datei. Das Ganze kann dann wie folgt aussehen:

Vue.material.registerTheme('default', {
primary: {
color: 'yellow',
hue: '600',
textColor: 'black'
},
accent: 'blue',
warn: 'deep-orange',
background: 'white'
})

In der früheren Version wird mein Theme nun erfolgreich auf die Vue-Material Komponenten angewendet und ich bin somit fertig.

Die neue Konfiguration

In der neuen Version schaut das ganze leider etwas anders aus. Öffnet man die neue Konfigurationsanleitung (https://vuematerial.io/themes/configuration) sieht man nun plötzlich folgenden Codeschnipsel:

@import "~vue-material/dist/theme/engine"; // Import the theme engine

@include md-register-theme("default", (
 primary: md-get-palette-color(blue, A200) // The primary color of your application));

@import "~vue-material/dist/theme/all"; // Apply the theme

Man findet noch einige Möglichkeiten wie ich das Theme weiter anpassen kann, aber keinerlei Informationen wo ich diesen Code eingeben soll. Diejenigen unter euch die mit SCSS vertraut sind merken vielleicht, dass es sich bei diesem Codeschnipsel um SCSS Code handelt. Dies bedeutet, dass es nicht in meine src/main.js Datei gehören kann. Stattdessen muss man sich jetzt pro Theme das man registrieren möchte am besten eine eigene SCSS Datei anlegen.

Hierfür legen wir uns nun zunächst in unserem src Ordner einen neuen Ordner themes an. Und in diesem Ordner erstellen wir noch gleich eine Datei default.scss. Das Ganze sieht dann wie folgt aus:

Öffnen wir nun unsere default.scss Datei. Hier kann ich nun den Codeschnipsel von der Anleitung auf der Webseite einfügen. Für mein Theme sieht das ganze wie folgt aus:

@import "~vue-material/dist/theme/engine"; // Import the theme engine

@include md-register-theme("default", (
primary: md-get-palette-color(orange, 400), // The primary color of your application
accent: md-get-palette-color(pink, 300) // The accent and secondary color
));

@import "~vue-material/dist/theme/all"; // Apply the theme

Nun habe ich quasi mein Default Theme erstellt und wende das Theme auf alle Komponenten an. Was nun noch fehlt ist ein Import in der App.vue Datei. Wir haben zwar ein Theme registriert und sagen auch dass er das Theme auf alle Komponenten anwenden soll, aber das wird erst angewandt wenn wir das Theme in einer .vue Datei importieren. Ich möchte mein default Theme auf mein gesamtes Projekt anwenden und deshalb importiere ich es in der App.vue Datei. In meinem Projekt sieht diese Datei nun so aus:

Wichtig: Das Style Tag muss zusätzlich noch lang=”scss” dabeistehen haben!

Schlusswort

Nun sind wir fertig und euer Theme wird nun endlich wieder auf eure Komponenten angewendet.

Solltet ihr mit einem bestimmten Theme nur spezifische Komponenten anpassen wollen, dann importiert ihr einfach nur die entsprechenden Komponenten in eurer theme.scss Datei. Zum Beispiel:

@import "~vue-material/dist/components/MdButton/theme"; 
@import "~vue-material/dist/components/MdToolbar/theme";

Zum Schluss sei noch kurz angemerkt, dass es sich bei dieser Version um eine Beta handelt und es daher sein kann, dass nicht alles 100% funktioniert!

The post Die neue Vue-Material Installation? appeared first on Mobile USTP MKL.

Bei dem Projekt SocketQuiz handelt es sich um ein Quiz Applikation bei der eine Person ein Quiz starten bzw. freigeben kann. Alle Personen die den QR Code des Spiels scannen oder den Spielecode eingeben, können diesem Quiz beitreten. Alle Spieler können anschließend einen Playername eingeben und warten dann auf den Spielbeginn. Sobald alle Spieler dem Quiz beigetreten sind, kann der Quizleiter das Quiz starten. Daraufhin erhalten alle Spieler die erste Frage. Beantwortet ein Spieler die Frage sieht er sofort ob sie richtig oder falsch war. Haben alle Spieler die Frage beantwortet schaltet der Spielleiter die nächste Frage frei.

Funktionen der Applikation

Spielleiter

Login
Der Spielleiter kann sich mit seinen Zugangsdaten in der Applikation einloggen. Er sieht dann eine Übersicht all seiner Quizes.

Freigabe
Der Spielleiter kann ein Quiz freigeben oder deaktivieren. Nur wenn ein Quiz freigegeben ist können Spieler diesem beitreten.

Leitung
Sobald ein Quiz freigegeben wurde, wird der Spielleiter zur Quiz Administration weitergeleitet. Hier wird nun der QR Code und der Game Code des Quizes angezeigt. Die Spieler können nun dem Quiz beitreten. Danach kann der Spielleiter auf den “Start”-Button klicken um die erste Frage freizugeben. Beim Spielleiter so wie bei den Spielern wird die Frage und alle Antwortmöglichkeiten angezeigt. Haben alle Spieler die Frage beantwortet kann der Spielleiter mit dem “Next”-Button die nächste Frage freigeben. Sollte es sich um die letzte Frage handeln, wird der “Next”-Button zum “Finish”-Button. Der Spielleiter kann nun das Spiel beenden und bekommt die drei besten Spieler angezeigt.

Spieler

Beitreten

Der Spieler hat zwei Möglichkeiten um einem Quiz beizutreten. Die erste Möglichkeit ist das Scannen des QR-Codes und die zweite die Eingabe des Game Codes. Sobald der Spieler einem Quiz beigetreten ist, kann er/sie einen Namen eingeben.

Beantworten

Der Spieler kann freigeschaltete Fragen beantworteten und sieht sofort sein Ergebnis. Abschließend sieht er/sie wieviele Fragen er/sie falsch und richtig beantwortet hat.

Umsetzung

Die Applikation besteht aus einem Client und einem Serverteil. Die Client Applikation – sowohl der Spielleiter als auch der Spieler Part – habe ich mit dem Framework Angular umgesetzt. Um ein Design, das den Material Design Richtlinien entspricht, verwenden zu können, habe ich das Angular Material Plugin verwendet. Für die Erstellung der QR-Codes habe ich das Plugin angular-qrcode verwendet. Außerdem wurde für die WebSocket Kommunikation mit dem Server das Socket.io Plugin für Angular verwendet.

Bei dem Server handelt es sich um einen Node.js Server der mit Typescript und ESLint programmiert wurde. Für die Kommunikation mit dem Client wurde auch hier die Socket.io Library verwendet. Um die Quizes und die Benutzer Daten zu speichern wurde eine MySQL Datenbank verwendet. Für einen schnelleren und einfacheren Zugriff auf die Datenbank, habe ich das ORM Mapping von Sequelize verwendet. Um den lokalen Server auf den richtigen Serven zu deployen habe ich den Process Manager pm2 verwendet.

The post “Print-to-Mobile” – SocketQuiz appeared first on Mobile USTP MKL.