Interacting with google chrome browser from WCF service - wcf

I have a local WCF service which needs to communicate with a web browser.
It has to do the following
Scroll the page
Add cookies
Open new tabs
Etc.
I thought to use one of those; Chrome, IE, Firefox and create an extension which would forward my WCF messages to a browser.
Have you got any suggestion which browse has a richer API, easier to use, etc.
Edit:
So the scenario is following:
WCF service runs on PC and waits for clients.
A client (which in my case is a mobile device) connects to the service.
A client ask to perform an action on a browser
Message via WCF is forwarded to the browser
I hope this scenario makes sense :)

In general, WCF services provide services that clients consume. It is probably not a good idea at all to try to force a WCF service to attempt to control anything.
WCF services should, in general, know nothing about the clients they serve. So your service should know nothing about a browser at all.
The only scenario that might make any sense to me would be if the service provides some sort controlling information (where to navigate to, which tabs to open, etc) to a client that would then do the actual controlling itself.
Make sense?

Related

Is it possible to create a website with WCF?

Is it possible to create a website (hosted locally on my machine is fine for now) using a WCF Service Application?
By "web site" I mean allow an HTTP call from a web browser to my service and have the service return an HTML page that the browser can then render/display.
I am doing something very similar using a WCF based REST service. I have a WCF service that is accessed only from a web browser to download images. If you browse to 'http://www.MyFooImageService.com/100', it will lookup from the database an image with ID 100 and serve it up to the user. I use it to serve images from WCF service for the purpose of sending (user defined) emails with embedded images.
I used this guide with great results: RESTFUL WCF Service Step-ByStep. Check it out and see if a REST based WCF service is what you are looking for.
No, it doesn't quite work like that. WCF applications are service applications. There is no GUI interface or web interface or any kind of interface at all.
What you do is you create a WCF service that does some sort of function. Lets say you create a method called StoreName that stores your name into a database. Keep it simple. WCF services can be hosted in a variety of ways, depending on how you plan to use it. But to keep it simple, lets say you host the application using IIS.
Now this WCF application has no interface for interacting with it. You need to create an ASP.NET application (or it can be PHP, or jQuery if you prefer). It might have a text box and a submit button. Once the submit button is pushed, the ASP.NET application (or jQuery or PHP) makes an ajax call to your WCF service, passing it in the name as a POST parameter. The WCF service then does the work of storing it in the database. Execution then returns back to your web application.
This is a general overview of how this works. I hope it helps!
A website involves:
1) A user requesting HTML from somewhere
You can proxy pass a simple HTTP Get request to a WCF service hosted in a console app (or hosted in IIS), and configure it to return an HTTP request of content type text/html. Then the user would see a website appear in the browser.
But WCF is not a good fit for this. Especially if it's a simple HTML page. Others have said ASP.NET is better for this. And that's true. But node.js or PHP or pretty much anything that isn't .NET is MUCH better for this.
2) A user uses the web page to interact with server processes
This involves a user clicking a button or moving a mouse, or anything, and then that results in the web page (actually a web app at this point) making AJAX requests to one, or several server(s).
WCF is quite a good fit for this.

Is a WCF service open for method calls for any computer in the network by default?

I have a silverlight web application and I am loading data to the client side using a wcf service. Should I secure the WCF service? Can anyone who's on the network call methods of the service?
Yeah they can see and access the service if they know the url.
And if they can see it, they only need to do a "Add Service reference" and they can see all methods available.
And since silverlight uses the basichttpbinding, it can work through firewalls (they typically allow http traffic).
You should secure it if it contains sensitive info.
By default you'll have security through obscurity, so if you're not broadcasting your WCF service's presence, it's not likely to be found or called. Additionally, it would be very hard to use it without having an appropriate client proxy configured. If you do not have the MEX endpoint set up, you are again pretty safe.
All that said though, you haven't really authorized the calls. It's theoretically possible to locate your WCF service and create a proxy to call it. So if you want to be safe, which I recommend, look into WCF authorization. It's fairly easy to set up, and you can use various options such as username-password, Windows accounts, or X.509 certificates. Each has its pros and cons.
This article goes into great detail, and there are others. http://msdn.microsoft.com/en-us/magazine/cc948343.aspx

WCF - push data from web app to windows form application

I am not sure though what exactly to ask since im very new to WCF. So I'll try to explain what I am doing. I need to create a web app with textbox and button. On button_click the data in the textbox should be push on a win form app supposedly to be deployed to a client. So what's connecting them is the wcf service. I am not exactly looking for codes as solution rather a theory or what I am missing. Thanks.
The simple method is to have your web site publish the button state and have the clients poll for updates. That is very easy to do with wcf, all you have to think about is security - if any.
The hard way is to let the clients to "sign" up on the wep application and then push the state to the clients. Each client would need its own wcf listening endpoint that can be called from the web application. The implementation is simple enough, but I'll suspect that you will run into issues with connectivity. Do the end user have rights to open ports for listening in windows? If the clients are behind nat-routers can you be sure that you can connect to them?

Security of WCF endpoints

For the sake of argument, lets say that I've got a basicHttp WCF service. Besides implementing authentication (login/logout methods), what is stopping someone from just cracking open Visual Studio, adding a web reference to my website's service, and then playing playing around with my service? I'm not familiar with a method of stopping someone from doing this. The idea of someone downloading all of my Data/Operation contracts and then start playing around is keeping me up at night, and I like my sleep!
Discoverability is the driving factor behind Web Services and especially SOAs. The ability of anyone at all who can reach the service to pull up the WSDL, generate a proxy in Visual Studio (or some other tool), and start using the service is one of the main reasons to create a web service!
I suppose you could generate all the client proxies and then disable the mex endpoint, but that pretty much cripples WCF, and even then it's only security through obscurity.
If you don't want any miscreant to start hitting your web service then either don't use the basicHttpBinding (which is designed for the express purpose of immediate and anonymous consumption) or host the service on a private network which only trusted clients can reach.
Some form of authentication or encryption is the only thing that can prevent this. You have to distinguish between those you want give access to, and those you don't. Give the ones you want to have access the certificate necessary to do encryption, or the username and password.
Don't give anything to the others.

What are my binding options for a self hosted cross domain WCF service with remote thick clients?

I'm trying to build a WCF self hosted service (eventually in a windows service) that will receive binary and text base messages from remote thick clients that have no accounts on my hosted machine. I'm trying to figure out both my binding options and security options, and in reading the patterns and practices guides, my head has completely spun around at least once.
The clients would be authenticated against a custom SQL based method, so I'd like to be able to pass that info in the initial login request and then set an authorization token of some kind. (This part of the problem is probably outside the scope of the question, but I included it in case it might make a difference.)
Any thoughts at all would be very helpfull.
Ryan
The choice of binding and security option depends on the usage of your WCF service. Is it just for your rich client or are you planning to expose it to the world as API? If it's just for your rich app, does it run on LAN or over untrusted, unreliable Internet?
With WCF you can configure the service to expose multiple endpoints with different bindings, for example both SOAP and REST. In general, I'd start with something stateless and lightweight like basicHttpBinding and webHttpBinding, passing user and password on every request. Once you have that up and running you can optimize cache authentication, provide binary endpoint etc.. only if it actually helps.
There's no need to have just one binding. Having said that if it's self hosted you're "on your own" here. I've never looked at what's involved.