Vlad's blog

In programming veritas

Introduction to TPL Dataflow

leave a comment »

TPL Dataflow Library is one of underestimated libraries which have not gained as much popularity as other TPL components. I believe the main reason is a fact that Microsoft did not include Dataflow Library in the .NET Framework 4.5, you should install it separately. Anyway in this post I am going to quickly describe main features of TPL Dataflow and answer a question why and when you need to use this library.

TPL Dataflow Library is designed to help programmers write concurrent enabled applications. You may say that this is what TPL is all about. True, but Dataflow Library is supposed to be used in very specific scenarios. Imagine you are developing an application that has to process many request which is typical scenario for server side applications. And processing of a request involves many concurrent tasks: Web API calls, database transactions, file IO operations, image processing etc. Also you want to be able to control resource utilization in order to keep your server responsive. Certainly, you can do everything described above using TPL tasks, develop own queues for message prioritization and use synchronization primitives to protect shared data. TPL Dataflow provides a programming model that hides low level details of managing concurrent workflows and allows you to focus on your business logic.

Programming Model

The main concept in Dataflow is a block. You can consider a block as data structure that can buffer and process data. Normally your Dataflow application is a collection of linked blocks forming a workflow specific for your needs. Actual communication between blocks is organized in a form of messages passed from one block (source) to another (target). There are different types of blocks: data transform block, buffer block, action block. You can build a simple pipeline which is a linear sequence of blocks or network, which is a graph of blocks.

Common blocks

Transform block

Transform block is used to receive input value and return transformed value. In the example below TransformBlock receives user names and returns user photos.

var photoService = new PhotoService();
var transformBlock = new TransformBlock<string, Photo>(async userName =>
{
 Photo userPhoto = await photoService.GetUserPhoto(userName);

 return userPhoto;
});

Read the rest of this entry »

Written by vsukhachev

March 5, 2017 at 12:32 pm

Posted in Development

Tagged with ,

Web API versioning in real world applications

leave a comment »

Once you have published your API it is set in stone. Customers who use your API expect it to not change. Otherwise their code may fail due to changed contract or behavior. But requirements will change and we need to figure out a way to evolve API without breaking existing clients. So every time when a breaking API change occurs you need to release a new version of API. That does not mean you need to support all versions forever. But you need to get rid of old versions of API with some care so customers have an idea how to move to a newer version of API.
In this post I am going to discuss how Web API versioning affects entire application and provide some recommendations how to organize source code to maintain different versions of API.

Example project can be downloaded here.

Introducing test application

In order to illustrate API versioning strategies we are going to develop a simple Web API for retrieving tasks. A task contains Name, Description, Owner and task state attributes: IsStarted and IsFinished. Each task belongs to particular Project which is barely a container of tasks. Application consists of three layers:

  • Domain layer that includes Task and Project definition
  • Data access layer that defines TaskRepository class. TaskRepository uses domain classes in serialization.
  • Distributes services layer defines DTO’s used by TaskController

versioning-domain

Read the rest of this entry »

Written by vsukhachev

December 12, 2016 at 10:37 am

Posted in Development

Tagged with

OAuth 2 flows: Client flow

leave a comment »

Client flow is used solely for machine to machine communication, i.e. no Resource Owner involved. Client sends client_id and secret to Authorization Server and then receives access_token and refresh_token.

Client.png

This type of flow is usually used when Web application needs to access Web API.

Written by vsukhachev

December 3, 2015 at 2:51 am

Posted in Development

Tagged with

OAuth 2 flows: Resource Owner Credentials flow

leave a comment »

This type of flow is used when Resource Owner trusts the Client. Client might be mobile application, desktop application or browser application communicating with Web server. Device where Client is installed is trusted as well so user name and password can be stored on this device. In this flow Resource Owner enters user name and password in the UI provided by Client. Then Client sends POST request to Authorization server. The request contains entered user name and password.

Resource Owner Credentials Flow-1

Authorization Server responds with access_token and refresh_token.

Resource Owner Credentials Flow-2

access_token is included in each request that Client sends to Resource Server.

Resource Owner Credentials Flow-3

When access_token is expired Client can repeat this procedure, i.e. send user name and password and collect new access token or it can use refresh_token. Ideally Client should not store user credentials. Instead it should ask for user credentials once, collect refresh_token and then use it forever to obtain new refresh_token. access_token and refresh_token might be stored on a device.

Written by vsukhachev

December 3, 2015 at 2:51 am

Posted in Development

Tagged with

OAuth 2 flows: Implicit flow

leave a comment »

Implicit flow is probably the most common scenario. It is used when Client is mobile application (IOS, Android, Windows Phone) or native application or browser mobile application which wants to access resource on the behalf of Resource Owner.

Implicit Flow-1

Resource Server redirects application to Authorization Server. client_id identifies application, redirect_uri specifies Uri where Client will be redirected after authorization completed.

Implicit Flow-2

Then Authorization Server asks user to authorize. Depending on particular implementation (Google, Twitter, Facebook) the login screen might look different.

Google Login Screen

The next step is Consent screen where Resource Owner will be prompted to allow application to perform certain actions.

Google consent screen

When authorization is complete the Authorization Server executes redirect_uri passing access token and expiration interval.

Implicit Flow-3

Notice that access_token and expires_in are specified after pound character which assumes that they never passed to the Resource Server. So Client can extract access_token and include it in the next requests.

Implicit Flow-4

This flow does not use refresh token since this implies that user name and password must be stored on a device which can not be considered as secured. So user should periodically repeat the authorization procedure.

Written by vsukhachev

December 3, 2015 at 2:50 am

Posted in Development

Tagged with

OAuth2 flows: Authorization flow

leave a comment »

Authorization flow is usually used when Resourse Owner communicates with Web server which accesses another RESTful web service on behalf of the Resource Owner.
Authorization Flow-1
Client redirects Resource Owner to Authorization Server. In the url Client specifies client_id which is how Authorization Server identifies the Client. Assumed that Client was previously registered on the Authorization server. Also Client specifies redirect_uri which Authorization Server will use when Resource Owner authorization is complete.
Authorization Flow-2
Then Authorization Server asks user to authorize. Depending on particular implementation (Google, Twitter, Facebook) the login screen might look different.
Google Login Screen
The next step is Consent screen where Resource Owner will be prompted to allow application to perform certain actions.
Google consent screen
When authorization is complete the Authorization Server redirects Resource Owner back to the Client.
Authorization Flow-3
It passes code parameter but this is not a token yet. This code will be used by Client which will send a request to Authorization Server.
Authorization Flow-4
Authorization Server responds with access token, refresh token and expiration time in seconds.
Authorization Flow-5
So now Client can access Resource Server by using access token.
Authorization Flow-6
As you can see access token time life is very short. So when it is expired there are two options. Client can start this procedure over or use refresh token to request new access token.
So Authorization flow has the following features.

  • Used for server side applications
  • Resource owner never gets access token so it can not leak
  • If access token is expired it can be requested again using refresh token

Written by vsukhachev

November 15, 2015 at 3:28 am

Posted in Development

Tagged with

OAuth 2 flows: introduction

leave a comment »

This post starts series of posts dedicated to OAuth2 flows. But before we begin I would like to provide some background. First I want to say some words why we need OAuth2 and which problems it is supposed to solve.
OAuth 2.0 is open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.
Let’s start from the traditional example of using web forms authentication. In form authentication there are two roles: Browser and Server. Browser starts conversation by sending user name and password entered by user. Server authorizes this request and responds with authentication ticket representing user credentials. Browser saves the ticket in the users cookie collection and then sends this cookie in every request.
This approach works fine for browser based application but what about mobile application? Usually mobile applications don’t maintain collections of cookies. And described approach assumes that application is responsible for authentication and authorization. The scenario when user needs to create new password for every mobile application is not realistic. Today users prefer to use their Facebook or Google credentials to identify them-self. But this approach raises a question. Will user trust newly downloaded application to let it use his Facebook user name and password? The answer is obvious, no. So we came to the conclusion that authentication and authorization should be separated from application. And that is where federated security comes into play.

OAuth 2 roles

OAuth2 defines the following roles.

  • Resource Owner is a human that owns a resource on the Resource Server
  • Resource Server is the server hosting the protected resource
  • Client is an application making protected resource requests on the behalf of the resource owner
  • Authorization Server is the server that issues access tokens to the Client

The term Client does not refer to any particular implementation characteristics. For example Client can be mobile application or desktop application or server side application making requests to Web API.

OAuth roles

OAuth 2 flows

Written by vsukhachev

November 15, 2015 at 3:28 am

Posted in Development

Tagged with