We have JAX-WS web service like this:
public class NamedDataHandlerContainer {
public String options; // format is option1_name=option1_value;option2_name=option2_value
#XmlMimeType("application/octet-stream") public DataHandler dataHandler;
}
#WebService
public interface mtomserver {
#WebMethod public int saveFile(String name,
#XmlMimeType("application/octet-stream") List<NamedDataHandlerContainer> contents,
#XmlMimeType("application/octet-stream") #WebParam(mode = WebParam.Mode.OUT) Holder<List<NamedDataHandlerContainer>> results);
}
When WSDL for that web service is processed with SvcUtil of .NET 4.0, it generates byte[] type for NamedDataHandlerContainer.dataHandler:
public partial class namedDataHandlerContainer;
{
[System.Xml.Serialization.XmlElementAttribute(Form = System.Xml.Schema.XmlSchemaForm.Unqualified, Order = 0)]
public string options;
[System.Xml.Serialization.XmlElementAttribute(Form = System.Xml.Schema.XmlSchemaForm.Unqualified, DataType = "base64Binary", Order = 1)]
public byte[] dataHandler;
}
However, in App.config it generates Mtom artifacts:
<basicHttpBinding>
<binding name="mtomserverImplPortBinding" messageEncoding="Mtom" maxReceivedMessageSize="1000000000" />
</basicHttpBinding>
(maxReceivedMessageSize is added by us to allow large attacghments). In fact WCF client sends MTOM attachment to the service - we are dumping HTTP payloads and confirm that:
--uuid:394d798b-e43e-47cc-82dd-64e32ef51edd+id=1
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><saveFile xmlns="http://wsserver.mtomtest/"><arg0 xmlns="">myfile.bin</arg0><arg1 xmlns=""><options>my options from .NET</options><dataHandler><xop:Include href="cid:http://tempuri.org/1/634993057692269386" xmlns:xop="http://www.w3.org/2004/08/xop/include"/></dataHandler></arg1></saveFile></s:Body></s:Envelope>
--uuid:394d798b-e43e-47cc-82dd-64e32ef51edd+id=1
Content-ID: <http://tempuri.org/1/634993057692269386>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
<binary content goes here>
JAX-WS can successfully apply streaming to such payload. However, is there a way to implement streaming on .NET side? I have read MSDN where it is explicitly said that only one parameter with streaming enabled may exist. However, is there a way to have custom message serializer (or something custom, I'm not an expert in WCF) and still avoid loading entire payload into memory.
WCF has a configuration to enable streaming. You don't need to write any additional code to achieve this.
<basicHttpBinding>
<binding name="mtomserverImplPortBinding" messageEncoding="Mtom" maxReceivedMessageSize="1000000000" transferMode="Streamed"/>
</basicHttpBinding>
Source: http://msdn.microsoft.com/en-us/library/ms789010.aspx
Related
How do I change my wcf service to be able to accept mustunderstand = 1?
This is a scenario where I have to change the service to be able to accept a request from the client. The client sends mustunderstand =1 in the header.
The service is configured to use basichttpBinding
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName"/>
<transport clientCredentialType="None"></transport>
</security>
Using soap UI I insert the following username token into the header
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-2684C13EA73A35131015516775308851">
<wsse:Username>username</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
I can reproduce the issue on soap UI when I insert this token in the wcf service request. This is the error
<FaultMsgRec>
<ErrCode>100</ErrCode>
<ErrCat>Error</ErrCat>
<ErrDesc>An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.--> The header 'Security' from the namespace 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' was not understood by the recipient of this message, causing the message to not be processed. This error typically indicates that the sender of this message has enabled a communication protocol that the receiver cannot process. Please ensure that the configuration of the client's binding is consistent with the service's binding. </ErrDesc>
</FaultMsgRec>
Since I have control over the wcf service I can go and add ValidateMustUnderstand = false in the service behavior.
Just like it is explained in the link
https://learn.microsoft.com/en-us/dotnet/api/system.servicemodel.description.mustunderstandbehavior.validatemustunderstand?view=netframework-4.7.2
Once I add this to the service behavior the error disappears.
But I don't want to turn off validation on the header especially if its a username, password. What should I do to allow mustunderstand=1? Am I missing something that the service doesn't automatically process mustunderstand=1 by default. I know there is code to be written on the client in order to sent a 0 in the header.
I am using message contracts in my wcf service not data contract. I understand that for certain properties I can go and add attributes like this link
https://learn.microsoft.com/en-us/dotnet/api/system.servicemodel.messageheaderattribute.mustunderstand?view=netframework-4.7.2. But I am not adding to any properties. I am just adding it to the first linke in soapenv:mustunderstand=1
Please help!.
Thank you
Not sure whether this could solve your problem. But you could try to add your header in web.config.
<endpoint address="http://ws-wuxipc-5077:4000/calculator" binding="basicHttpBinding"
contract="ServiceInterface.ICalculatorService" name="cal">
<headers>
<Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" >
<wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>
</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">monMonDePasse</wsse:Password>
<wsse:Nonce>sdsdsdlojhfdsdM5Nw==</wsse:Nonce>
<wsu:Created>2019-01-21T6:17:34Z</wsu:Created>
</wsse:UsernameToken>
</Security>
</headers>
</endpoint>
Or you could add header using code.
using (ChannelFactory<ICalculatorService> ChannelFactory = new ChannelFactory<ICalculatorService>("cal"))
{
ICalculatorService employeeService = ChannelFactory.CreateChannel();
using (OperationContextScope scope = new OperationContextScope((IContextChannel)employeeService))
{
System.Xml.XmlDocument document = new XmlDocument();
XmlElement element = document.CreateElement("wsse", "UsernameToken", "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd");
XmlElement newChild = null;
newChild = document.CreateElement("wsse", "Username", "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd");
newChild.InnerText = "finance";
element.AppendChild(newChild);
newChild = document.CreateElement("wsse", "password", "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd");
newChild.SetAttribute("Type", "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest");
newChild.InnerText = "387";
element.AppendChild(newChild);
MessageHeader messageHeader = MessageHeader.CreateHeader("security", "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd", element, false); // here is mustunderstood is set to false
OperationContext.Current.OutgoingMessageHeaders.Add(messageHeader);
}
Console.Read();
}
I am currently fixing a WCF based server enabled to provide large (multiple gigabytes) mpeg video files for a client.
The client shall both save the video and view it while still downloading. A buffered service failed because the video was loaded into memory completely.
When I try to get it with wget.exe or a web browser, it loads only a part (roughly 600 to 800 MB), then it stops without an error, neither on the client nor on the server side.
When opening the video stream in Internet Explorer, no time slider appears on the bottom, and the HTTP response has no content-length in header.
The HTTP response contains no Content-Length in headers, although it has been set in the code (see below).
Does anybody know how to fix this problem, or an alternate way?
Contract interface of the service:
[ServiceContract(Namespace = "http://www.blah.com/MyFunnyVideos")]
public interface IMyFunnyVideosService
{
[OperationContract(Name = "GetVideo")]
[WebGet(UriTemplate = "LORESVIDEO/{videoId}", ResponseFormat = WebMessageFormat.Xml, RequestFormat = WebMessageFormat.Xml, BodyStyle = WebMessageBodyStyle.Bare)]
Stream GetVideo(string videoId);
}
Implementation:
[ServiceBehavior(Namespace = "http://www.blah.com/MyFunnyVideos", InstanceContextMode = InstanceContextMode.PerCall)]
public class MyFunnyVideosService : IMyFunnyVideosService
{
// ...
Stream IMyFunnyVideosService.GetVideo(string videoIdString)
{
Logger.LogMethod();
try
{
FileStream fstream = GetVideoFileStream(int.Parse(videoIdString));
fstream.OpenRead();
var response = WebOperationContext.Current.OutgoingResponse;
response.ContentLength = fstream.Length;
return fstream;
// ...
}
Web service config contains:
<webHttpBinding>
<binding name="restBinding" transferMode="StreamedResponse" maxBufferSize="21474836470" maxReceivedMessageSize="21474836470" />
</webHttpBinding>
<behaviors>
<endpointBehaviors>
<behavior name="[omitted]">
<webHttp />
</behavior>
</endpointBehaviors>
</behaviors>
HTTP response headers:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: video/mpeg
Server: Microsoft-HTTPAPI/2.0
Date: Thu, 30 Jan 2013 15:52:04 GMT
Got to answer my own question:
It was simply a timeout. Default sendTimeout in webHttpBinding is 1 minute, then the transmission stops without any error.
So, I only had to set sendTimeout="00:10:00" in the webHttpBinding, for a 10min timeout.
I need help converting the following netTcpBinding to an equivalent CustomBinding:
<bindings>
<netTcpBinding>
<binding name="secureNetTcp" openTimeout="00:00:25" closeTimeout="00:00:27" receiveTimeout="00:10:10" sendTimeout="00:01:00"
listenBacklog="50" maxBufferPoolSize="2097152" maxBufferSize="2097152" maxConnections="50" maxReceivedMessageSize="2097152">
<readerQuotas maxArrayLength="2097152" />
<reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="true" />
<security mode="TransportWithMessageCredential">
<message algorithmSuite="Basic256Sha256" />
</security>
</binding>
</netTcpBinding>
</bindings>
I'm mostly struggeling with the Security part of the custom binding, because I can't fathom all the different settings. And everything seems to be named differently as well (compared to netTcpBinding parameters).
In case it's necessary I'll provide the following information as well:
The service endpoint has a certificate attached to it via serviceBehavior.
In my code I provide a username/password when creating the proxy (service behavior has <userNameAuthentication userNamePasswordValidationMode="Windows" /> under serviceCredentials; For the netTcpBinding the WCF configuration editor shows ClientCredentialType=Windows, which I guess is the default value).
Update:
I have found a potential solution for my main problem - increasing ChannelInitilizationTimeout - without having to create a CustomBinding. I'll share this, incase someone stumbels upon this thread while googeling...
What I did was create a custom class that inherits from NetTcpBinding and in it's constructor used reflection to set the ChannelInitilizationTimeout property. Thus maintaining full compatibility with NetTcpBinding.
Here is the code for my custom class:
public class MyNetTcpBinding : NetTcpBinding
{
public MyNetTcpBinding()
{
var fi = typeof(NetTcpBinding).GetField("transport", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance);
var val = (System.ServiceModel.Channels.TcpTransportBindingElement)fi.GetValue(this);
val.ChannelInitializationTimeout = TimeSpan.FromSeconds(10);
}
}
public class MyBindingElement : NetTcpBindingElement
{
protected override Type BindingElementType
{
get { return typeof(MyNetTcpBinding); }
}
}
public class MyBindingElementCollection : StandardBindingCollectionElement<MyNetTcpBinding, MyBindingElement>
{
}
After compiling this class (I created a seperate DLL project for this class), I used WCF configuration editor (under left pane "Configuration" -> Advanced -> Extensions -> binding extensions -> new -> give a name, eg. "MyNetTcp" and point to the dll file) to add my class as an extension to bindings.
Afterwards in WCF app.config just replace netTcpBinding with MyNetTcp (there are three references in total; one in <service><endpoint binding="netTcpBinding"></endpoint></service>; the other two are xml tags under <bindings><netTcpBinding></netTcpBinding></bindings>).
I will leave this question open in case someone wants to give a proper answer to the original question...
You can pass in the netTcpBinding into a custom binding and do the following.
There is no guarantee that reflection will work across versions.
http://blogs.msdn.com/b/sajay/archive/2010/01/29/how-to-create-a-custom-binding-from-a-standardbinding.aspx
Editing this to refocus on the actual issue. I've preserved the origional question at the bottom of the message but changing the title and content to reflect what was really happening.
I need to override the maxReceivedMessageSize for a WCF service added to an MVC3 project via the ServiceRoute mechanism. Specifing the binding in the web.config doesn't work. How does one do this.
Initial question is below this line but is misleading based on lots of false positives I was seeing.
Hi I have used some examples to add a file streaming upload service to my MVC3 project. If I use the default bindings (i.e., not defined in web.config) the service works as long as I don't exceed the 64k default size. When I try and define my own binding to increase the size I get a content-type mismatch in my trace and a HTTP415 Unsupported Media Type in the response. I'm trying to call this via fiddler via HTTP and am not using a WCF client.
Here is the error in the trace:
Content Type image/jpeg was sent to a service expecting multipart/related;type="application/xop+xml". The client and service bindings may be mismatched.
Here is the web.config service model section
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="NewBehavior0" />
</endpointBehaviors>
</behaviors>
<services>
<service name="AvyProViewer.FileService">
<endpoint address="UploadFile" binding="basicHttpBinding" bindingConfiguration=""
contract="AvyProViewer.FileService" />
</service>
</services>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true"/>
<bindings>
<basicHttpBinding>
<binding name="NewBinding0" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647"
messageEncoding="Mtom" transferMode="StreamedRequest">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
</binding>
</basicHttpBinding>
</bindings>
Here is the service:
[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class FileService
{
[OperationContract]
[WebInvoke(Method = "POST", UriTemplate = "UploadFile")]
public string UploadFile(Stream fileStream)
{
string path = HostingEnvironment.MapPath("~");
string fileName = Guid.NewGuid().ToString() + ".jpg";
FileStream fileToupload = new FileStream(path + "\\FileUpload\\" + fileName, FileMode.Create);
byte[] bytearray = new byte[10000];
int bytesRead, totalBytesRead = 0;
do
{
bytesRead = fileStream.Read(bytearray, 0, bytearray.Length);
totalBytesRead += bytesRead;
} while (bytesRead > 0);
fileToupload.Write(bytearray, 0, bytearray.Length);
fileToupload.Close();
fileToupload.Dispose();
return fileName;
}
}
And here is where I expose it in my MVC3 routes:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.Add(new ServiceRoute("FileService", new WebServiceHostFactory(), typeof(FileService)));
. . .
}
I think the issue is with the mtom declaration for messageEncoding in your binding. Try changing messageEncoding to Text.
Answer ended up being a combination of three different stack overflow posts. None by themselves solved the question but each provided crucial clues as to what was happing.
It seems that if you add a ServiceRoute the web.config binding information is ignored. This SO post clued me in to what seems to be undocumented behavior of this function: Unable to set maxReceivedMessageSize through web.config
I then used this post to determine how to programatically override the maxreceivedmesssagesize for the binding: Specifying a WCF binding when using ServiceRoute.
Unfortunately the code form #2 didn't work out of the box (not sure if the binding behavior for ServiceRoute has changed or what makes the difference). Turns out that if you specify a ServiceRoute its automatically created as a CustomBinding which can't be cast to the WebHTTPBinding type used in #2. So this post: How to set the MaxReceivedMessageSize programatically when using a WCF Client? helped me determine how to change the code in #2 to add this capability to a custom binding.
I am developing WCF services with basicHttpBinding, these services should be accessible using .net 1.1 & .net 2.0, for this purpose I am using basicHttpBinding. In old ASMX web services I assed one Soap Header (AuthHeader) to authenticate the user every request.How Can I authenticate in WCF using basicHttpBinding? Any sample Or tutorial will helpfull.
nRk
You can use AuthHeader as you did before switching to WCF. Maybe it will be more convinient for you, cause the princples will remain the same.
The bad thing i see in this solution is a plain text password transfer. Anyway, it's just another option and you can encrypt/decrypt the password somehow.
In this case you should implement your own your IDispatchMessageInspector & IClientMessageInspector, like
[AttributeUsage(AttributeTargets.Class)]
public class CredentialsExtractorBehaviorAttribute : Attribute, IContractBehavior, IDispatchMessageInspector
{
#region IContractBehavior implementation.
public void ApplyDispatchBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint,
DispatchRuntime dispatchRuntime)
{
dispatchRuntime.MessageInspectors.Add(this);
}
... empty interface methods impl skipped ...
#endregion
#region IDispatchMessageInspector implementation.
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
int i = request.Headers.FindHeader("username", "sec");
if (-1 != i)
{
string username = request.Headers.GetHeader<string>("username", "sec");
... do smth ...
}
return null;
}
public void BeforeSendReply(ref Message reply, object correlationState)
{
return;
}
#endregion
}
In a sample i placed to header only username, but you can implement your a class containing username and password and use it instead of string.
On the client:
internal class CredentialsInserter : IContractBehavior, IClientMessageInspector
{
private string m_username;
public CredentialsInserter(string username)
{
m_username = username;
}
#region IContractBehavior implementation.
... empty interface methods impl skipped ...
public void ApplyClientBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint,
ClientRuntime clientRuntime)
{
clientRuntime.MessageInspectors.Add(this);
}
#endregion
#region IClientMessageInspector implementation.
public object BeforeSendRequest(ref Message request, IClientChannel channel)
{
MessageHeader<string> mh = new MessageHeader<string>(m_username);
request.Headers.Add(mh.GetUntypedHeader("username", "sec"));
return null;
}
public void AfterReceiveReply(ref Message reply, object correlationState)
{
return;
}
#endregion
}
Then you should place attribute CredentialsExtractorBehaviorAttribute on your service implementation class.
[CredentialsExtractorBehavior]
public class DummyService : IDummyService
{
... impl ...
}
And on the client side you should do the following:
using (DummyServiceClient c = new DummyServiceClient("TcpEndpoint"))
{
c.ChannelFactory.Endpoint.Contract.Behaviors.Add(
new CredentialsInserter("_username_"));
c.DummyMethod();
}
First of all - yes you can! It depends on whether you use Transport or Message binding - if you're internet-facing, you're more likely to use message-based security.
Unfortunately, for message-based security, basicHttpBinding only supports certificates which is a bit of a pain.
wsHttpBinding on the other hand would support username/password or other methods as well.
You'd configure wsHttpBinding with username/password client credentials over message-based security like this:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="wsUserName">
<security mode="Message">
<message clientCredentialType="UserName"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
<services>
<service name="yourservice">
<endpoint name="YourEndpoint"
address=""
binding="wsHttpBinding"
bindingConfiguration="wsUserName"
contract="IYourService" />
</service>
</services>
</system.serviceModel>
The section under <bindings> defines a binding configuration for wsHttpBinding that uses message-security with username/password client credentials.
The section under <service> defines a sample service that uses wsHttpBinding and that references that binding configuration that we just defined.
On the server side, you could now use the username/password that's being sent over the wire to validate your callers either in your Active Directory (everyone calling needs an AD account with you), or in the ASP.NET membership system database; or if you really really must, you could write your own authentication mechanism, too.
Find a lot of useful information on WCF security at Codeplex - excellent resource.
Check the scenarios here to try to match one to your situation. Each scenario is provided with a chceklist of items required to implement the solution.