Monthly Archives: June 2016

Mongo Shell – Display More than 20 records

How to print out more than 20 items (documents) in MongoDB’s shell?

Simple use this command on Mongo Shell

DBQuery.shellBatchSize = 300




CORS and Web API 2

Browser security prevents a web page from making AJAX requests to another domain. This restriction is called the same-origin policy, and prevents a malicious site from reading sentitive data from another site. However, sometimes you might want to let other sites call your web API. Cross Origin Resource Sharing (CORS) is a W3C standard that allows a server to relax the same-origin policy. Using CORS, a server can explicitly allow some cross-origin requests while rejecting others. It’s important to understand that same-origin policy does not prevent the browser from sending the request. Instead, it prevents the application from seeing the response.

To enable CORS in Web API install the core nuget package
Install-Package Microsoft.AspNet.WebApi.Cors

In App_Start inside WebApiConfig.cs class add following where config is HttpConfiguration.



On the Controller action u can use the

[EnableCors(origins: "", 
          headers: "*", methods: "*")]

add following namespace to your controller

using System.Web.Http.Cors;

this allows CORS request coming only from

The CORS specification introduces several new HTTP headers that enable cross-origin requests. If a browser supports CORS, it sets these headers automatically for cross-origin requests; you don’t need to do anything special in your JavaScript code. The Origin header gives the domain of the site that is making the request.

If the server allows the request, it sets the Access-Control-Allow-Origin header. The value of this header either matches the Origin header, or is the wildcard value *, meaning that any origin is allowed.

If the response does not include the Access-Control-Allow-Origin header, the AJAX request fails. Specifically, the browser disallows the request. Even if the server returns a successful response, the browser does not make the response available to the client application.

Scope Rules for [EnableCors] – You can enable CORS per action, per controller, or globally for all Web API controllers in your application. If you set the attribute at more than one scope, the order of precedence is: Action, Controller, Global.

Passing Credentials in Cross-Origin Requests – Credentials require special handling in a CORS request. By default, the browser does not send any credentials with a cross-origin request. Credentials include cookies as well as HTTP authentication schemes. To send credentials with a cross-origin request, the client must set XMLHttpRequest.withCredentials to true. In addition, the server must allow the credentials.

To allow cross-origin credentials in Web API, set the SupportsCredentials property to true on the [EnableCors] attribute.

[EnableCors(origins: "", 
headers: "*", methods: "*", 
SupportsCredentials = true)]

Something @ Microservices…

Application architectures have evolved over years in various ways like shown below


So as you can see idea behind micro services is to divide a large monolithic web app to smaller pieces.


So why Microservices?

  • Build and operate service at scale
  • Improved resource utilization to reduce cost (especially considering cloud deployments)
  • Fault Isolation
  • Continuous Innovation
  • Small Focus teams (e.g. ‘two-pizza team’: If you can’t feed a team with two pizzas, it’s too large.
  • Can be written in any language and framework.

What are Microservices?

Microservices are…

  • Autonomous – A microservice is a self-contained unit of functionality with loosely coupled dependencies on other services.
  • Isolated – A microservice is a unit of deployment that can be modified, tested and deployed as a unit without impacting other areas of a solution
  • Elastic – A microservice can be stateful or stateless and can be scaled independently of other services
  • Resilient – A microservice is fault tolerant and highly available
  • Responsive – A microservice responds to request in a reasonable amount of time
  • Intelligent – The intelligence in a system is found in the endpoints not on the wire. ESB is an anti-pattern to Microservices.
  • Message Oriented – Microservices rely on asynchronous message-passing to establish a boundary between components and Applications are composed from multiple microservices
  • Programmable – Microservices provide API’s for access by developers and administrators
  • Configurable – Microservices provide an API and/or a console that provides access to administrative operations
  • Automated – The lifecycle of a microservice is managed through automation that includes dev, build, test, staging, production and distribution


  • Evolutionary – Can be developed alongside existing monolithic applications providing a bridge to a future state
  • Open – Language agnostic APIs, Highly decoupled
  • Resilient – No monolith to fall over, designed for failure
  • Speed of Development – Adding, updating and maintaining services and can be done at velocity
  • Reuse – Reusable and Composable
  • Deployment Governance – Services are deployed independently
  • Scale Governance – On-demand scaling of smaller services leads to better cost control
  • Replaceable – Services can be rewritten and replaced with minimal downstream impact
  • Versioned – New API’s can be released without impacting clients that are using previous API’s
  • Owned – Microservices are typically owned by one team from development through deployment

Challenges with a Microservices Approach

  • Communication is Key – Communication across teams becomes critical
  • Automation is not an Option – Speed of change requires investment in automation
  • Platform Matters – Your platform must support elastic scale and resilience.
  • Versioning must be Supported – Composability requires versioning
  • Testing – Unit, inter-service, extra-service, composition testing
  • Discoverability – The ability to locate services in a distributed environment without being tightly coupled

Symmetric and Asymmetric keys cryptography…

  • Asymmetric Key encryption, also known as public/private key encryption, it utilizes a pair of keys – a public key and a private key. If you encrypt data with the public key, only the holder of the corresponding private key can decrypt the data, hence ensuring confidentiality. Online transaction systems rely on asymmetric encryption to establish a secure channel. SSL, for example, is a protocol that utilizes asymmetric encryption to provide communication security on the Internet. An asymmetric encryption algorithms typically involve exponential operations, they are not lightweight in terms of performance. For that reason, asymmetric algorithms are often used to secure key exchanges rather than used for bulk data encryption.
  • Symmetric encryption – As the name suggests, means that the encryption and decryption operations utilize the same key. For two communicating parties using symmetric encryption for secure communication, the key represents a shared secret between the two. Symmetric encryption is typically more efficient than asymmetric encryption, and is often used for bulk data encryption.

SSL typically uses Asymmetric public private keys for initial hand shake and then later utilizes Symmetric key for for further communication post hand shake.

SSL has been explained in earlier blog post