In my WCF service application , images are saved into application directory. So in one of the service call, it returns the image(http request to the url- http://mydomain:88/Images/Tree/test.png) to the client application.( a mobile application). The url exposes the application directory, so is this a good practice? All the call to the service is protected using basic authentication. But still is this good practice to exposing the directory structure in url?
Thanks.
All you've done is expose a little information to the world about your directory structure behind the scenes - probably not a "best practice". But generally, I'd say you're safe if:
you don't expose the directories to browsing (like via an IIS
setting)
the web service or proxy is located behind a firewall within a
DMZ
the WCF requests are authenticated/authorized before
content is delivered.
You can fix this without too much work, though. Assuming the "Test.png" is the file the client is trying to download, change the host-side endpoint so that it's just ".../Images/Tree/Connect" that receives the file name as a parameter in the Get(). The host and clients would have to change, but it's not a big change.
Related
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.
as you can see, I am relatively new on SO please don't kill me after posting this question :) I will do my best to describe the dilemma I am currently in.
I am creating something like a "Guardian Service" that is hosted on Windows Azure inside a Worker Role. This service has external ports, that can be accessed via HTTPS to allow clients to call it's service methods.
The WCF service is meant to call other services hosted in other Worker Roles that have only internal ports open, and which can be accessed only through the use of the Guardian Service. That's the main idea. Similar to a proxy or something.
I read already an excellent article from Jim O'Neil, what the caveats are when you try to access internal service points from within other WCF Services hosted in worker Roles:
His blog Troubleshooting Endpoints on a WCF Web Role
This is not the point for this question, and totally clear to me how to do that.
I have no idea at the moment, how I could do this, without implementing every contract from every single service I want to make accessible from within the Guardian Service to the outside world.
There must be a better way to decouple those things.
Any tips are appreciated.
Thank you.
I do not know the exact requirements for your project but I would say that what you are looking for is WCF Routing. I've used it in the past to redirect requests for different versions of Workflow instances.
The way it works is completely transparent to the client connecting to its endpoint. The router implementation must decide where to send the requests to, based on the request data (message headers and body).
In your case, if you are using SOAP and namespaces correctly, you might be able to base your decision on the message soap address and then send the request to the correct endpoint. You could also look at the Action property of the message.
Some links that might be useful:
http://msdn.microsoft.com/en-us/library/ee517423.aspx
http://www.codeproject.com/Articles/227699/RoutingService-on-Azure
I have two questions I hope I can get an answer for with regard to my service oriented application
I am creating a service oriented application where controls have no events, it's all done by calling services... that means the service url is written in my jQuery code, but this seems somehow not nice.... It's like what is the best option to save service urls?! I feel it's hard to maintain and not secure when it's written inside the page or inside javascript referenced file.
I am talking to a hosting company and they told me that I can host this application services on cloud server and the application on another servers.... not all in the same server, but my application services are self hosted, I mean the services are inside the application.... so to make things work as my hosting company wants, shall I host the restful services in IIS or how exactly?
Service URL must be in your page or script source file. It can be local address unless you are using cross domain calls and JSONP - cross domain calls requires absolute address. It is the same as any other web technology. If you want navigation to other page, you must provide URL. If you want some picture or css file you must provide URL. Security is up to you.
This will be the problem of cross domain calls. Normally JS calls can be done only to the same domain where the page is exposed. Once the application server is exposed on different domain name your calls will not work. To avoid that you must use JSONP (WCF 4 has support for that). Exposing rest services consumed by your application from self hosted application is strange. REST services are consumed by your clients - they are front-end services and should be part of your application hosted on front-end web server. Your back-end application server should not host anything directly accessible by your clients.
The question is as simple as the title. I have a webapp (I have no clue as to what technology it was built on or what appserver it is running on). However, I do know that this webapp is being served by an Apache Server/ IIS Server / IBM Http Server. Now, I would like to have a plugin/ module / add-on at the web-server end, which would parse/truncate/cut/regex the http response (based on the requested url's pattern), and mask(encrypt/shuffle/substitute) a set of fields in this response based on different parameters(user's LDAP permissions in the intranet / user's geo-location if on the internet, etc) and send the altered response back to the user.
So, Is there an easy answer to creating such plugins/modules/add-ons? How feasible is this approach of creating extra software at the webserver, when you want to mask sensitive information in a webapp without modfying the web-app code? Are there any tools that help you do this for Apache?
And, finally, is this just a really crazy thing to try?!
Each webserver will have its own way of doing so.
There is no universal plugin architecture for webservers.
In IIS you would write an HTTP Handler or HTTP Module, or possibly an ISAPI Filter. You can also directly interact with the http response using the Response object exposed by the HttpContext.
With apache, there are different modules that can do what you want (mod_headers, for example).
I don't know anything about WebSphere, but I am certain it also has similar mechanisms.
What you are asking is required by most web applications, so would be either built in or very easy to do.
The easiest way is to add a plug-in using the web application container. For example, if it's Tomcat, you can add a filter or valve.
If you want to plug-in to the web server, you'd need to write a custom module using the API of whichever web server is being used.
If all else fails, you could always wrap the entire server in a reverse proxy. All requests would go through your proxy and that would give you the opportunity to modify the requests and the responses.
I am currently working on a silverlight client, making use of a web server, and an application server.
Most of the users sit within our firewall, so they do not have any problems accessing the WCF service running on the application server (through a Service.svc file).
However, some users will sit outside of our firewall, and only have access to the web server, and not to the application server (Where the WCF service is).
I am hoping someone could tell me if there is a way for the client to use the WCF service on the application server, through the web server, without rewriting the WCF service on the web server, and only relaying the calls through that server.
I hope this is a clear enough description of what I need.
Thanks
Sounds like what you want is a router service. Unfortunately, there's nothing built-in into WCF to do that (at least until .NET 4.0 with its RoutingService.).
You can certainly build it yourself, either by building a specific, one-off routing service (i.e. you implement the same contract and manually forward each operation to the service inside the firewall), or by building a generic, reusable routing service.
If you choose the second option, a couple of articles might help get you started.
Rather than have your Silverlight clients accessing the application server directly, route all the requests through a proxy service on the web server.
An example of this is the "Cross Domain Proxy" pattern.