Skip to main content

Losing control of your web application in the world of nearshore IT model

In this post, I will share with you a story about why it is so important to be aware of any 3rd parties dependencies and how you manage the ownership and access control to them.

Starting a few years ago it becomes widespread to integrate your web application with 3rd parties identity providers like Facebook, Google or Twitter. From the consumer perspective, it is more straightforward to have only one identify and use it on multiple web application versus having different accounts and password for each application.
Let’s take Facebook as an example where to be able to do such an integration you need to create a Facebook App that it is used as the authentification and authorization layer for your app. The application can be created by a normal Facebook Account that becomes the Administrator of the Facebook App.

In most of the cases, the company that owns the web application does not have IT capabilities and use an external company to implement the web application and manage the Facebook account. Everything is going as planned until in the moment the company decides to change the IT provider that manages the web application.
In general, you have a contract with the IT provider that it is offering IT services. The source code of the web application it is own by you, the custom DNS name and HTTPS certificates are own by you also, the same thing applies for other dependencies. However, you might forget to add in the contract the 3rd parties applications, that from an ethical perspective are own by the customer. The perfect example here is the Facebook App. Why? Because the IT company might claim the rights on it and give you headaches once you are not their customer anymore.


This is the following case that I had to manage:

  • A company is subcontracting an IT company to develop a Web Application. 
  • The Web Application authentication and authorization mechanism it is only based on Facebook.
  • A Facebook Application is created to handle this by the IT company. 
  • From the IT company, an employee is using his own personal account to create and manage the Facebook App.
  • The web application goes live for a while
  • The customer decides to change the IT company that offers support


This is the moment when things become ugly. The previous IT company disable the Facebook application. Guess what? The web application becomes unusable, and the customer is losing money.
After long discussions, they are accepting to enable the Facebook App for 30 days, but they are refusing to add as an administrator of the Facebook, the real owner of the Facebook App.
Remember: It is important to know that an administrator of a Facebook App can add another administrator. Besides this, an administrator can remove the previous administrators.
Even if creating a new app might be a solution, because you cannot migrate users from one Facebook App to another, you cannot do a user’s migrations. Using user email address that you already store in the web application you might find solutions to link a new user registration with previous data. These come at an extra cost and a risk to do something wrong and have users that don’t have the old data merged with the new account. It can become a disaster when users are paying a monthly fee to have access to the web application, and you need to do manual actions to merge the accounts. These risks combine with a high volume of users (let’s say 50.000 unique register users) it’s a good receipt for disaster.

Lesson learned
From a contractual point of view you shall always ensure that besides source code, all 3rd party applications and systems are own by the customer and not by the IT company that offers support. In this way, from a legal perspective, you can secure the Facebook Application that it is own by you (the customer) and not by the IT company that you subcontracted.

Additional to this on all 3rd party systems you should manage them using dedicated accounts and not a personal account. In the case of Facebook App, you need to create a Facebook Account that is owned by the customer and has full rights to the Facebook App. Depending on the policy that you want to use you might share the account with the IT company or add additional administrators to the app.

The most important thing that needs to be done is to ensure that you the 3rd party applications are managed using accounts and channels that are own by the customer and not by IT company that is offering support. The legal owner of the system shall ensure that has full control over their systems.


Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.