lib
: le code de votre applicationlib/models
: la partie métier de votre applicationviews
: les différentes vues (templates) de votre applicationviews/layout.erb
: exemple de layout, utilisant la librairie CSS Twitter Bootstrapexamples
: des exemples listés dans cette documentationspec
: spécifications rspec de votre applicationdb
: tout ce qui concerne la base de données (configuration, migrations)app.rb
: le fichier de lancement de l'application.demo.rb
: application de démonstrationGemfile
: spécification des librairies utilisées
sudo apt-get install libpq-dev # pour la gem pq
bundle install # installation des gems
ruby demo.rb # lance l'application sur http://localhost:4567
Nous allons considérer 2 types d'authentifications possibles:
- authentification pour API Rest
- authentification pour interface web
Une API Rest doit être sans état, ce qui implique de ne pas gérer de session. Le client doit donc soumettre ses identifiants à chaque connexion.
Pour authentifier les appels par API, nous allons utiliser l'authentification
HTTP
Basic
qui utilise l'entête Authorization
.
Vous trouverez un exemple de code dans
examples/http_basic.rb
.
Pour gérer l'authentification, nous allons utiliser un service externe. Le
middleware Rack omniauth
permet de manière
souple l'utilisation de plusieurs sources d'authentification.
Il faut d'abord configurer omniauth
en installant et configurant les
librairies spécifiques aux fournisseurs d'authentification (twitter, facebook,
google …).
Quel que soit le fournisseur d'authentification, l'utilisation est :
GET '/auth/:provider'
Le navigateur de l'utilisateur est redirigé vers le service d'authentification designé par:provider
, qui se charge d'authentifier l'utilisateur.- Le service redirige ensuite le navigateur vers
/auth/:provider/callback
. La libraire omniauth remplitrequest.env['omniauth.auth']
avec des informations représentant l'utilisateur, telle que l'email, le nom, et d'autres informations que vous trouverez dans la spécification du hash renvoyé par omniauth. En cas d'échec de l'authentification, le service redirige le navigateur versauth/failure
. - À vous de jouer pour faire quelque chose de ces informations, par exemple:
- créer un utilisateur dans une base de données
- positionner dans la session une variable pour se souvenir que l'utilisateur s'est authentifié
Vous trouverez un exemple d'utilisation dans authentication.rb
et demo.rb
.
Dans certains cas, l'utilisation de l'entête Accept
ne suffit pas à distinguer
les appels pour l'interface web des appels API.
Le cas classique est la génération de html (donc Accept: text/html
), avec :
- un document HTML complet pour l'interface web (layout + contenu)
- un fragment HTML pour l'API (juste le contenu sans enrobage).
Dans ce cas, il faut utiliser un autre entête :
- les clients javascripts positionnent fréquemment l'entête non standard
X-Requested-With: XMLHttpRequest
. L'usage est tellemente courant queRack::Request#xhr?
existe. - si votre API nécessite une authentification HTTP Basic, vous pouvez vérifier
la présence de l'entête
Authorization
.
Dans votre code, request.xhr?
vaudra true
si l'entête est positionné.
Pour séparer les cas authentifié/non authentifié dans les spécifications avec
rspec
, on utilise un stub sur la méthode current_user
.
Vous trouverez un exemple dans spec/app_spec.rb
.
# encoding: utf-8
Notez que la version 2.0 de ruby en fait un réglage par défaut.
Test, développement, production
export RACK_ENV = test | production | development
L'environnement par défaut est development
.
rake -T db
va vous lister les tâches disponibles pour gérer vos bases de
données.
Les tâches s'appliquent dans l'environnement courant, ou development
par
défaut.
rake db:new_migration name=do_this
Cette commande génère le fichier db/migrate/YYYMMDDHHMMSS_do_this.rb
dans le
répertoire db/migrate
(YYYMMDDHHMMSS
: date au format année mois jour heure minute seconde).
rake db:migrate
Regarder du côté de sintra-contrib : http://www.sinatrarb.com/contrib/ en particulier :
L'application demo.rb
fournit un exemple d'utilisation de ces 3 modules.
Le principe est de faire générer au navigateur une requête POST avec un paramètre indiquant le type de requête HTTP souhaitée.
<form action="…" method="POST">
<input type="hidden" name="_method" value="PUT/DELETE"/>
…
<input type="submit" name="submit" value="ok"/>
</form>
Le middleware
Rack::MethodOverride
implémente le changement de requête: si une requête de type POST est reçue avec
le paramètre _method
, alors le type de requête est changé pour la valeur du
paramètre _method
.
Pour utiliser ce middelware, il faut dans Sinatra faire :
enable :method_override # activé par défaut
Vous trouverez un exemple démontrant ce mécanisme dans
examples/method_override.rb
Heroku est une solution de PaaS.
Installation des outils heroku
wget -qO- https://toolbelt.heroku.com/install-ubuntu.sh | sh
Se créer un compte sur heroku.com et s'authentifier localement.
heroku login
Enter your heroku credentials
Email: [email protected]
Password:
Could not find an existing public key.
Would you like to generate one? [Yn]
Generating new SSH public key.
Uploading ssh public key /Users/adam/.ssh/id_rsa.pub
cd sinatra-skeleton
heroku create
git push heroku master
heroku run db:migrate
La base de données est indiquée dans l'environnement d'excution dans la plateforme fournie.
heroku run bash # ouvre un shell sur la plateforme distante
env # regarder
heroku open