I have a RESTful WCF service that exposes a method that takes in an XElement as a parameter.
Now i want to know if i need to check the incoming message for XSS attacks first or does the framework handle it by default.
If i need to handle do i use the Microsoft XSS library to perform this operation on the XElement string that comes in from the request.
check the below link for further details
REST Security
REST does not have predefined security methods so developers define their own, and
Often, developers in a hurry to just get... services deployed don't treat them with the same level of diligence as they treat web applications.
Related
I've been looking into WebAPI and really like what I see.
Is there are reason why NOT to use WebAPI? If so, in what scenario?
I initially thought in a cross-platform SOA architecture, WebAPI might fall short, but the more articles I read, the more I realise that WebAPI might beat WCF in almost every realistic scenario. It looks like you can use WebAPI for android, ios etc. and not just for .Net; even performance shows WCF REST to be slowest. http://weblog.west-wind.com/posts/2012/Sep/04/ASPNET-Frameworks-and-Raw-Throughput-Performance
Is there still an "obivous" reason where WCF is better?
Whenever you control the both the consumer and provider endpoints (for example back-end service-to-service communication) you should use WCF (or Sockets) for capabilities and performance. Hosting the service via WCF and then sharing binary contracts means 100% guaranteed matching, compiler-checked and type-safe (de)serialization between client and server.
If you also have full CI you all but eliminate the risk of releasing binaries with mismatched contracts. Web API serialization is more forgiving, and thus verification and testing is more involved (client can send data server does not expect, server can send data client does not expect.) WCF also supports contract versioning and extended data, this allows intermediary services that only know V1 contract can still accept and forward to a V2 or later message while preserving all data for services which understand V2 or later contracts!)
WebAPI is mainly for implementing HTTP-based services with minimal frustration, as such, WebAPI relies heavily on the asp.net HTTP Web Stack to function (whereas WCF and its underpinning's do not, matter of factly, some WebAPI features rely directly on WCF.. for example, exposing OData feeds via WebAPI.)
Similar to Web API endpoints, WCF endpoints can be configured to provide access via HTTP as necessary (among other protocols and technologies such as Secure Named Pipes, MSMQ, UDP, TCP, etc.) WCF is also extensible, and out of the box it provides transport implementations for duplex, bidirectional and reliable messaging, it provides both Transport-level and Message-level authentication using Tokens, Certificates, basic Authentication Credentials and more. There is additional support for service discovery, subscription, broadcasting, etc. (Admittedly, WebAPI provides some overlap, but not with the same level of control.)
Not only does WCF support all this, it is highly configurable allowing you to mix and match between MOST of the available transport, formatting/serialization, security, instancing, lifetime and other service settings through configuration files and code.
Moved two of your middle tiers together into same machine now? Switch to a named pipe. Swapping a server from .net to PHP? No problem, change binding config from using net.tcp to use soap. Where WebAPI stops, WCF continues.
However, as with any technology, WCF only shines as well as your developer's understanding of networking and infrastructure. Put in the hands of the mediocre or unwilling and you will get a complete mess that fails to perform. WebAPI is a little bit more fool proof, even beginner programmers can put it to use within minutes, and generally succeed at their task doing so.
2c
I have a third-party Java web service listening at three SOAP 1.1 WSDL endpoints. One of the endpoints is used to initiate the session and perform some high-level tasks, and the other endpoints are for subject-specific tasks reusing that initial authentication.
I'm building a C# WCF application to talk to the service, and I'd like to share the session cookie among the three client objects.
What's the VS2010 'best practices' way of sharing this cookie?
If this article is still the best answer, I can go with it, but I would appreciate some additional feedback, especially if .NET 4 introduced a simplification that I'm not finding on-line.
http://megakemp.wordpress.com/2009/02/06/managing-shared-cookies-in-wcf/
I can pretty easily create the first client and retain the session (new BasicHttpBinding myBinding; myBinding.AllowCookies = true), but I couldn't find an elegant way of saving off the cookie from the Connect response and reusing for the two auxiliary clients.
Any insights are appreciated.
I should note that I'm aware of CookieContainer and using Add Web Reference instead of Add Service Reference. That method is labeled as 'legacy' in most posts I've read, and I'd prefer to stay current...or as current as possible when working with SOAP 1.1.
The mentioned article is still valid. You have to use OperationContextScope and access message properties to get protocol specific data. This complexity is based on the fact that WCF architecture is protocol independent whereas ASMX architecture was HTTP protocol dependent.
It is true that ASMX (WebReference) is legacy technology but it is still present in .NET framework so if you know that you will never need nothing more the basic SOAP messaging without any advanced WS-* standard you can still use it and make your life little bit simple. Once you need anything more you can still refactor your code and use WCF with mentioned code to work with cookies.
I'm new to WCF RESTFull services developpment and I'm looking for some usefull information and your experience feedback about using webHttpBinding compared to the new WCF Web API http://wcf.codeplex.com/.
What I'm looking for is to know about the shortcomings of webHttpBinding and therefore why to use the new Web api and especially what problems the new API resolves.
If you could point me to some blog posts comparing both of them or just talking about the problems when using webHttpBinding I would appreciate. Thank you in advance.
Main shortcomings I would say is that the webhttpbinding makes it difficult to handle HTTP specific concerns. It works great if all you are doing is passing an object over HTTP that is serialized into XML or JSON and which may be transported over different formats.
HTTP is much more than a simple transport protocol for XML and JSON, it is an application layer protocol with rich semantics. Web API is specifically targetting folks that want to build systems over HTTP that fully levergage HTTP's richness.
Web API embraces that HTTP Resources can have a multitude of representations based on the needs of different clients. One end of the spectrum could be a dumb browser that just talks to a service using a Form url encoded post and a GET, while the other end could be a more rich client that uses Atom/OData or a hypermedia based media type.
Web API embraces that there are other HTTP specific concerns like conneg, etags, etc which allow better leveraging intermediary web servers.
Web API is designed with more testability in mind, thus you can address working with HTTP messages or other concerns in a more testable manner.
Web API has a more simplified configuration story.
You can read more about the rationale here: http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx
The most significant difference for me is the change in programming model. You no longer write 'services' which expose 'operations' bound to HTTP idioms (GET, POST etc.). With Web APIs you create 'resources' (POCOs) with which your clients can interact.
Web APIs seem to be better at handling various custom media types (like PNG images for example).
Last but not least, Web APIs are far better suited for automated testing. For instance, you no longer have to use static context classes to access HTTP concepts such as response codes. You use POCO request and response classes which can be easily instantiated in automated tests using old-style new() operator.
I agree with Ladislav that Web APIs are just a preview now and building application on top of it can be both risky and forbidden by the means of license agreement (but I haven't checked that).
Have you considered #serialseb's OpenRasta? It is stable and offers very nice programming model for building RESTful services.
The Web API is something like possible future of REST development in WCF. It is just preview which can significantly change before final release (probably in next version of .NET framework). So if you want to build production REST service you should use webHttpBinding.
Available information about Web Api can be found for example on .NET Connected Framework team's blog and on the site you mentioned. It is simplification and extension of current REST API.
Web API provides a REST-friendly HTTP based API. Web API uses the patterns of MVC and is going to be very familiar to ASP.NET MVC developers. Web API can leverage the capabilities of HTTP as an application layer protocol, returning resources in multiple representations (XML, JSON, HTML etc.) according the the client's request headers.
On the other hand WCF webHttpBinding uses the patterns of WCF, and is going to appeal more to the WCF developer - ServiceContracts, OperationContracts, comprehensive (or overweight, depending how you look at it, config file), ability to self-host outside of IIS.
One of the things I like about Web API is the ability to use dynamic types to escape the constraints of the type system. I also like the default exception behavior in Web API - contrast WCF webHttpBinding where, by default, exceptions bubble up as HTTP 500 + an HTML payload (yuk!).
Its nice to have the choice between two excellent technologies here. I wouldn't describe Web API as 'newer' or 'better' that WCF, as this implies its a replacement technology and that WCF webHttpBinding is legacy, which I don't believe is true.
I chose to use WCF webHttpBinding recently to expose a JSON API for an existing WCF SOAP service. I believe it was a good choice because it fitted that style of that existing solution and minimized the amount of change required.
I've read several entries on the web about securing WCF Data Services (OData). I would be glad to hear your recommendation about securing WCF DS assuming it will be consumed by Java client.
I think you have a number of options available. Since it's all REST requests, the client doesn't really matter too much (except that it rules out any Windows-specific integrated stuff). :)
I've done some prototypes where I have an encrypted token in my request header which I grab in the OnStartProcessingRequest event handler. You have access to HttpContext.Current, so you can just grab the request header, validate it against your token store, and then either let the request continue or not. The client, whether it's Java, C#, JavaScript or whatever would be responsible for creating the token and appending it to your request headers.
Last year, the WCF Data Services team put out a series of blog posts responding to some community criticism that WCF Data Services weren't not that secure. They listed out a number of different scenarios on securing your WCF Data Services. Two entries in particular that I think are appropriate for your situation are these:
OData and Authentication – Part 4 – Server Side Hooks
OData and Authentication – Part 5 – Custom HttpModules
You can find all blogs in the series here.
I think those two links are useful because it's all about the server-side configuration. OData support is also contained within RESTlet extension, but being a .NET guy, I can't give you much more info that that. :)
I hope this helps. Good luck!
Folks,
I'm building a pretty standard workflow that I want exposed via a WCF endpoint - I'm using the "WCF Service Application" project template and I've got a .xamlx service. This is a very simple document interchange workflow service - I want consumers to POST me a blob of XML as the body of an HTTP post (with HTTP headers containing authentication tokens). In response, these consumers will get a blob of XML containing the reply. 2 goals for me using REST/POX here are the document/message-based nature of the interaction AND I want to make client development easy for non-.NET environments (especially limited environments like Silverlight and iPhone).
I don't really see how to make this possible using out of the box features (unless I'm missing something). Does anybody know how to create a RESTful (or even REST-ish, I'm not picky) endpoint for a WF4 service-hosted workflow? Any info leading in the right direction here would be great.
There is an unreleased item on CodePlex to cover this, which includes source code. Also see this SO answer which contains another idea for achieving this.
If you'd like to see the CodePlex activity released, please up-vote the UserVoice request.
Using a REST Pass-Through Service
As #Maurice mentions, you can also treat the WF service as a back-end service and expose a REST service that simply calls through to the WF service.
This method is a bit clumsy, but has the advantage that it doesn't use anything unreleased or really complicated.
If the back-end service runs on the same machine as the REST service (which is probably what you'd do), you should expose the WF service using the named pipes binding. This binding is fast, but only works when the caller and callee are on the same box.
A further thought: your REST pass-through service is blocked while the back-end service is being called. If your WF service is not very fast, you'd benefit from making your REST service asynchronous so it doesn't block a thread pool thread while the WF service is being called.
There are no out of the box activities that will allow you to use REST with WF, the Receice is pure SOAP.
You can either build a custom REST Receive activity and use that with your workflow. Depending on your needs this is going to be quite a handful to a lot of work. The easy option is use use a standard REST WCF endpoint and convert the REST data to SOAP, pass rhe request on to the workflow, and do the reverse on the result message.