Modifications entre les versions 5 et 11 (s'étendant sur 6 versions)
Version 5 à la date du 2010-03-26 15:20:40
Taille: 2923
Éditeur: CyrilRobert
Commentaire:
Version 11 à la date du 2010-08-05 15:16:01
Taille: 5151
Éditeur: CyrilRobert
Commentaire:
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
'''Page en cours de réécriture'''

## page was renamed from Python/AuthentificationROA
Ligne 3: Ligne 6:
= ROA =
= Concept =
Ligne 7: Ligne 11:
La couche HTTP utilise un API [[http://en.wikipedia.org/wiki/Representational_State_Transfer|REST]], et donc peut être consulté facilement depuis nimporte quel environnement.
Ligne 8: Ligne 13:
= Authentification = En plus de l'accès direct aux objets et aux collections, on peut ajouter des paramètres GET pour réstreindre la réponse. Ces paramètres sont les mêmes que pour les querysets, par exemple:
{{{
GET /roa/utilisateurs/?filter_email__contains=auf.org
}}}
Ligne 10: Ligne 18:
Un système d'authentification centralisé utilisant django-roa est en ce moment en essai sur certains systèmes à Montréal (ex. http://pypi.auf.org/). = Clients =
Ligne 12: Ligne 20:
Voir le projet sur [[https://redmine.auf.org/projects/roa-authentification|redmine]]. == Client django ==
Ligne 14: Ligne 22:
== Service == Pour faciliter l'utilisation du système de réferences avec Django, un paquet est installable depuis notre serveur [[Python/DépôtPypi|Pypi]]: [[http://pypi.auf.org/auf_references_client/|auf_references_client]]. En plus de ce paquet, il existe [[http://pypi.auf.org/auf_references_modeles/|auf_references_modeles]], qui est utilisé aussi bien par le serveur que le client.
Ligne 16: Ligne 24:
Le service a été installé sur authentification.auf.org. L'application en arrière est sur git, [[http://git.auf.org/?p=auf_roa_authentification.git;a=tree|auf_roa_authentification]]. === Ajout de la dépendance ===
Ligne 18: Ligne 26:
La première étape pour utiliser réferences est d'ajouter le client comme dépendance dans `buildout.cfg`, par exemple:
{{{
[buildout]
parts = django
find-links = http://pypi.auf.org/django-roa/
    http://pypi.auf.org/auf_references_client/
    http://pypi.auf.org/auf_references_modeles/
Ligne 19: Ligne 34:
== Clients == [django]
recipe = djangorecipe
version = 1.1.1
project = auf_ninja
wsgi=true
settings=production
extra-paths = auf_ninja
eggs = django_exportateur
       auf_references_client
}}}
'''Note''': auf_references_modeles doit figurer dans `find-links`, mais il n'est pas obligatoire dans `eggs`.
'''Avertissement''': Il faut à tout prix que django-roa soit pris depuis notre pypi, il comporte plusieurs changements nécessaires au bon fonctionnement du système.
Ligne 21: Ligne 47:
=== Django ===

Pour nimporte quelle application Django souhaitant utiliser ce système, un backend existe: [[http://git.auf.org/?p=auf_roa_authentification_backend.git;a=tree|auf_roa_authentification_backend]]. Il est publié sur le pypi de l'AUF, donc dans le cas d'un buildout, on peut simplement l'ajouter dans la section ''eggs''.

Ce backend nécessite plusieures options de configuration:
Il faut ensuite modifier `settings.py` pour activer et configurer le client:
Ligne 29: Ligne 51:
    'auf_roa_authentification_backend',
Ligne 32: Ligne 53:
AUTHENTICATION_BACKENDS = (
    'auf_roa_authentification_backend.backends.CascadeBackend',
)
AUTH_PASSWORD_REQUIRED=True
ROA_MODELS = True # set to False if you'd like to develop/test locally
ROA_FORMAT = 'django'
ROA_HEADERS = {
    'Content-Type': 'application/x-www-form-urlencoded',
}
ROA_DJANGO_ERRORS = True # useful to ease debugging if you use test server

ROA_BASE_URL = 'https://authentification.auf.org/auth/'
Ligne 45: Ligne 54:

SERIALIZATION_MODULES = {
    'django' : 'auf_roa_authentification_backend.serializers',
}
from auf_references_client.settings import *
TEMPLATE_DIRS.extend(REFERENCES_TEMPLATE_DIRS)
Ligne 51: Ligne 58:
'''ROA_API_KEY''' doit être défini dans conf.py.
Ligne 53: Ligne 59:
Le backend s'appelle ''Cascade'' puisqu'il va vérifier d'abord par ROA si le compte existe et si le mot de passe est valide. Dans ce cas, il fait une copie locale de compte. Le cas échéant, il va regarder s'il existe un compte local valide, ce qui nous permet de valider les comptes de l'AUF automatiquement, mais aussi de pouvoir avoir des utilisateurs locaux, au cas ou ce serait nécessaire. === API_KEY ===

Tous les clients de `references` doivent s'identifier en fournissant une API-KEY, il faut en demander une au responsable du système, en précisant quel est le client, quelles opérations il a besoin de faire, et sur quels objets, et s'il s'agit d'une clé de test ou de production.
Ligne 56: Ligne 64:
=== Autres === === Objets ===
Ligne 58: Ligne 66:
Le service d'authentification est suffisamment souple pour pouvoir être utilisé dans d'autres contextes que Django. Le client a besoin des choses suivantes:
 * Capable de lire et écrire en http
 * Capable de parser du json ou du xml
L'utilisation des objects via `references` se fait de facon transparente:
Ligne 62: Ligne 68:
Par exemple, pour vérifier l'utilisateur ''blabla@auf.org'' en json, il faut charger l'url suivante:
Ligne 64: Ligne 69:
https://authentification.auf.org/auth/user/?filter_email=blabla@auf.org&filter_password=<md5 du mot de passe>&format=json&api-key=<api-key> from auf_references_modeles import Etablissement, Region

ameriques = Region.objects.get(nom_court = 'A')
etablissements = Etablissement.objects.filter(region = ameriques)
Ligne 67: Ligne 75:
Le contenu retourné sera assez explicite: une erreur 404 signifie que l'utilisateur n'existe pas, par exemple.
=== Authentification ===

Un autre besoin du systeme de réference était d'avoir une source unifiée pour vérifier les comptes utilisateurs. Le paquet [[http://pypi.auf.org/auf_references_client/|auf_references_client]] fournit un backend d'authentification pour Django.

Pour activer cette authentification, il faut ajouter les lignes suivantes a `settings.py`:
{{{
AUTHENTICATION_BACKENDS = (
    'auf_references_client.backends.CascadeBackend',
)
AUTH_PASSWORD_REQUIRED = True
}}}

La variable `AUTH_PASSWORD_REQUIRED` peut être mise à `False` si on a besoin de pouvoir tester l'application avec plusieurs comptes utilisateurs.

=== Cache (coté client) ===

L'utilisation de cache est critique pour certains sites, et pour limiter l'utilisation de bande passante. Un système de cache a été ajouté à la version `AUF` de `django-roa`.

Pour l'activer, il faut modifier `MIDDLEWARE_CLASSES` dans `settings.py`:
{{{
MIDDLEWARE_CLASSES = (
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
    ....
}}}
'''Note''': CommonMiddleware devrait déja être présent, les 2 autres sont à ajouter, dans cet ordre.

Ensuite, on peut spécifier le systeme de cache à utiliser, en ajoutant une ligne dans `settings.py`:
{{{
CACHE_BACKEND = 'memcached://localhost:11211/'
}}}

Plus d'informations: [[http://docs.djangoproject.com/en/dev/topics/cache/|django cache]].

== Client manuel ==

En guise d'exemple, une méthode rapide pour vérifier un compte utilisateur:
{{{
    def roa_login (self, email, password):
        rc = None

        api_key = ""
        url = "%s?filter_email=%s&filter_password=%s&format=json&api-key=%s" \
                % (self.auf_roa_url, email, password, api_key)

        try:
            ud = urllib.urlopen (url)
            list = simplejson.load (ud)
            ud.close ()
            rc = list[0]
        except:
            rc = None

        return rc
}}}
'''Note''': Ne pas utiliser cette méthode, la gestion d'erreur est très mauvaise.


= Serveur =

== Restrictions ==

=== API-KEY ===

=== Lister ===


== Ajout d'un modele ==

Page en cours de réécriture

Concept

Le projet django-roa permet de créer un système de sérialisation/dé-sérialisation d'objets en passant par une couche HTTP, tout en maintenant un API compatible avec l'ORM de Django.

La couche HTTP utilise un API REST, et donc peut être consulté facilement depuis nimporte quel environnement.

En plus de l'accès direct aux objets et aux collections, on peut ajouter des paramètres GET pour réstreindre la réponse. Ces paramètres sont les mêmes que pour les querysets, par exemple:

GET /roa/utilisateurs/?filter_email__contains=auf.org 

Clients

Client django

Pour faciliter l'utilisation du système de réferences avec Django, un paquet est installable depuis notre serveur Pypi: auf_references_client. En plus de ce paquet, il existe auf_references_modeles, qui est utilisé aussi bien par le serveur que le client.

Ajout de la dépendance

La première étape pour utiliser réferences est d'ajouter le client comme dépendance dans buildout.cfg, par exemple:

[buildout]
parts = django
find-links = http://pypi.auf.org/django-roa/
    http://pypi.auf.org/auf_references_client/
    http://pypi.auf.org/auf_references_modeles/

[django]
recipe = djangorecipe
version = 1.1.1
project = auf_ninja
wsgi=true
settings=production
extra-paths = auf_ninja
eggs = django_exportateur
       auf_references_client

Note: auf_references_modeles doit figurer dans find-links, mais il n'est pas obligatoire dans eggs. Avertissement: Il faut à tout prix que django-roa soit pris depuis notre pypi, il comporte plusieurs changements nécessaires au bon fonctionnement du système.

Il faut ensuite modifier settings.py pour activer et configurer le client:

INSTALLED_APPS += (
    'django_roa',
)

ROA_CUSTOM_ARGS = {'api-key': ROA_API_KEY}
from auf_references_client.settings import *
TEMPLATE_DIRS.extend(REFERENCES_TEMPLATE_DIRS)

API_KEY

Tous les clients de references doivent s'identifier en fournissant une API-KEY, il faut en demander une au responsable du système, en précisant quel est le client, quelles opérations il a besoin de faire, et sur quels objets, et s'il s'agit d'une clé de test ou de production.

Objets

L'utilisation des objects via references se fait de facon transparente:

from auf_references_modeles import Etablissement, Region

ameriques = Region.objects.get(nom_court = 'A')
etablissements = Etablissement.objects.filter(region = ameriques)

Authentification

Un autre besoin du systeme de réference était d'avoir une source unifiée pour vérifier les comptes utilisateurs. Le paquet auf_references_client fournit un backend d'authentification pour Django.

Pour activer cette authentification, il faut ajouter les lignes suivantes a settings.py:

AUTHENTICATION_BACKENDS = (
    'auf_references_client.backends.CascadeBackend',
)
AUTH_PASSWORD_REQUIRED = True

La variable AUTH_PASSWORD_REQUIRED peut être mise à False si on a besoin de pouvoir tester l'application avec plusieurs comptes utilisateurs.

Cache (coté client)

L'utilisation de cache est critique pour certains sites, et pour limiter l'utilisation de bande passante. Un système de cache a été ajouté à la version AUF de django-roa.

Pour l'activer, il faut modifier MIDDLEWARE_CLASSES dans settings.py:

MIDDLEWARE_CLASSES = (
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
    ....

Note: CommonMiddleware devrait déja être présent, les 2 autres sont à ajouter, dans cet ordre.

Ensuite, on peut spécifier le systeme de cache à utiliser, en ajoutant une ligne dans settings.py:

CACHE_BACKEND = 'memcached://localhost:11211/'

Plus d'informations: django cache.

Client manuel

En guise d'exemple, une méthode rapide pour vérifier un compte utilisateur:

    def roa_login (self, email, password):
        rc = None

        api_key = ""
        url = "%s?filter_email=%s&filter_password=%s&format=json&api-key=%s" \
                % (self.auf_roa_url, email, password, api_key)

        try:
            ud = urllib.urlopen (url)
            list = simplejson.load (ud)
            ud.close ()
            rc = list[0]
        except:
            rc = None

        return rc

Note: Ne pas utiliser cette méthode, la gestion d'erreur est très mauvaise.

Serveur

Restrictions

API-KEY

Lister

Ajout d'un modele

References (dernière édition le 2010-08-11 14:06:20 par CyrilRobert)