« Service Proxy de base de données (server) » : différence entre les versions

De Wiki1000
 
(20 versions intermédiaires par le même utilisateur non affichées)
Ligne 4 : Ligne 4 :
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 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.
Ce 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
L'interface duservice proxy est basée sur une interface REST


===Service URL.===
===Service URL.===
Ligne 12 : Ligne 12 :


<pre>
<pre>
  https://hostname/service/sql
  https://domain/service/sql
</pre>
</pre>
*domaine
:Domaine du service
*service
:Service Sage 1000 du service.


===Ressources URI.===
===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 :
Les identifiants de ressources :


<pre>
<pre>
  /databaseType/uriType
  /databaseType/uriID
</pre>
</pre>


Ligne 28 : Ligne 36 :
|-
|-
!Entête
!Entête
!Usage
!Valeur
!Valeur
|-
|-
|x-ms-version
|x-ms-version
|Version de service proxy
|Version de service proxy
|2017-01-01
|-
|-
|x-ms-date
|x-ms-date
|Heurodatage de la requête
|Heurodatage de la requête
|Example, Tue, 13 Dec 2016 08:35:12 GMT
|-
|-
|Authorization
|Authorization
|Doit contenir un token de signature de la requête.
|Doit contenir un token de signature de la requête.
|Example, type%3DInfineo%26ver%3D1.0%26sig%3DUoJIc0H4RlcUn3Jme53QUNR2cVAnlawVX52pEDD%2BBaI%3D
|-
|-
|ContentType
|ContentType
|Définit le type de contenu de la requête
|Définit le type de contenu de la requête
|application/sql
|-
|-
|Accept
|Accept
|Définit le type de contenu de la réponse
|Définit le type de contenu de la réponse
|application/xml
|-
|Accept-Encoding
|Définit le type d'encoding de la réponse
|gzip
|-
|-
|Cookie
|Cookie
|Doit contenir le cookie de session de l'utilisateur
|Doit contenir le cookie de session de l'utilisateur
|Example, SID=208393202-5A950A00000003........
|}
|}


Ligne 56 : Ligne 75 :
La méthode utilisant le dialogue standard est préférable parce qu'elle gère l'ensemble des paramètres d'authentification.
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.
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====
====Authentification en utilisant $connect====
L'authentification par la méthode [[Connect_(sdata)|$connect]] permet de retrouver directement le SID de la session.
====Authentification en utilisant le dialogue Web d'authentification====
====Authentification en utilisant le dialogue Web d'authentification====
Le dialogue standard d'authentification de l'utilisateur peut être appelé à l'url suivante :
Le dialogue standard d'authentification de l'utilisateur peut être appelé à l'url suivante :
Ligne 68 : Ligne 89 :
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.  
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écutée une url de service interrogeant retournant les informations de session en passant un paramètre "returnSID=1"  
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).
A la fin de la procédure d'authentification le dialogue navigue sur l'url passée en paramètre (url_redirect_url).
Ligne 77 : Ligne 100 :
  https://domaine/service/server/rpc.l1000/info.context?returnSID=1
  https://domaine/service/server/rpc.l1000/info.context?returnSID=1
</pre>
</pre>
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.===
===Authentification de l'application.===
Ligne 82 : Ligne 109 :


L'enregistrement d'une application fournit deux valeurs :
L'enregistrement d'une application fournit deux valeurs :
* Un identifiant d'application, par exemple "infineo"
* Un identifiant d'application. (Exemple, Infineo)
* Une clé de chiffrement symétrique  
* 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.
Ces identifiants doivent être utilisés dans la signature des requêtes.
Ligne 90 : Ligne 117 :


===Signature des requêtes.===
===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.  
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 [https://docs.microsoft.com/en-us/rest/api/documentdb/access-control-on-documentdb-resources 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 :
 
<pre>
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;
</pre>
 
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 de retour===
Ligne 97 : Ligne 176 :
!Code
!Code
!Usage
!Usage
|-
|500
|Bad request
|-
|501
|Not implemented
|-
|401
|Unautorized
|-
|403
|Forbidden
|-
|200
|OK
|}
|}


===Type de contenu de la réponse===
===Type de contenu de la réponse (XML)===
Les requêtes peuvent renvoyer les données en format XML ou JSON.
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
|-
|absftUnknown
|
|-
|absftOID
|
|-
|absftOIDChar
|
|-
|absftVarchar
|
|-
|absftInteger
|
|-
|absftFloat
|
|-
|absftCurrency
|
|-
|absftDateTime
|
|-
|absftMemo
|
|-
|absftBinary
|
|-
|absftLongInt
|
|-
|absftNVarchar
|
|-
|absftNMemo
|
|-
|absftBool
|
|-
|absftSmallInt
|
|-
|absftStamp
|
|}


===Curseurs===
===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 ressources 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 :
Les identifiant de ressource URI utilisés par un curseur :


{|class="wikitable"
{|class="wikitable"
|-
|-
!Type
!Type  
!Identifiant
!Usage
!Usage
|-
|-
|cursor
|open
|open
|Ouverture du curseur  
|Ouverture du curseur  
|-
|-
|cursor
|next
|next
|valeurs suivantes
|Valeurs suivantes
|-
|-
|cursor
|close
|close
|Fermeture du curseur
|Fermeture du curseur
Ligne 123 : Ligne 299 :




[[category:Server]]
[[Category:Latest]]
[[Category:Serveur]]

Dernière version du 9 janvier 2017 à 08:20

{{#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://domain/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
Accept-Encoding Définit le type d'encoding de la réponse gzip
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
absftUnknown
absftOID
absftOIDChar
absftVarchar
absftInteger
absftFloat
absftCurrency
absftDateTime
absftMemo
absftBinary
absftLongInt
absftNVarchar
absftNMemo
absftBool
absftSmallInt
absftStamp

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
Récupérée de « http://wiki.sage.fr/index.php?title=Service_Proxy_de_base_de_données_(server)&oldid=11263 »