Deblan blog

Tag #Linux

Sharepoint Office365 sur Linux : automatiser l'authentification

Suite de l'aventure avec Sharepoint !

On a pu passer 2 étapes cruciales pour jouer avec Sharepoint Online :

Après quelques jours d'utilisation, il s'avère que les cookies d'authentification ne sont plus valables. C'est un gros problème car c'est pénible de les récupérer manuellement pour ensuite les injecter dans le fichier de configuration Davfs.

J'ai planché quelques heures sur une solution : réaliser le parcours de connexion d'un utilisateur qui passerait par un navigateur web.

Le projet est libre et voici comment l'installer et l'utiliser.

Note : il faut avoir NodeJS sur sa machine. J'ai développé le code en version 6.13.0.

Il faudra déclarer 3 variables d'environnement contenant le site Sharepoint, l'identifiant de connexion et le mot de passe :

Il ne reste plus qu'à lancer le script qui devrait vous retourner du JSON avec les 2 cookies dedans :

À vous de choisir la méthode pour alimenter la configuration de Davfs avec ces données !


Sharepoint Office365 sur Linux (Webdav/Davfs) avec des fichiers accentués

Suite de l'aventure avec Sharepoint !

Je me suis rendu compte que les répertoires et les fichiers nommés avec des accents ne sont pas montés par Davfs. Le problème vient bien sur de Microsoft qui n'est pas foutu d'implémenter un protocole en suivant les standards ! Le support technique est une vraie plaie et ne veut pas comprendre que le problème vient de chez eux…

En effet, les spécifications WebDAV indiquent que les caractères spéciaux (espace compris) doivent être encodés en %XXX. Par exemple, on doit retrouver %C3%A9 à la place de é. Or, Sharepoint ne remplace que les espaces (%20). Voici une partie de la réponse HTTP formée par Sharepoint pour un fichier nommé "éducation.pdf" :

<D:href>https://foo.sharepoint.com/sites/bar/Documents%20partages/éducation.pdf</D:href>

Alors que ça devrait être sous cette forme :

<D:href>https://foo.sharepoint.com/sites/bar/Documents%20partages/%C3%A9ducation.pdf</D:href>

Du coup, j'ai du travaillé sur un correctif et voici une POC qui corrige le problème. Elle consiste à faire passer les requêtes HTTP de DavFS à travers un proxy qui fera le boulot de Sharepoint : encoder les caractères en question !

Je travaille sur ma machine de dev dans ~/www/repo/sharepoint-webdav-proxy.

J'ai choisi le proxy mitmproxy car on peut modifier les requêtes et les réponses à la volé.

Les binaires de mitmproxy sont placés dans ./bin/. Si vous lancez une première fois bin/mitmproxy, des certificats SSL seront créés dans ~/.mitmproxy/.

Configuration de DavFS :

$ sudo cp ~simon/.mitmproxy/mitmproxy-ca-cert.pem /etc/davfs2/certs/

Dans /etc/davfs2/davfs2.conf, j'ai ajouté :

[/mnt/sharepoint/]
proxy 127.0.0.1:8118
trust_ca_cert /etc/davfs2/certs/mitmproxy-ca-cert.pem
use_proxy 1
[...]

Adapteur WebDAV :

Dans src/webdav-adapter.py :

Edit : la version colorée affiche mal certain caractères. Consulter la version texte.

Lancement du proxy :

./bin/mitmdump --mode regular --listen-host 127.0.0.1 --listen-port 8118 -s ./src/webdav-adapter.py

Une fois tout ça réalisé, mount.davfs va pouvoir monter les répertoires/fichiers accentués.


Monter un partage Sharepoint Office365 sur Linux (Webdav/Davfs)

Dans le cadre de mon travail, je développe une application web (nommée Tools) qui fait office de boite à outils pour le groupe Zenitude. L'idée de l'application est de fournir un ensemble d'outils pour faciliter le travail de mes collaborateurs.

Parmi la flopée de fonctionnalités, on trouve des interfaces qui affichent des données récupérées depuis des fichiers Excel. Elles sont analysées et mises en page par l'application (graphiques et tableaux).

Ces fichiers sont initialement déposés sur un espace collaboratif Sharepoint délivré par Office365. J'avais pour objectif de travailler avec les API de Microsoft mais c'est un véritable calvère. C'est mal documenté et le support technique de premier niveau est complètement naze. Du coup, je me suis résolu à faire des formulaires pour déposer les fichiers manuellement.

Pour éviter d'avoir des formulaires d'upload de fichier, je souhaite monter le partage Sharepoint sur le serveur afin d'accéder, en quasi temps réel, au contenu des fichiers qui m'intéressent. Microsoft fournit OneDrive qui est un outil de synchronisation pour monter le partage Sharepoint sur son ordinateur mais seul Microsoft Windows et IOS sont supportés. Il s'appuie sur le protocole WebDAV mais authentifie les utilisateurs avec le protocole OAuth2.

Sous Linux, davfs2 permet de faire des montages WebDAV dans son système de fichiers. La problématique d'authentification via OAuth2 est réelle car impossible de passer un couple login/mot de passe classique. Une solution existe et consiste à récupérer des cookies générés après l'authentification OAuth2 via un navigateur et indiquer à davfs2 de les injecter dans les requêtes HTTP WebDAV.

Pour des questions de sécurité, j'ai ajouté à l'organisation Office365 un compte utilisateur qui, par défaut, ne peut lire que les fichiers du partage. Lorsque que je me connecte à Office365 via un navigateur web en utilisant ce compte, 2 cookies sont créés : rtFa et FedAuth. Il faut conserver leur valeur respective car nous en auront besoin pour configurer le montage.

On va installer le driver davfs2 pour réaliser le montage :

# aptitude install davfs2

Je décide que le point de montage sera dans /mnt/sharepoint. Dans /etc/davfs2/davfs2.conf, on indique à davfs2 d'ajouter les cookies. Il faut bien évidement remplacer XXXXXX et YYYYYY par ce que vous avez récupéré :

[/mnt/sharepoint/]
ask_auth 0
add_header Cookie rtFa=XXXXXX;FedAuth=YYYYYY

Il reste maintenant à faire le montage :

# mount.davfs -o ro "https://foo.sharepoint.com/bar/Documents partages" /mnt/sharepoint

Si tout se passe bien, vous devrier avoir le montage fonctionnel. Ça ne sera pas détaillé ici mais vous pouvez maintenant affiner la configuration, faire du cache sur les fichiers, gérer les permissions plus finement, passer par /etc/fstab pour automatiser le montage, etc.


[Astuce] i3wm : liste des processus les plus actifs

Quand j'utilisais conky, l'un de mes objectifs était de connaître la liste des processus les plus actifs. En effet, il n'était pas rare (et ça continue aujourd'hui) qu'un programme s'affole un peu en mangeant un peu trop de ressources. Mon passage à i3-wm m'a légitiment fait abandonner conky puisque j'ai toujours une fenêtre affichée en plein écran. Du coup, j'ai décidé d'ajouter une barre qui s'affiche uniquement quand j’appuie sur une touche.

Voici un aperçu : i3-wm : barre de processus

Le code source du script est en shell :

#!/bin/sh                                          

echo "{\"version\":1}"

INFO='#E9F1FF'
NORMAL='#B3FF6C'
WARNING='#FF6836'
CRITICAL='#FF474A'

echo "[[]"

while true; do
	(
		echo -n ",["
		
		ps ux --sort -%cpu | head -n 30 | sed 's/\s\{2,\}/ /g' | cut -d" " -f3,11 | uniq | grep -v uniq | egrep -v '^0.0' | egrep '^[0-9.]* [a-z]' | while read cpu bin; do
			if [ $(echo "if (${cpu} < 3 ) 1 else 0" | bc) -eq 1 ]; then
				COLOR=$INFO
			elif [ $(echo "if (${cpu} < 40.0 ) 1 else 0" | bc) -eq 1 ]; then
				COLOR=$NORMAL
			elif [ $(echo "if (${cpu} < 70.0 ) 1 else 0" | bc) -eq 1 ]; then
				COLOR=$WARNING
			else
				COLOR=$CRITICAL
			fi
			echo -n "{\"full_text\": \" $bin ($cpu%) \", \"color\": \"$COLOR\"}," 
		done
		
		echo "]"
	) | sed 's/,\]/]/'
		
	sleep 5
done

Au niveau de la conf de i3, voila comment j'ai procédé :

bar {
    status_command /chemin/vers/le/script
    workspace_buttons yes
    position top
    tray_output none
    mode hide
    modifier mod1

    /* d'autres confs */    
}

That's all folks!


Installer un serveur Sync (Firefox) à la maison

Dans ma conquête vers auto-suffisance et pour écarter encore plus mes données persos des USA, j'ai décidé d'installer mon propre serveur de synchronisation pour Firefox.

Pour rappel, Firefox permet de synchroniser vos terminaux par le biais d'une fonction "Sync". Ainsi vous concervez les mêmes marque-pages, historique, modules complémentaires, etc. entre les différents terminaux que vous manipulez.

Par défaut, ce sont sur des serveurs à Mozilla où les données sont enregistrées. Elles sont évidément chiffrées mais stockées on ne sait pas trop où....enfin si, aux USA. Certains diront que tant que c'est chiffré, on s'en fiche vers où elles partent et c'est à moitié vraie. Cependant, le jour où l'ago de chiffrement sera cassé, ces données aujourd'hui indéchiffrables le deviendront et je préfère les savoir chez moi.

Comment installer son propre serveur Sync ? C'est très simple et voici les étapes de configuration.

Voici mes contraintes :

  • Un domaine dédié (sync.deblan.org)
  • Transactions HTTP chiffrées (HTTPS)

Pour rappel, je travail sur Debian et j'ai déjà un serveur web Apache installé.

Étape 1 : installation des paquets nécessaires
$ su - 
# aptitude update
# aptitude install python-dev mercurial sqlite3 python-virtualenv libssl-dev libapache2-mod-wsgi
# aptitude clean
# a2enmod wsgi
# service apache2 restart
Étape 2 : installation de Sync server

Dans ma procédure de création de vhost pour Apache, je génère systématiquement un nouvel utiliseur unix. Dans le cas de Sync, il s'appel "websync". Son répertoire personnel est chez moi : "/services/web/www/sync.deblan.org".

# su - websync
$ mkdir public_html logs databases
$ chmod 700 logs databases
$ hg clone https://hg.mozilla.org/services/server-full
$ cd server-full
$ make build
Étape 3 : configuration de Sync server

Dans le répertoire server-full/" se trouve un fichier "development.ini". Éditez-le et ajoutez ces informations. Ici je vais conserver SQLite pour enregistrer les données.

# De base, Sync server permet à n'importe qui de s'inscrire pour synchroniser ses données.
# Vous pouvez activez un Captcha pour bloquer les bots
# Passez simplement use à true
[captcha]
use = false
public_key = 6Le8OLwSAAAAAK-wkjNPBtHD4Iv50moNFANIalJL
private_key = 6Le8OLwSAAAAAEKoqfc-DmoF4HNswD7RNdGwxRij
use_ssl = true

[storage]
backend = syncstorage.storage.sql.SQLStorage
# À modifier selon vos répertoires
sqluri = sqlite:////services/web/www/sync.deblan.org/databases/storage.db
standard_collections = false
use_quota = true
# Un quota de 25Mo : par défaut à 5Mo
quota_size = 25120
pool_size = 100
pool_recycle = 3600
reset_on_return = true
display_config = true
create_tables = true

[auth]
backend = services.user.sql.SQLUser
# À modifier selon vos répertoires
sqluri = sqlite:////services/web/www/sync.deblan.org/databases/auth.db
create_tables = true
pool_size = 100
pool_recycle = 3600
create_tables = true
# Décommentez la ligne suivante pour ne pas autoriser d'inscription.
# Note : il est nécessaire des les autoriser le temps d'ajouter votre compte
# allow_new_users = false

[nodes]
# Nécessaire pour que ça puisse fonctionner...
fallback_node = https://sync.deblan.org/

[smtp]
host = localhost
port = 25
sender = no-reply@deblan.fr

[cef]
use = true
file = syslog
vendor = mozilla
version = 0
device_version = 1.3
product = weave

[reset_codes]
backend = services.resetcodes.rc_sql.ResetCodeSQL
# À modifier selon vos répertoires
sqluri = sqlite:////services/web/www/sync.deblan.org/databases/reset.db
create_tables = True
Étape 4 : configuration d'Apache

Dans ce Vhost, j'utilise le module WSGI (pour jouer avec Python) mais également Suexec pour ma politique de sécurité. J'ai également des certificats SSL qui ne sont pas ceux par défaut. Il ne faut donc pas faire un "bête" copié/collé car ça ne va pas fonctionner.

# cat /etc/apache2/sites-available/sync.deblan.org.443 
<IfModule mod_ssl.c>
<VirtualHost *:443>
	# À modifier
	ServerName sync.deblan.org
	# À modifier (public_html est un répertoire vide)
	# /var/www/service-web/www/ == /services/web/www/ (contraintes php-fastcgi)
	# @see http://www.deblan.tv/post/407/Serveur-web-Debian-Apache2-et-FastCGI
	DocumentRoot /var/www/service-web/www/sync.deblan.org/public_html
	SuexecUserGroup websync webgroup
	ErrorLog /services/web/logs/sync.deblan.org.log
	CustomLog /services/web/logs/sync.deblan.org.log combined
	CustomLog /services/web/logs/sync.deblan.org.log trafic

	WSGIProcessGroup sync
	# Modifier "websync" selon le user créé pour l'occasion
	WSGIDaemonProcess sync user=websync group=websync processes=2 threads=25
	WSGIPassAuthorization On
	# À modifier selon vos répertoires
	WSGIScriptAlias / /services/web/www/sync.deblan.org/server-full/sync.wsgi

	# À modifier selon vos répertoires
	<Directory /var/www/service-web/www/sync.deblan.org>
		Options -Indexes SymLinksIfOwnerMatch MultiViews
		AllowOverride All
		Order allow,deny
		allow from all
		Options +ExecCGI
	</Directory>

	# Ne fonctionnera pas tel quel chez vous
	SSLEngine on
	SSLCertificateFile    /etc/apache2/ssl/deblan/org/deblanorg.crt
	SSLCertificateKeyFile /etc/apache2/ssl/deblan/org/deblanorg.key
	SSLCACertificateFile  /etc/apache2/ssl/deblan/org/GandiStandardSSLCA.pem

	BrowserMatch MSIE [2-6] \
		nokeepalive ssl-unclean-shutdown \
		downgrade-1.0 force-response-1.0
	BrowserMatch MSIE [17-9] ssl-unclean-shutdown
</VirtualHost>
</IfModule>
# a2ensite sync.deblan.org.443
# service apache2 reload

Il ne reste plus qu'à supprimer et recréer un compte Sync en spécifiant que vous utilisez un serveur personnel. Si tout se passe bien, les bases de données SQLite vont être générées. En cas de problème, il "suffira" de regarder ce que les logs racontent coté serveur et de regarder ceux présents chez vous via : about:sync-log.