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://domaine/service/sql

• domaine

Domaine du service

• service

Service Sage 1000 du service.

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 SID de session de l'utilisateur et passé ce SID dans un cookie de session de nom "SID" et posé sur l'url du service ( https://domaine/service )

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. (Exemple, Infineo)
• Une clé de chiffrement symétrique encodée en base 64 (Exemple, 0vGbKhRbJHDKdG8j755r75N1hozxAQGbo2fxzWNMcBc=)

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ées, le résultat de la signature est formaté dans un jeton qui doit être passé dans l'entête Authorization de la requête.

La méthode de signature des requêtes est basée 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;

où

• KeyName

L'identifiant de l'application

• KeyValue

la clé de chiffrement de l'application

• iVerb

Le verbe http utilisé (ex: POST)

• iResourceType

Le type de la ressource. (ex: cursor)

• iResourceID

L'identifiant de la ressource. (ex: open)

• iHeaderDate

L'horodatage utilisé dans l'entête ms-x-date

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 ressources de type curseur exécute un select sur une base de données et retourne les données en résultat.

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

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