« Service Proxy de base de données (server) » : différence entre les versions
| Ligne 189 : | Ligne 189 : | ||
|} | |} | ||
===Type de contenu de la réponse=== | ===Type de contenu de la réponse (XML)=== | ||
Les | Les réponses au format XML respectent le schéma suivant : | ||
<pre> | |||
<?xml version="1.0" encoding="UTF-8"?> | |||
<result eof="1"> | |||
<columns> | |||
<c id="0" type="column_type" len="column_length">column_name</c> | |||
... | |||
</columns> | |||
<rows> | |||
<r> | |||
<v id="0" null="1" blob="1">value</v> | |||
... | |||
</r> | |||
.... | |||
</rows> | |||
</result> | |||
</pre> | |||
Si les attributs de type boolean sont présent (Ex: eof,null,blob...) leur valeur est 1, ils sont absent si leur valeur est False. | |||
Column_type est le type de l'attribut Sage 1000 | |||
{|class="wikitable" | |||
|- | |||
!Type Sage 1000 | |||
|Type SQL Server | |||
|} | |||
===Curseurs=== | ===Curseurs=== | ||
Version du 28 décembre 2016 à 12:24
{{#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.
Ce est utile lorsque les bases de données ne peuvent pas être exposées, par exemple dans un environnement hébergé Web.
L'interface duservice 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 | Usage | Valeur |
|---|---|---|
| x-ms-version | Version de service proxy | 2017-01-01 |
| x-ms-date | Heurodatage de la requête | Example, Tue, 13 Dec 2016 08:35:12 GMT |
| Authorization | Doit contenir un token de signature de la requête. | Example, type%3DInfineo%26ver%3D1.0%26sig%3DUoJIc0H4RlcUn3Jme53QUNR2cVAnlawVX52pEDD%2BBaI%3D |
| ContentType | Définit le type de contenu de la requête | application/sql |
| Accept | Définit le type de contenu de la réponse | application/xml |
| Cookie | Doit contenir le cookie de session de l'utilisateur | Example, SID=208393202-5A950A00000003........ |
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 |
|---|---|
| 500 | Bad request |
| 501 | Not implemented |
| 401 | Unautorized |
| 403 | Forbidden |
| 200 | OK |
Type de contenu de la réponse (XML)
Les réponses au format XML respectent le schéma suivant :
<?xml version="1.0" encoding="UTF-8"?> <result eof="1"> <columns> <c id="0" type="column_type" len="column_length">column_name</c> ... </columns> <rows> <r> <v id="0" null="1" blob="1">value</v> ... </r> .... </rows> </result>
Si les attributs de type boolean sont présent (Ex: eof,null,blob...) leur valeur est 1, ils sont absent si leur valeur est False.
Column_type est le type de l'attribut Sage 1000
| Type Sage 1000 | Type SQL Server |
|---|
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 |