L'ajout de SAVON implicite des en-têtes WSDL

Ma question est semblable à cela. Comment Passer d'en-Tête Soap Quand le fichier WSDL N'est pas le Définir? , Mais ils sont différents.

Pour un service web que j'utilise, toutes les méthodes ont besoin d'authentification qui est envoyé en texte clair à l'intérieur d'un en-tête SOAP. Cependant, mon WSDL ne comprennent pas les informations d'en-tête soap. J'ai une plate-forme personnalisée de l'outil que je dois utiliser pour générer le code à partir du fichier WSDL. Depuis l'en-tête info n'est pas disponible, je suis incapable d'utiliser la classe générée directement - je ne veux pas modifier manuellement le code pour accueillir l'en-tête.

J'ai essayé de spécifier l'en-tête SOAP dans le fichier WSDL, mais je n'ai pas réussi à obtenir la bonne espaces de noms. Le WSDL est ici https://stage.totalcheck.sensis.com.au/service/webservice?wsdl et l'en-tête SOAP est comme suit:

    <soapenv:Header>
        <wsse:Security>
            <wsse:UsernameToken>
                <wsse:Username>username</wsse:Username>
                <wsse:Password>password</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
   </soapenv:Header>

Quelqu'un peut m'aider? Merci!

wsse ressemble le préfixe utilisé normalement pour les WS-Security. Aussi, depuis de SAVON services sont destinés à être auto-description, je suis à une perte pour trouver une raison valable pour les en-têtes ne sont pas définis dans le fichier WSDL.
Que c'est agréable. Mais comme je l'ai dit, je ne veux pas toucher à la génération automatique de classe. Je suis juste en modifiant ce seulement pour générer la classe.
Auto-généré classe est une classe partielle. Peut-être vous pouvez ajouter l'en-tête à une autre classe. Il ne change pas lorsque l'auto-fichiers générés sont générés à nouveau.

OriginalL'auteur Vid L | 2011-04-20

  1. 19

    À partir d'un point de vue conceptuel, WSDL n'est pas censé définir les en-têtes. WSDL est seulement pour définir les aspects fonctionnels d'un service, comme les opérations, les messages, la liaison et les points de terminaison. Les Messages et les liaisons de définir la façon dont la charge utile de messages doit être codé et mis en forme.

    Les en-têtes des messages SOAP cependant n'appartiennent pas à la charge utile. Ils sont généralement utilisés pour la configuration de la non-propriétés fonctionnelles d'un SAVON processeur. La sécurité est une non-propriété fonctionnelle. L'aspect fonctionnel de la charge utile n'est pas affectée. Il n'est assurée que la communication est sécurisée et le WS outil de pile, pas de la mise en œuvre des services, doit prendre soin de cela.

    De sorte que la pièce manquante est maintenant un standard qui permet la fixation de certaines exigences non fonctionnelles à WSDL des services, ainsi que des générateurs de code peut dériver automatiquement dont les en-têtes doivent être envoyés et/ou de comprendre afin de répondre à la non-propriété fonctionnelle comme souhaité, sans avoir à traiter manuellement avec des champs d'en-tête. Cette norme existe et est appelé WS-policy. Une stratégie contient généralement un ensemble d'alternatives qui exposent un ensemble d'exigences à la fois, fournisseur et le consommateur devrait être en mesure de remplir. Lorsque deux services sont censés interagir les uns avec les autres, les deux politiques sont prises, et un soi-disant "politique efficace" est calculé. Il définit la commune les exigences non-fonctionnelles. En utilisant cette information, le fournisseur et le consommateur peut configurer eux-mêmes pour ajouter des en-têtes, comme le WS-Security-têtes. WS-SecurityPolicy définit également un ensemble de stratégies qui peuvent être utilisés. WS-PolicyAttachment définit comment ces stratégies peuvent être attachés à un document WSDL.

    Il y a des générateurs de code qui peut traiter avec WS-Politiques, par exemple, de Métro ou de Axis2

    L'élément d'en-tête EST défini dans le fichier wsdl/soap schéma de sorte qu'il serait difficile de dire qu'il n'est pas censé être utilisé: schemas.xmlsoap.org/wsdl/soap Vous pourrait certainement utiliser WS-SecurityPolicy mais c'est tout simplement un autre, quoique de manière plus spécifique, la spécification.
    D'accord, pour une liaison, WSDL spécifie comment certaines parties peuvent être mappés à des en-têtes SOAP. Cependant, je considère que l'utilisation de ce, à partir d'un point de vue conceptuel, une mauvaise pratique, car il les liens de votre WSDL pour les liaisons spécifiques. Je suis d'accord, que la question a aussi été posée pour le SAVON de liaison, en utilisant les en-têtes de liaison est probablement très bien, mais à l'aide de WS-policy est un sondeur de chemin à faire (c'est à dire qu'il exprime la non-fonctionnelle préoccupation "assurez-vous que la demande est authentifié" par rapport à l'envoi des en-têtes spécifiques). Dans le premier cas, le WS-pile sait déjà quoi faire.
    Alors que je suis toujours en désaccord que c'est les "mauvaises pratiques" (daté pourrait être une meilleure évaluation), je ne vois maintenant que vous avez raison sur pointant vers le WS-SecurityPolicy dans ce cas puisque les en-têtes dans les OP sont ceux de WS-Security. +1

    OriginalL'auteur vanto

  2. 4

    Vous pouvez ajouter du savon informations d'en-tête pour les appels de méthode par la décoration de la méthodes de la classe proxy généré à partir du wsdl avec le SoapHeader attribut.

    Par exemple wsdl.exe va générer de la classe de proxy client de Référence.cs pour le service web de référence lors de l' "Ajouter une Référence Web". Dans le lien mentionné ci-dessus https://stage.totalcheck.sensis.com.au/service/webservice?wsdl il y a un message suggestAddress qui se traduira par une méthode dans l'généré de référence.cs client proxy fichier de code lorsque vous ajoutez une référence web à partir de visual studio. Par défaut, lorsque cette méthode est appelée, il n'y aura pas d'en-Tête dans l'enveloppe soap. Pour ajouter un SoapHeader à l'enveloppe de cette demande d'ajouter un [SoapHeader("Security")] attribut vers le haut de la SuggestAddress à la méthode de Référence.cs classe générée, où la "Sécurité" est une classe qui hérite de SoapHeader de la classe de base.

    Exemple pour le dessus de Sécurité requis SoapHeader vous devez créer les classes suivantes,

    public partial class Security : SoapHeader
{
    public UserNameToken UserNameToken { get; set; }
}

public partial class UserNameToken
{
    public string UserName { get; set; }
    public string Password { get; set; }
}

    Alors vous serait décorer la SuggestAddress à la méthode de référence.cs comme suivi,

    [SoapHeader("Security")]
public suggestAddressesResult suggestAddresses([System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] addressSearch search) {
        object[] results = this.Invoke("suggestAddresses", new object[] {search});
        return ((suggestAddressesResult)(results[0]));
    }

    Cela permettra d'assurer que chaque enveloppe créé lors de la méthode suggestAddress est invoquée contient un en-tête de sécurité qui ressemble à celui mentionné ci-dessus,

    <soapenv:Header>
    <wsse:Security>
        <wsse:UsernameToken>
            <wsse:Username>username</wsse:Username>
            <wsse:Password>password</wsse:Password>
        </wsse:UsernameToken>
    </wsse:Security>

    qu'est-ce que suggestAddresses reportez-vous ici? Je ne peux pas inférieur. alors que impementing,. j'ai eu l'Erreur " SoapwbApp.withHeader' ne contient pas une définition pour 'Appeler' et aucune méthode d'extension 'Appeler' acceptant un premier argument de type 'SoapwbApp.withHeader' a pu être trouvé (vous manque une directive using ou une référence d'assembly?)
    La langue qui est-ce?

    OriginalL'auteur Roger

  3. 1

    Clé pour moi à l'aide de cette question pour m'aider à reconnaître (comme l'ont souligné certaines) que les en-têtes en question sont ceux de la norme WS-Security.

    Si votre proxy générer outil est "personnalisé", il semble logique que vous pourriez avoir un interrupteur pour ajouter automatiquement les en-têtes de WS-Security. Toutefois, si vous êtes en utilisant WSDL.exe ("Ajouter une Référence Web" dans Visual Studio), pensez à svcutil.exe à la place ("Ajouter une Référence de Service").

    Si vous utilisez un proxy WCF, vous pouvez remplacer la config et permettre de la WCF pour ajouter des en-têtes pour vous:

    <security mode="TransportWithMessageCredential">
    <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
    <message clientCredentialType="UserName" algorithmSuite="Default" />
</security>

    À partir de là, vous pouvez spécifier le mot de passe:

    RemoteSvcProxy.TheirClient client = new RemoteSvcProxy.TheirClient();
client.ClientCredentials.UserName.UserName = "uname";
client.ClientCredentials.UserName.Password = "pwd";

    Je ne sais pas ce que votre outil personnalisé est, mais peut-être le cadre, il est basé sur a aussi des options de configuration similaires.

    OriginalL'auteur b_levitt