In our WCF Web service, we recently solved a customer's problem by adding <serviceHostingEnvironment multipleSiteBindingsEnabled=”true”> to the application's configuration file. This allowed the service to operate correctly, when IIS was configured with multiple bindings for the site containing the Web service, meaning that the Web service had multiple base addresses.
The question now is whether this setting is a good idea for all installations of our product. Does it have any downsides? If not, why is it not the default in WCF?
I have done some Web-searching and found multiple people explaining reasons why one should include this setting, but the only downside that I found was to do with "relayed endpoints", which are a concept with which I am unfamiliar and therefore something that I don't believe we are using.
I dont know what problem you solved enabling multipleSiteBindingsEnabled however if you are using multiple base url e.g. one for external users and one for internal users and you want to keep one of urls secrete then enabling multipleSiteBindingsEnabled will defy that purpose as all base address will be listed in WSDL/MEX information generated by the service. This could be one flip side of enabling multiple site bindings.
Related
I have a self-hosted WCF service, which is available from all computers of the company. This has a standard landing page ("You have created a service. To test this service..."). I want to make sure that this landing page and the WSDL links on it are only accessible from the local server, as the information contained there could potentially be a security risk.
What is the easiest way to make sure that any URL that is not tied to a service is only accessible from localhost?
Please note that I do not want to change the contents of the landing page, as the WSDL links are useful for developers.
I am interested in solutions that involve modifying the app.config or limiting access via code.
As far as I know you can't selectively grant access to WSDL/Test WCF pages only by config or code. You can disabled it or not.
You could implement some sort of rules at IIS level to prevent access from non local addresses, but would make the question more suitable for Super Admin, probably.
If WSDL and/or service description pages public are secutiry issue, though, maybe you need to rethink your services security. Methods should be secured by authentication/authorization of some sort (usually via tokens). If anyone can post to your method and run code without proper authorization, having the interface description public is the last of your problems.
PS: if needed for devs, you can generate static versions of WSDLs to be served from user/password protected path.
This seems like a duplicate question - but after hours of search, it seems there is no clear question-answer which summarize the issues i'm raising here.
We have a web application (built using asp.net MVC4) which stores customers sensitive customer information.
We've decided to migrate our entire application to https.
My question is, except for the IIS and certificates technical issues, which we've already know how to deal with, what should be changed on code level?
What will happen for instance for:
Included external scripts containing http, such as: http://code.jquery.com/jquery-1.7.1.min.js - will it work automatically without any problem and popup messages or blocking on the client browsers?
Internal links, which we've forgotten to change, which redirect to our site using http?
Images/Sources which have http in their URL.
Should we change all references from http to relative, or just specifying // without the http/https protocol ? (as seen on other posts on this subject)
Should we do nothing, will it happen automatically?
Is there a way to do something in IIS or Global.asax etc, in order to automatically take care of all http leftovers?
What else should we take in account when migrating to https?
Thanks in advance.
For all internal static resources hopefully you have used #Url.Content helper and for all internal dynamic resources you have used #Html.ActionLink, #Html.BeginForm, ... helpers to generate the links. This way you don't need to worry about anything.
For all external resources you could use // syntax in the link which will respect the protocol.
Since you are switching to HTTPS you might consider marking all your cookies (if any) with the secure flag to ensure that they are transmitted only over a secure channel.
i have a WebRole in my Windows Azure Deployment with a few instances. In this Roles i do a lot of caching. So my client asks everytime another instance for a specific information, which is maybe not stored on the requested instance. All my cached informations got a "instance"-property, so i can route my request in the cloud to the specific instance (via internal endpoints).
Is there a way to get a URL for my instance and not my deployment?
Something like:
instance1.mydeployment.cloudapp.net?
I think something would be really helpful.
Thank you.
Yes, there is. I'm not sure what SDK it came in, but in your csdef file you can alter your normal endpoints section to look like this
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" localPort="80" />
<InstanceInputEndpoint name="Endpoint2" localPort="80" protocol="tcp"><!--localPort must be 80 for this to work-->
<AllocatePublicPortFrom>
<FixedPortRange min="10016" max="10020"/> <!--make a range that covers the # instances you might need or scale too - bear in mind azure port limits ~25 -->
</AllocatePublicPortFrom>
</InstanceInputEndpoint>
</Endpoints>
Now you should be able to access both
http://myapp.cloudapp.net:10016
http://myapp.cloudapp.net:10017
Your approach is very similar to the sticky session issue with Tomcat servers. Since you live in a .NET world I highly suggest that you change your architecture to not relay on this sticky routing.
If you really want to achieve that specific goal (which I don't imagine why one would want), it is possible through Application Request Routing. It is not easy, but it is feasible. you can read here about how to install ARR on Azure Web Role. But you have to maintain automatic configuration and reconfiguration of ARR, especially when you add or remove instances.
Frankly, the whole idea of sticky sessions is broken. Even if you manage to handle automatic installation and configuration of ARR, tell me what will happen when the Azure Fabric controller takes 1 instance down for Guest OS Update. What will happen to your users that were served by that instance?
I'd suggest you to use distributed Windows Azure Caching as a ready robust solution for sharing cached data between instances.
As far as I know, you can not get separate URLs for individual instances.
EDIT: the following answers might help:
Azure Web Role Internal Endpoint - Not Load Balanced
Take a look at this example: http://blog.maartenballiauw.be/post/2011/10/21/Running-Memcached-on-Windows-Azure-for-PHP.aspx
I know, it is a tutorial for PHP and memcache but it uses InternalEndpoint for Role Communication via TCP. Maybe it helps you to understand, how to fix your problem.
I'm using ServiceStack but am not sure how to approach what must be simple and common concepts. Perhaps this should be posted as two separate questions.
How would I provide the server URL to the client? It's not inherently a ServiceStack problem but would like to know if there's something out of the box which I've missed. I'm thinking either through a config file for a client desktop application or perhaps a web service discovery mechanism, if such a thing exists.
edit: I am referring to the base / root URL of the server, where the clients are desktop applications (in some cases deployed in house). Most ServiceStack examples use a hard coded "localhost:82". So a mechanism to discover the real URL is needed..
To generate a RESTful service I would like to provide links (href's) so that a client could potentially navigate without knowing too much about the service. Is there a simple way to do this? Is it a matter of extending my response DTOs and pushing these details? From a separation of concerns POV it doesn't feel like the best way to do this.
Thanks!
I think that the built in ServiceStack metadata page can help you out on both accounts. It should be available to you automatically at http//:[service_root]/metadata. For example:
http://www.servicestack.net/ServiceStack.Northwind/metadata
You could provide this URL to a customer, and they should be able to interact with the service without issue. It provides detailed information on all service operations, different ways to call them, and even sample request/responses in supported content-types.
You can provide operation descriptions to help clarify even further by decorating your request DTOs with the [Description] attribute.
[Description("This is a service description for thinger.")]
public class Thinger
{
}
I have two web sites in IIS like
http://domainA.com
http://domainB.com
I would like to use the same code for these web sites but a different web.config files. Is this possible? I store database connectionstrings etc in the web.config files, all the other code in the applications are the same.
I have tried some different approches with creating a folder structure like
-Root
- Domain A
- web.config for domain A
- Code
- Virtual Directory to Source Code
- Domain B
- web.config for domain B
- Code
- Virtual Directory to Source Code
- Source Code
I will then point the website for domain A to "Root/Domain A" and domain B to "Root/Domain B" but the problem is then that the code must be accessed one level down, like
http://domainA.com/Code/
http://domainB.com/Code/
Any ideas?
I will base my answer on the assumption that you are writing custom code rather than using an out of the box solution such as DNN or SharePoint.
One solution that comes to mind to keep a common code base is to maintain your website specific configuration settings in your database instead of the web.config. You can keep your database structure fairly dynamic by using a set of name/value pairs. You would of course need to take this into account in the design of your application and plan for it in your database. This gives you the advantage of only having a single code base as well as a single web.config. If you need to maintain content in separate databases for each site, the connection string info to those content databases can be one of the name/value pairs in your configuration database.
You can even take this one step further by having a single website in IIS for all domains as well (unless you will be using SSL, in which case separate IIS sites would be better). You would need to add host headers to the website and then look for the host header in your code to determine what settings to use and what content to serve. You would lose the ability to create separate app pools so you should check your requirements if this is a feasible option for your situation.
This is actually a similar model to how both DNN and SharePoint work but can certainly be done in a custom application as well.