Service Proxy de base de données (server)

{{#images:versionlatest-32x32.png|stock}}

Le service proxy de base de données permet d'accéder aux bases de données à travers le service Sage FRP 1000.

Le service proxy de base de données est utile lorsque les bases de données ne peuvent pas être exposées, par exemple dans un environnement hébergé Web.

Le service proxy est basée sur une interface REST

Service URL.

Le service proxy est accessible à travers l'url de base du service :

 https://hostname/service/sql

Ressources URI.

Une ressource à un type et un identifiant, le type est utilisé dans la signature, l'identifiant dans l'URI.

Les identifiants de ressources :

 /databaseType/uriID

Entête de requête.

Les requêtes HTTP doivent contenir les entêtes suivantes :

Entête	Valeur
x-ms-version	Version de service proxy
x-ms-date	Heurodatage de la requête
Authorization	Doit contenir un token de signature de la requête.
ContentType	Définit le type de contenu de la requête
Accept	Définit le type de contenu de la réponse
Cookie	Doit contenir le cookie de session de l'utilisateur

Authentification de l'utilisateur.

Il existe deux méthodes pour authentifier l'utilisateur :

• Utiliser une connexion de service a travers l'api sdata $connect
• Utiliser le dialogue standard de connexion de l'utilisateur

La méthode utilisant le dialogue standard est préférable parce qu'elle gère l'ensemble des paramètres d'authentification.

Dans les deux cas vous devez obtenir en fin d'authentification le cookie de session de l'utilisateur.

Authentification en utilisant $connect

L'authentification par la méthode $connect permet de retrouver directement le SID de la session.

Authentification en utilisant le dialogue Web d'authentification

Le dialogue standard d'authentification de l'utilisateur peut être appelé à l'url suivante :

 https://domaine/service/server/connect.l1000?cburl=url_redirect_success

Par défaut le dialogue standard retourne le SID de la session dans un cookie ayant l'attribut "httponly", de ce fait il n'est pas possible de récupérer en dehors du contexte html.

Pour obtenir le cookie de session, il faut exécuter l'url de service retournant les informations de session en passant un paramètre "returnSID=1"

Pour ce faire :

A la fin de la procédure d'authentification le dialogue navigue sur l'url passée en paramètre (url_redirect_url).

Cette url doit être interceptée et redirigée sur url suivante :

 https://domaine/service/server/rpc.l1000/info.context?returnSID=1

Dans la réponse du serveur, le SID est présent dans l'élement <SIDC>.

Ce SID est crypté 3des par la clé de chiffrement de l'application et encodé en base 64.

Authentification de l'application.

L'application appelante doit être authentifiée et autorisée, elle doit être enregistrée en tant d'application de service.

L'enregistrement d'une application fournit deux valeurs :

• Un identifiant d'application, par exemple "infineo"
• Une clé de chiffrement symétrique

Ces identifiants doivent être utilisés dans la signature des requêtes.

Fichier:Application-de-service-1.png

Signature des requêtes.

Les requêtes HTTP émises sur le service proxy doivent être signée, le résultat de la signature est formaté dans un token qui doit être passé dans l'entête Authorization de la requête.

La méthode de signature des requêtes est basé sur Access control on DocumentDB resources

Cette méthode est décrite ainsi :

• Un payload est construit à partir des informations de la requête
• Ce payload est signé avec la clé de chiffrement de l'application
• Un jeton encapsule la signature
• Ce jeton est passé dans l'entête Authorization de la requête

Le code de signature et de construction du jeton est le suivant :

function TSage1000ApplicationKey.Sign(const iVerb,iResourceType,iResourceID:string; iHeaderDate:TDatetime):string;
begin
  (*
  payLoad to sign
  1. VERB.toLowerCase() + "\n" +
  2. ResourceType.toLowerCase() + "\n" +
  3. ResourceId + "\n" +
  4. (headers["x-ms-date"] || "").toLowerCase() + "\n" +
  5. (headers["date"] || "").toLowerCase() + "\n";
  resourceType ==  "dbs", "colls", "docs"
  x-ms-date is the UTC date and time the message was sent (in "HTTP-date" format as defined by RFC 7231 Date/Time Formats) e.g. Tue, 15 Nov 1994 08:12:31 GMT.
  *)

  lastPayLoad := lowerCase(iVerb)+#10+lowerCase(iResourceType)+#10+iResourceID+#10+lowerCase(LocalDateTimeToGMT(iHeaderDate))+#10#10;
  lastSign := THMACUtils<TIdHMACSHA256>.HMAC_KeyBase64_Base64(KeyValue, lastPayLoad);

  lastToken := Format('type=%s&ver=1.0&sig=%s',[KeyName,lastSign]);
  Result := HTTPEncode(lastToken);
end;

Code de retour

Code	Usage

Type de contenu de la réponse

Les requêtes peuvent renvoyer les données en format XML ou JSON.

Curseurs

Les requêtes de type curseur exécute un select sur une base de données et retourne les données en résultat.

Les types de ressource URI utilisés par un curseur :

Type	Usage
open	Ouverture du curseur
next	valeurs suivantes
close	Fermeture du curseur