Eigener Sync-Server für Firefox: Difference between revisions
No edit summary |
|||
(67 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
== Eigener Sync-Server für Firefox == |
|||
= Theorie = |
= Theorie = |
||
== Überblick == |
|||
https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/ |
|||
https://wiki.mozilla.org/images/f/ff/Firefox_Accounts_and_Sync_Architecture.png |
|||
== Aufgabenbereiche der einzelnen Server == |
|||
https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol |
|||
=== Sync-Server === |
|||
Speichert (verschlüsselt) die zu synchronisierenden Daten der angemeldeten Nutzer ab. Die bereitgestellte Konfiguration nutzt eine SQLite DB unter (/tmp/syncserver.db). Spricht mit dem BrowserId-Verifier. Läuft lokal auf Port 5000 |
|||
=== fxa-auth-server === |
|||
'''Module/Komponenten''' |
|||
Verwaltet die Accounts. Gibt die Bestätigungs-Mail-Links aus. |
|||
Muss um die E-Mail-Links zu generieren die Adresse vom Content-Server kennen. |
|||
Die Datenbank-Andbindung wird per Konfigurationseintrag gesetzt. Das standardmäßige DB-Backend ist [https://www.npmjs.org/package/http-db http-db] |
|||
=== fxa-content-server === |
|||
*'''Sync Server''' |
|||
Liefert das Web-Frontend für den auth-server: login/anmelden/verwaltung |
|||
Die Javascript und CSS Ressourcen werden mit [http://bower.io/ Bower] verwaltet. |
|||
Die Einloggen/Registrierungs-Vorgänge werden an den auth-server weitergereicht. |
|||
=== browserid-verifier === |
|||
*'''Firefox Accounts Server (fxa)''' |
|||
Generiert Challenges für die BrowserID Zertifikate und verifiziert Berechtigungen am Auth-Server. |
|||
== Further Reading == |
|||
auth-server |
|||
manages accounts database |
|||
https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/ |
|||
content-server |
|||
web-based user interface |
|||
https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol |
|||
= Work in Progress = |
|||
https://developer.mozilla.org/en-US/Firefox_Accounts |
|||
1. Schritt: lokaler sync-server mit mozilla fx-Accounts |
|||
https://wiki.mozilla.org/Identity/Firefox-Accounts |
|||
= Lösung = |
|||
== MVP: lokaler Syncserver angebunden an FXA-System == |
|||
Anleitung zu finden unter: |
Anleitung zu finden unter: |
||
https://docs.services.mozilla.com/howtos/run-sync-1.5.html |
https://docs.services.mozilla.com/howtos/run-sync-1.5.html |
||
Der Standalone Syncserver bringt von sich aus keine SSL-Unterstützung mit, |
|||
2. Schritt: fxa-auth-server aufsetzen |
|||
allerdings kann die syncserver.ini über einen Apachen und mod_wsgi eingebunden werden (sodass der Apache sich um Verschlüsselung kümmert) |
|||
https://github.com/mozilla/fxa-auth-server |
|||
3. Schritt: fxa-content-server aufsetzen |
|||
https://github.com/mozilla/fxa-content-server |
|||
== Überblick == |
|||
4. Schritt: Firefox an eigenen fxa-server anbinden |
|||
== Manuelle Vorbereitung== |
|||
https://docs.services.mozilla.com/howtos/run-fxa.html |
|||
Zertifikate erstellen |
|||
Hosts Config |
|||
= Debug Optionen = |
|||
Firefox: about:sync-log |
|||
config: |
|||
tokenServerURI: http://192.168.56.101:5000/token/1.0/sync/1.5 |
|||
== Einrichtung über [https://github.com/ansible/ansible Ansible] == |
|||
=== 1. Vorbereitung vm === |
|||
* Ubuntu vm |
|||
* Einrichtung Netzwerk |
|||
* Auf Host: ansible_hosts ip des Gastes in gruppe [vms] eintragen |
|||
=== 2. Befehle === |
|||
'''Test''' |
|||
ansible vms -m ping --ask-pass -i ./ansible_hosts |
|||
'''Check syntax''' |
|||
ansible-playbook --syntax-check --list-tasks -i ./ansible_hosts ./ansible.yml |
|||
'''Run''' |
|||
ansible-playbook --ask-pass --ask-sudo-pass -i ./ansible_hosts ./ansible.yml |
|||
'''Files zu finden unter:''' |
|||
==Plug-in== |
|||
automatische Konfiguration des Clients zur Nutzung der eigenen sync und fxa server |
|||
Der Nutzer wird aufegordert die Adresse des Sync Servers anzugeben, das Plug-in setzt dann alle benötigten Einträge in about:config |
|||
services.sync.tokenServerURI |
|||
identity.fxaccounts.auth.uri |
|||
identity.fxaccounts.remote.force_auth.uri |
|||
identity.fxaccounts.remote.signin.uri |
|||
identity.fxaccounts.remote.signup.uri |
|||
identity.fxaccounts.settings.uri |
|||
= Hindernisse = |
|||
== Email-Verifizierung == |
|||
Nach der Registrierung (am lokalen FXA-System) muss die eingegebene E-Mail Adresse verifiziert werden. Wenn im Auth-Server kein SMTP-Server konfiguriert ist, wird der generierte Link nicht verschickt. Um die E-Mail trotzdem zu verifizieren genügt es sich den Link aus der Log-Ausgabe des auth-servers zu kopieren und ihn aufzurufen. |
|||
== Content Server braucht nach npm install noch bower run == |
|||
Bower muss installiert werden (npm install -g bower) |
|||
und dann im Verzeichnis ein "bower install" |
|||
== Server nur über https ansprechbar == |
|||
about:accounts gibt in der browser console folgenden Fehler aus: |
|||
"Firefox Account Error: Couldn't init Firefox Account wrapper: Firefox Accounts server must use HTTPS |
|||
" aboutaccounts.js:28 |
|||
== Connection Reset == |
|||
Bei selbst-signierten Zertifikaten kann es vorkommen das beim Login über den Account-Server (about:accounts) eine leere Seite ausgeliefert wird. |
|||
Dies kann 3 Ursachen haben: |
|||
* fehlende Ressourcen des Content Server (siehe bower install) |
|||
* falsche Konfiguration der Content Server Ressourcen (js/css Requests geben 404 zurück) |
|||
* Nicht-Akzeptiertes Zertifikat das ausgeliefert wird. In diesem Fall wird '''keine Fehlermeldung''' ausgegeben. Dieser Fall lässt sich durch ein RESET-Paket auf http-Ebene erkennen (bsp durch Wireshark). Er kann behoben werden durch manuellen aufruf der Login-Seite (und Einrichtung einer Ausnahme im Dialog "Dieser Verbindung wird nicht vertraut"). |
|||
== Cross Origin Ajax Calls == |
|||
Firefox macht während des Logins AJAX Calls vom Content Server an den Auth Server. |
|||
Bei Mozilla ist das kein problem, da die uris für API/Content Server subdomains von firefox.com sind: |
|||
Wenn die Server allerdings lokal laufen, schlägt der Ajax-Request mit einem Cross-Domain Fehler |
|||
fehl (was ja eigentlich auch gut so ist). In unserem Fall ist das aber ein Problem. |
|||
[[File:Flow_firefox.PNG]] |
|||
[[File:Flow_localhost.PNG]] |
|||
Lösungsansatz: NGINX, Apache reverse proxy |
|||
== Anbindung an Browserid-verifier == |
|||
502 bei lokal Verifier, trailing/slash, audiences |
|||
== Umstellung von Subdomains auf virtuelle Ordner == |
|||
relative links im content-server |
|||
aufruf von /.well-known/... |
|||
= Weiterführende Informationen = |
|||
== Links == |
|||
nginx rewrite: http://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy |
|||
Virtualbox HostNetwork: http://www.thomas-krenn.com/de/wiki/Netzwerkkonfiguration_in_VirtualBox#Host-only_networking |
|||
= Notizenhaufen = |
|||
Evaluieren: bringt uns das was? |
|||
https://github.com/mozilla/fxa-dev |
https://github.com/mozilla/fxa-dev |
||
Line 55: | Line 144: | ||
http://www.ncalexander.net/blog/2014/07/05/how-to-connect-firefox-for-android-to-self-hosted-services/ |
http://www.ncalexander.net/blog/2014/07/05/how-to-connect-firefox-for-android-to-self-hosted-services/ |
||
http://meta.wikimedia.org/wiki/Help:Wikitext_examples |
|||
BrowserId Verifier? |
|||
== Debug Infos == |
|||
Paketverkehr monitoring mit tshark |
|||
Firefox: about:sync-log |
|||
Virtualbox HostNetwork: http://www.thomas-krenn.com/de/wiki/Netzwerkkonfiguration_in_VirtualBox#Host-only_networking |
|||
== Config == |
|||
=== Ports === |
|||
Ports: |
|||
Sync: 5000 |
|||
API: 9000 |
|||
content: 3030 |
|||
verify: 7070 |
|||
=== Firefox === |
|||
'''syncserver:''' |
|||
services.sync.tokenServerURI |
|||
https://sync.accounts.devlocal/token/1.0/sync/1.5 --> https://accounts.devlocal/ffs/token/1.0/sync/1.5 |
|||
'''auth-services:''' |
|||
identity.fxaccounts.auth.uri |
|||
https://api.accounts.devlocal/v1 --> https://accounts.devlocal/api/v1 |
|||
identity.fxaccounts.remote.force_auth.uri |
|||
https://accounts.devlocal/force_auth?service=sync&context=fx_desktop_v1 |
|||
identity.fxaccounts.remote.signin.uri |
|||
https://accounts.devlocal/signin?service=sync&context=fx_desktop_v1 |
|||
identity.fxaccounts.remote.signup.uri |
|||
https://accounts.devlocal/signup?service=sync&context=fx_desktop_v1 |
|||
identity.fxaccounts.settings.uri |
|||
https://accounts.devlocal/settings |
Latest revision as of 15:17, 13 October 2014
Theorie
Überblick
https://wiki.mozilla.org/images/f/ff/Firefox_Accounts_and_Sync_Architecture.png
Aufgabenbereiche der einzelnen Server
Sync-Server
Speichert (verschlüsselt) die zu synchronisierenden Daten der angemeldeten Nutzer ab. Die bereitgestellte Konfiguration nutzt eine SQLite DB unter (/tmp/syncserver.db). Spricht mit dem BrowserId-Verifier. Läuft lokal auf Port 5000
fxa-auth-server
Verwaltet die Accounts. Gibt die Bestätigungs-Mail-Links aus. Muss um die E-Mail-Links zu generieren die Adresse vom Content-Server kennen. Die Datenbank-Andbindung wird per Konfigurationseintrag gesetzt. Das standardmäßige DB-Backend ist http-db
fxa-content-server
Liefert das Web-Frontend für den auth-server: login/anmelden/verwaltung Die Javascript und CSS Ressourcen werden mit Bower verwaltet. Die Einloggen/Registrierungs-Vorgänge werden an den auth-server weitergereicht.
browserid-verifier
Generiert Challenges für die BrowserID Zertifikate und verifiziert Berechtigungen am Auth-Server.
Further Reading
https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/
https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol
https://developer.mozilla.org/en-US/Firefox_Accounts
https://wiki.mozilla.org/Identity/Firefox-Accounts
Lösung
MVP: lokaler Syncserver angebunden an FXA-System
Anleitung zu finden unter:
https://docs.services.mozilla.com/howtos/run-sync-1.5.html
Der Standalone Syncserver bringt von sich aus keine SSL-Unterstützung mit, allerdings kann die syncserver.ini über einen Apachen und mod_wsgi eingebunden werden (sodass der Apache sich um Verschlüsselung kümmert)
Überblick
Manuelle Vorbereitung
Zertifikate erstellen
Hosts Config
Einrichtung über Ansible
1. Vorbereitung vm
- Ubuntu vm
- Einrichtung Netzwerk
- Auf Host: ansible_hosts ip des Gastes in gruppe [vms] eintragen
2. Befehle
Test ansible vms -m ping --ask-pass -i ./ansible_hosts
Check syntax ansible-playbook --syntax-check --list-tasks -i ./ansible_hosts ./ansible.yml
Run ansible-playbook --ask-pass --ask-sudo-pass -i ./ansible_hosts ./ansible.yml
Files zu finden unter:
Plug-in
automatische Konfiguration des Clients zur Nutzung der eigenen sync und fxa server
Der Nutzer wird aufegordert die Adresse des Sync Servers anzugeben, das Plug-in setzt dann alle benötigten Einträge in about:config
services.sync.tokenServerURI
identity.fxaccounts.auth.uri
identity.fxaccounts.remote.force_auth.uri
identity.fxaccounts.remote.signin.uri
identity.fxaccounts.remote.signup.uri
identity.fxaccounts.settings.uri
Hindernisse
Email-Verifizierung
Nach der Registrierung (am lokalen FXA-System) muss die eingegebene E-Mail Adresse verifiziert werden. Wenn im Auth-Server kein SMTP-Server konfiguriert ist, wird der generierte Link nicht verschickt. Um die E-Mail trotzdem zu verifizieren genügt es sich den Link aus der Log-Ausgabe des auth-servers zu kopieren und ihn aufzurufen.
Content Server braucht nach npm install noch bower run
Bower muss installiert werden (npm install -g bower)
und dann im Verzeichnis ein "bower install"
Server nur über https ansprechbar
about:accounts gibt in der browser console folgenden Fehler aus:
"Firefox Account Error: Couldn't init Firefox Account wrapper: Firefox Accounts server must use HTTPS " aboutaccounts.js:28
Connection Reset
Bei selbst-signierten Zertifikaten kann es vorkommen das beim Login über den Account-Server (about:accounts) eine leere Seite ausgeliefert wird.
Dies kann 3 Ursachen haben:
- fehlende Ressourcen des Content Server (siehe bower install)
- falsche Konfiguration der Content Server Ressourcen (js/css Requests geben 404 zurück)
- Nicht-Akzeptiertes Zertifikat das ausgeliefert wird. In diesem Fall wird keine Fehlermeldung ausgegeben. Dieser Fall lässt sich durch ein RESET-Paket auf http-Ebene erkennen (bsp durch Wireshark). Er kann behoben werden durch manuellen aufruf der Login-Seite (und Einrichtung einer Ausnahme im Dialog "Dieser Verbindung wird nicht vertraut").
Cross Origin Ajax Calls
Firefox macht während des Logins AJAX Calls vom Content Server an den Auth Server. Bei Mozilla ist das kein problem, da die uris für API/Content Server subdomains von firefox.com sind:
Wenn die Server allerdings lokal laufen, schlägt der Ajax-Request mit einem Cross-Domain Fehler fehl (was ja eigentlich auch gut so ist). In unserem Fall ist das aber ein Problem.
Lösungsansatz: NGINX, Apache reverse proxy
Anbindung an Browserid-verifier
502 bei lokal Verifier, trailing/slash, audiences
Umstellung von Subdomains auf virtuelle Ordner
relative links im content-server
aufruf von /.well-known/...
Weiterführende Informationen
Links
nginx rewrite: http://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy
Virtualbox HostNetwork: http://www.thomas-krenn.com/de/wiki/Netzwerkkonfiguration_in_VirtualBox#Host-only_networking
https://github.com/mozilla/fxa-dev
https://blog.mozilla.org/services/2014/05/08/firefox-accounts-sync-1-5-and-self-hosting/
http://comments.gmane.org/gmane.comp.mozilla.sync.devel/924
https://github.com/callahad/selfhosted-sync
https://github.com/mozilla-services/syncserver
http://meta.wikimedia.org/wiki/Help:Wikitext_examples
Debug Infos
Firefox: about:sync-log
Config
Ports
Ports:
Sync: 5000
API: 9000
content: 3030
verify: 7070
Firefox
syncserver: services.sync.tokenServerURI
https://sync.accounts.devlocal/token/1.0/sync/1.5 --> https://accounts.devlocal/ffs/token/1.0/sync/1.5
auth-services: identity.fxaccounts.auth.uri
https://api.accounts.devlocal/v1 --> https://accounts.devlocal/api/v1
identity.fxaccounts.remote.force_auth.uri
https://accounts.devlocal/force_auth?service=sync&context=fx_desktop_v1
identity.fxaccounts.remote.signin.uri
https://accounts.devlocal/signin?service=sync&context=fx_desktop_v1
identity.fxaccounts.remote.signup.uri
https://accounts.devlocal/signup?service=sync&context=fx_desktop_v1
identity.fxaccounts.settings.uri