Transfert de fichiers PC et ODBC

droit
aux utilisateurs sur les données ; par
conséquent, les applications serveur
renverront des messages d’échec « not
authorized ».

J’ai d’abord essayé d’utiliser des
programmes de sortie pour adopter
l’autorité du propriétaire de l’objet.
Mais quand les programmes de sortie
rendent le contrôle, ils abandonnent
aussi l’autorité adoptée et donc le serveur
continuait à  échouer avec le message
« not authorized ».

Voyant que l’adoption du programme
ne fonctionnait pas, j’ai décidé
d’essayer la permutation du profil
utilisateur. Le programme de sortie
peut appeler un programme semblable
à  celui de la figure 2. Ce programme
peut être utilisé pour changer le profil
utilisateur pour le job serveur en un
profil utilisateur propriétaire d’objet
ayant, lui, des droits sur les données.

Pour l’accès ODBC, l’interface
CALL peut être utilisée pour invoquer
directement le programme pour permuter
les profils utilisateur. Pour les
opérations de transfert de fichiers, la
permutation doit être appelée à  partir
des programmes de sortie. Utilisez la
commande WRKREGINF (Work with
Registration Information) ou les attributs
de réseau DDMACC ou PCSACC
pour nommer les programmes de sortie
pour les opérations de transfert de
fichiers.

Un problème se pose : comment
faire la distinction entre une application
trusted qui doit être autorisée à 
permuter pour l’accès, et une requête
non autorisée de la part d’un utilisateur.
Comme la requête émane d’un
programme PC, il est impossible de
faire la distinction entre les applications
autorisées et non autorisées.

La meilleure solution que j’ai trouvée
consiste à  utiliser une méthode
d’authentification supplémentaire,
comme une requête préalable émise
en envoyant un message à  une file d’attente
de données avec une information
d’authentification spécifique. Bien
qu’elle ne soit pas sûre à  100 %, c’est la
meilleure solution que j’ai pu appliquer.