I am trying to disable a web service WS-Addressing. I followed the steps passed by Serene Trees in microsoft forum.
She says basicaly to create a custom binding and set messageVersion on the textMessageEncoding element to "Soap12".
But my service still generating references to addressing namespaces.
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
Does anyone know why it occurs and whether I can remove these references?
Related
We’ve written a WCF (4.0) client of a web service for which the WSDL includes the following security policy
<wsp:UsingPolicy wssutil:Required="true"/>
<wsp:Policy wssutil:Id="UsernameTokenPolicy">
<sp:SupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:Policy>
The headers in our messages include the <nonce> tag. We didn’t have to explicitly write code to do this – it appears the .NET libraries automatically generate a nonce value and add it.
The problem is the server we’re talking to has been changed. It is now a JBOSS server (was previously WebLogic) and, apparently, whoever has deployed it is saying that it’s rejecting our messages because of the <nonce> tag.
From what I can see JBOSS does properly handle the <nonce> tag, so I’m not sure why it’s being rejected – I assume it’s a configuration setting on their end. [Edit] JBOSS strictly follows the WSSE uername and Token Security Spec 1,1, which requires that the Nonce explicitly provide and EncodingType. The .NET Framework does not strictly follow this spec.
However, I’d like to know is there any way of configuring my WCF client to not include the <nonce> tag?
I’d prefer not to have code the header explicitly as that would require rolling out patches with proper testing, etc. and would also be more prone to error. So, I’m really hoping there’s a client configuration option for this.
The Wikipedia page for WS-Addressing states:
WS-Addressing supports the use of asynchronous interactions by specifying a common SOAP header (wsa:ReplyTo) that contains the endpoint reference
I have a simple WCF service that I'm exposing via SOAP. I can see the WSDL and there are XML Namespaces in the root node that mentions addressing:
<wsdl:definitions ...
xmlns:wsa10="http://www.w3.org/2005/08/addressing"
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
...
>
Can I create an asynchronous WCF (or other .NET, but not from scratch) client that makes use of WS-Addressing?
I've added a service reference to a console app and the proxy class looks correct, but how do I know I'm taking advantage of the WS-Addressing? I know I can watch the HTTP requests to see it making asynchronous calls but that's a bit trial and error.
I know there is the "Generate asynchronous operations" checkbox, I assume this utilizes the usual Begin/End pattern found in .NET and not WS-Addressing?
Asynchronous operations and the use of WS-Addressing are orthogonal. The use of addressing is determined based on the binding used in the endpoint, and and defines the format of the message exchanged between the client and the server.
The fact that the operation is synchronous or asynchronous doesn't have an impact on the message on the wire - you can have the same message defined as both synchronous and asynchronous and they should work just as well.
An error occurred while trying to make a request to URI:
'http://localhost:8732/Design_Time_Addresses/WCF/Service1/'. This
could be due to attempting to
access a service in a cross-domain way without a proper cross-domain
policy in place, or a
policy that is unsuitable for SOAP services. You may need to contact
the owner of the service
to publish a cross-domain policy file and to ensure it allows
SOAP-related HTTP headers to be
sent. This error may also be caused by using internal types in the web
service proxy without
using the InternalsVisibleToAttribute attribute. Please see the inner
exception for more
details.
the error appears when result returned from the wcf
I consumed this wcf via console, website, win forms and it works properly
I use 2 xml files in the WCF library :
clientaccesspolicy.xml
crossdomain.xml
It used to make my brain hurt too.
I figured out for my use I needed this file:
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="SOAPAction">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
named clientaccesspolicy.xml
The trick is that is has to be at the root of your web server. That being said you need to be able to browse the file. In your case located at:
http://localhost:8732/clientaccesspolicy.xml
If you cannot see the file silverlight will always complain and boy does it complain whenever it can!
I should point out that my policy file is not restrictive, so use it wisely.
Oh, that problem. Besides the crossdomain, you cannot run the debugger from VS2010 which is what i'm gather from that localhost URL. Try publishing silverlight app on the domain or server that your WCF is on. For example, if your web service is on http://10.xx.xx.xx/sites/myWCF, publish your silverlight app on http://10.xx.xx.xx/sites/MySilverlightApp. You're debugger is going to run as http://localhost:somePort which is definitely going to give you problems even with a cross-domain policy file. Apart from that, ensure that you config file for your web.service is correct. Ensure all the interfaces have endpoint bindings and there is a host on the main service location(sounds obvious, but is a common error).
I'm writing a .NET client (WCF) that will consume a web-service that is implemented using Apache CXF (Java) and amazingly enough it's incredibly hard have WCF to set the Type attribute of the Password tag to PasswordText. I.e I would like the SOAP header to look something like:
<wsse:Security soap:mustUnderstand="true" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-11" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>test</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">a287645857cfaaddf82e2d333651b3e0</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">oKGlwEkbkhYJH6upsbiqeQ==</wsse:Nonce>
<wsu:Created>2011-10-25T13:10:11.958Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
but the actual header looks like:
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:UsernameToken u:Id="uuid-5acb0b47-1b52-4535-bfaf-b9e76621b7eb-1">
<o:Username>test</o:Username>
<o:Password>a287645857cfaaddf82e2d333651b3e0</o:Password>
</o:UsernameToken>
</o:Security>
As you can see the Type attribute is missing from the Password tag. Some research on the web seems to indicate that I perhaps have to write an interceptor to fix this. I figured that there was a simple solution, i.e. config setting, to fix this but maybe there is not. Anyhow, I'm hoping for some clarifications by posting this question.
The WS server rejects the request because of the missing Type attribute. Some function checking for BSP spec. compliance (not sure what this is) throws an exception.
Regards, Ola
OK, the implementation requires using WSE 2.0 SP3. Be careful NOT WSE 3.0.
WCF cannot help you.
All you need is here.
This is a better sample.
I'm troubling into an issue...
I'm trying to find a way to generate a single wsdl document from my WCF service, i.e. without any link to external documents.
I've used FlatWsdl to remove all xsd:import links, bou my generated wsdl still contains a link to an external wsdl document via a wsdl:import declaration:
<wsdl:import namespace="http://myurl/mynamespace"
location="http://myserver/myservice.svc?wsdl=wsdl0"/>
This document actually contains all inlined xsd schemas, so... there's a way to inline also this external wsdl document, in order to have a single wsdl?
Thanks a lot for any kind of help.
You can now do this natively in .net 4.5 (beta). There is an option (?singleWsdl instead of ?wsdl) for telling the service to output everything in a single wsdl document. More info on the new stuff here: http://msdn.microsoft.com/en-us/library/dd456789(v=vs.110).aspx
(EDIT: Previous answer about FlatWSDL deleted, because as you pointed out it was about eliminating xsd:import not wsdl:import.)
Look at this blogpost: Control generated WSDL in WCF
"... There is always one WSDL generated for one target namespace URI ..."
Do you have different namespace for ServiceContract, DataContract, ServiceBehavior, etc. ?
You could also use the WCFExtras project it has an extension to create a single WSDL-file.
WCFExtras
A collection of useful WCF extensions
including Soap Header support, WSDL
documentation and more.
The WCF platform is very extensible
and allows you to easily add features
that are not part of the core product.
This project contains some extensions
I needed in a WCF based project:
SOAP Header support for WCF Adding WSDL
Documentation from Source Code XML Comments
Override SOAP Address Location URL
Single WSDL file for better compatibility with older SOAP tools.
http://wcfextras.codeplex.com/
my problem was in endpoint definitions, that are in tempuri.org namespace
adding bindingNamespace to endpoint declarations fix my problem.
thanks to all for help :)
This is a late answer, but I had the same problem with a few of our WCF services. If you're on .NET 4.5, like the earlier answer, use ?singleWSDL, but if you're not targeting .NET 4.5 then I added the following to my web.config to fix the issue...
<useRequestHeadersForMetadataAddress>
<defaultPorts>
<add port="80" scheme="http" />
<add port="443" scheme="https" />
</defaultPorts>
</useRequestHeadersForMetadataAddress>
This goes in your behavior. That way I didn't have to flatten the WSDL because all references were to MyURL instead of MyServer.
Hope this helps others with a similar issue.
In addition to Jim's answer above, if you're using C# code to configure a WCF ServiceHost directly:
using System.ServiceModel.Configuration;
and when setting up your ServiceHost:
UseRequestHeadersForMetadataAddressBehavior urh = new UseRequestHeadersForMetadataAddressBehavior();
serviceHost.Description.Behaviors.Add(urh);
I struggled to find this information online, as simple as it is. Hopefully helps someone in a similar situation.