Calling WebAPI service from Windows Phone 8 using HttpClient – Addendum

I’ve noticed that allot of people have visited here to view the entry on Calling WebAPI service from Windows Phone 8 using HttpClient. Since writing it I’ve significantly extended the BaseService class that I wrote for it and thought I should share it online.

So here is a further example of an implementation showing how to call a WebAPI service from Windows Phone (or really any other location).

public abstract class BaseService
{
    private readonly string _BaseAddress;

    //Provide the address however you want
    public BaseService()
        : this("http://192.168.1.4:69/")
    {
            
    }

    public BaseService(string BaseAddress)
    {
        this._BaseAddress = BaseAddress;
    }

    /// <summary>
    /// Create an instance of the HttpClient class and return it.
    /// </summary>
    /// <param name="BaseAddress">The base address of a location to call i.e. http://192.168.1.1:69/ (The service path is provided later)</param>
    /// <returns>System.Net.Http.HttpClient with base address and timeout set</returns>
    private static HttpClient GetHttpClient(string BaseAddress)
    {
        HttpClient client = new HttpClient();
        client.BaseAddress = new Uri(BaseAddress);
        client.Timeout = new TimeSpan(10000000 * 20); //seconds
        return client;
    }

    /// <summary>
    /// Invoke get request with path and parameter and return result.
    /// </summary>
    /// <typeparam name="T">Type to be returned</typeparam>
    /// <param name="Path">Service Path i.e. /Services/Service</param>
    /// <param name="Parameter">Any object that implements ToString() correctly</param>
    /// <returns>Task Of T</returns>
    protected async Task<T> GetServiceAsync<T>(string Path, object Parameter)
    {
        return await BaseService.GetServiceAsync<T>(this._BaseAddress, Path, Parameter);
    }

    /// <summary>
    /// Invoke get request with path and parameter array and return result.
    /// </summary>
    /// <typeparam name="T">Type to be returned</typeparam>
    /// <param name="Path">Service Path i.e. /Services/Service</param>
    /// <param name="ParamArray">Any parameter array that implements ToString() correctly</param>
    /// <returns>Task Of T</returns>
    protected async Task<T> GetServiceAsync<T>(string Path, params object[] ParamArray)
    {
        return await BaseService.GetServiceAsync<T>(this._BaseAddress, Path, ParamArray);
    }

    /// <summary>
    /// Invoke get request with path and parameter array and return result.
    /// </summary>
    /// <typeparam name="T">Type to be returned</typeparam>
    /// <param name="BaseAddress">Base address path to be called</param>
    /// <param name="Path">Service Path i.e. /Services/Service</param>
    /// <param name="ParamArray">Any parameter array that implements ToString() correctly</param>
    /// <returns>Task Of T</returns>
    protected async static Task<T> GetServiceAsync<T>(string BaseAddress, string Path, params object[] ParamArray)
    {
        using (HttpClient client = BaseService.GetHttpClient(BaseAddress))
        {
            string actionUrl = string.Format("{0}{1}", Path, MvcUtilities.BuildWebApiRequest(ParamArray));
            HttpResponseMessage response = await client.GetAsync(actionUrl);
            response.EnsureSuccessStatusCode();
            T result = await response.Content.ReadAsAsync<T>();
            return result;
        }
    }
        
    /// <summary>
    /// Invoke put request with path and parameter and return result.
    /// </summary>
    /// <typeparam name="T">Type to be returned</typeparam>
    /// <param name="Path">Service Path i.e. /Services/Service</param>
    /// <param name="Obj">Any object that implements ToString() correctly</param>
    /// <returns>Task Of T</returns>
    protected async Task<T> PutServiceAsync<T>(string Path, object Obj)
    {
        return await BaseService.PutServiceAsync<T>(this._BaseAddress, Path, Obj);
    }

    /// <summary>
    /// Invoke put request with basepath, path and parameter and return result.
    /// </summary>
    /// <typeparam name="T">Type to be returned</typeparam>
    /// <param name="BaseAddress">Base address path to be called</param>
    /// <param name="Path">Service Path i.e. /Services/Service</param>
    /// <param name="Obj">Any object that implements ToString() correctly</param>
    /// <returns>Task Of T</returns>
    protected async static Task<T> PutServiceAsync<T>(string BaseAddress, string Path, object Obj)
    {
        using (HttpClient client = BaseService.GetHttpClient(BaseAddress))
        {
            HttpResponseMessage response = await client.PutAsJsonAsync(Path, Obj);
            response.EnsureSuccessStatusCode();
            T result = await response.Content.ReadAsAsync<T>();
            return result;
        }
    }

    /// <summary>
    /// Invoke post request with basepath and path return result.
    /// </summary>
    /// <typeparam name="T">Type to be returned</typeparam>
    /// <param name="Path">Service Path i.e. /Services/Service</param>
    /// <param name="Obj">Any object that implements ToString() correctly</param>
    /// <returns>Task Of T</returns>
    protected async Task<T> PostServiceAsync<T>(string Path, object Obj)
    {
        return await BaseService.PostServiceAsync<T>(this._BaseAddress, Path, Obj);
    }

    /// <summary>
    /// Invoke post request with basepath, path and parameter and return result.
    /// </summary>
    /// <typeparam name="T">Type to be returned</typeparam>
    /// <param name="BaseAddress">Base address path to be called</param>
    /// <param name="Path">Service Path i.e. /Services/Service</param>
    /// <param name="Obj">Any object that implements ToString() correctly</param>
    /// <returns>Task Of T</returns>
    protected async static Task<T> PostServiceAsync<T>(string BaseAddress, string Path, object Obj)
    {
        using (HttpClient client = BaseService.GetHttpClient(BaseAddress))
        {
            HttpResponseMessage response = await client.PostAsJsonAsync(Path, Obj);
            response.EnsureSuccessStatusCode();
            T result = await response.Content.ReadAsAsync<T>();
            return result;
        }
    }

}

public class BaseServiceException : Exception
{
    public BaseServiceException() { }
    public BaseServiceException(string Message) : base(Message) { }
    public BaseServiceException(string Message, Exception InnerException) : base(Message, InnerException) { }

}
Advertisements

Microsoft MVC5 + ASP.NET Identity with Telerik OpenAccess Awesomeness

Microsoft’s new membership system ASP.NET Identity is (IMHO) absolutely fantastic! The system itself comes installed as the default provider in Visual Studio 2013 for ASP.NET templates and can be downloaded for use within Visual Studio 2012.

ASP.NET Identity is the next step in the evolution to what was previously known as the SimpleMembership and Membership providers. Previous versions have been extremely brittle; this new approach simplifies and segments the membership provider in such a way that it makes it incredibly easy to plug-in and remove the components as you require and more importantly simplifies development when implementing a separation of concerns in a Service Oriented Architecture. Anyone who has attempted to achieve this with WCF and the previous membership providers will know the difficulties and lack of clear process through which to accomplish this. Another major benefit is that the framework implements all the .NET Async goodness by default. While you could always create your own Async wrappers in the older providers it makes things easier to see this functionality implemented for you.

The problems with the original ASP.NET Membership provider were:

  1. Designed for SQL Server and you can’t change it. You can add profile information, but the additional data is packed into a different table, which makes it difficult to access by any means except through the Profile Provider API.

  2. The provider system enables you to change the backing data store, but the system is designed around assumptions appropriate for a relational database.

  3. Since the log-in/log-out functionality is based on Forms Authentication, the membership system can’t use OWIN.

As the Introduction to ASP.NET identity article goes on to say

Simple Membership did make it easier to customize user profile information, but it still shares the other problems with ASP.NET Membership, and it has some limitations such as:

  • It was hard to persist membership system data in a non-relational store.
  • You can’t use it with OWIN.
  • It doesn’t work well with existing ASP.NET Membership providers, and it’s not extensible.

So, how is ASP.NET Identity different? Well…..

1. Storage backend is completely separate

Complete and total separation of the storage mechanism used within the provider. For example implement your own storage back-end but use something other than the entity framework? Or you want to use some type of NoSQL implementation (such as Azure Tables) or even just an Xml file? Well all you need to do¹ is implement the IUser and the IUserStore interfaces, inject it into your UserManager and you’ve got your own custom storage provider.

Example.

protected void CreateUserManager()
{
    //Create a new user manager based on your User model, inject your UserStore and finally your ORM context
    UserManager<AspNetUser> Manager = new UserManager<AspNetUser>(new OpenAccessUserStore(new EntitiesModel()));

    //Now inject the validator
    Manager.UserValidator = new UserValidator<AspNetUser>(Manager)
    {
        AllowOnlyAlphanumericUserNames = false
    };

    //And set a property so you can use the UserManager when required
    this.UserManager = Manager;
}

//Public property to access your UserManager instance.
public UserManager<AspNetUser> UserManager { get; private set; }

Note that all you need to do to create a basic IUserStore and IUser is implement this.

public interface IUserStore<TUser> : System.IDisposable where TUser : Microsoft.AspNet.Identity.IUser
{
    System.Threading.Tasks.Task CreateAsync(TUser user);
    System.Threading.Tasks.Task UpdateAsync(TUser user);
    System.Threading.Tasks.Task DeleteAsync(TUser user);
    System.Threading.Tasks.Task<TUser> FindByIdAsync(string userId);
    System.Threading.Tasks.Task<TUser> FindByNameAsync(string userName);
}

AND THIS

public interface IUser
{
    string Id { get; }
    string UserName { get; set; }
}

2. General decoupling

Previously the provider implementation was extremely closely coupled between its various ‘bits’. The result would often cause confusion about which methods to invoke and under what circumstances (at least for me). Sometimes all you’d want to do is authenticate, sometimes you want to authenticate and sign in and sometimes you want to go straight to the database and just retrieve some bit of User info. Because of this change of implementation it’s been significantly easier to build a project using this provider and integrate it with WCF cleanly. In part this is because it’s now much easier to say, “Give me all claims for this user.” then “Authenticate the following claims.”. They are completely different subsystems and have no direct inter-dependencies.

3. Unit Testing

Clear interface based contracts between the various components of the framework make dependency injection and unit testing much simpler.

4. Claims based

While roles still exist within ASP.NET Identity the emphasis to a claims based authentication seams clear. Claims are useful because they abstract the individual elements of identity and access control into two parts. Unless you’ve got a reason not to, I suggest it makes sense to use claims rather than roles.


Finally I’ve gone ahead and built a generic Visual Studio project template extension which shows how to integrate MVC5 with ASP.NET Identity behind WCF webservices and utilizing Telerik OpenAccess ORM for the storage provider (Because OpenAccess kicks ass…) and deployed it to the Visual Studio Gallery for everyone to use or if you prefer just a straight download of the files.

The project itself demonstrates a number of things including:

  1. How to create a NetTCP WCF service without autogenerated proxy classes.
  2. How to use ASP.NET Identity in a WCF service
  3. How to use a different ORM as an alternative to the entity framework
  4. How to include System.ComponentModel.DataAnnotations in a portable class library for your Views.
    1. Which allows the ability to use them across your MVC, WCF, Windows Phone and Xamarin applications.

Hopefully someone else will find the template and source code useful!


  1. It’s not quite that simple (you might need to implement between 1 and like 10,000,000 interfaces), but almost!

Using WebMatrix, WCF and “You must call the WebSecurity.InitializeDatabaseConnection method before you call any other method of the WebSecurity class.” error

As an addendum to my previous post regarding using WebMatrix in WCF you may run into a situation where you receive the error “You must call the WebSecurity.InitializeDatabaseConnection method before you call any other method of the WebSecurity class.” 

Should such a situation arise you might quickly discover that simply placing the initialization code into the Application_Start event handler as you normally would does not work. This is because Application_Start is part of the http pipeline and will only get invoked if a http request is made.

So whats the solution? A little known feature of the App_Code folder which basically allows you to create a global Application Start hook regardless of protocol exactly like you assume the Application_Start handler is doing. This is done by implementing any class that contains a static void AppInitialize().

In other words you can then do this.

public class App
{
    private static SimpleMembershipInitializer _initializer;
    private static object _initializerLock = new object();
    private static bool _isInitialized;

    //This is the key, any class that implements this method that lives in the App_Code folder will work
    public static void AppInitialize()
    {
        LazyInitializer.EnsureInitialized(ref _initializer, ref _isInitialized, ref _initializerLock);
    }

    public class SimpleMembershipInitializer
    {
        public SimpleMembershipInitializer()
        {
            if (!WebSecurity.Initialized)
                WebSecurity.InitializeDatabaseConnection("DefaultConnection", "UserProfile", "UserId", "UserName", autoCreateTables: true);
        }
    }

}

And that’s it, you should be all good…

Using WebMatrix, SimpleMembershipProvider in WCF service and the “This method cannot be called during the application’s pre-start initialization stage” error.

Having made the transition to using MVC architecture for all my new applications I recently came across a situation where I needed to use the WebMatrix membership provider within my WCF services. It wasn’t a trivial process so I thought I would document it here.

So how do you get access to the SimpleMembershipProvider in WCF?

First add the references to the WebMatrix dlls

references

Second add the Web.Config reference in system.web as such

<membership defaultProvider="SimpleMembershipProvider">
  <providers>
    <add
      name="SimpleMembershipProvider"
      type="WebMatrix.WebData.SimpleMembershipProvider, WebMatrix.WebData"
      connectionStringName="MyApplicationConnectionString"
      applicationName="MyApplicationName"
      enablePasswordRetrieval="false"
      enablePasswordReset="true"
      requiresQuestionAndAnswer="false"
      requiresUniqueEmail="true"
      passwordFormat="Hashed" />
  </providers>
</membership>

Making sure you select your defaultProvider as SimpleMembershipProvider.

Lastly make sure the required assemblies are referenced in the web.config system.web.compilation.assemblies section as such.

<compilation debug="true" targetFramework="4.5">
  <assemblies>
    <add assembly="WebMatrix.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add assembly="WebMatrix.WebData, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
  </assemblies>
</compilation>

and at that point you should be able to do this.

SimpleMembershipProvider provider = (SimpleMembershipProvider)System.Web.Security.Membership.Provider;

and use the provider now as you as you normally would i.e. ValidateUser(), ChangePassword() etc…

However at this point I ran into an issue where the following error appeared. “Parser Error Message: This method cannot be called during the application’s pre-start initialization stage.”. The solution to this problem was the following StackOverflow post and adding the these into my appSettings.

<appSettings>
  <add key="autoFormsAuthentication" value="true"/>
</appSettings>

Which successfully fixed the problem and everything worked at that point.

Always use ChannelFactory when referencing WCF services (particularly for Azure)

Given the indeterminate nature of the IP addresses of Azure web roles (There are a number of exceptions to this but in general) you end up in a real pickle if you you use the Service Reference functionality built into Visual Studio that most of us regularly do.

(This thing)

Image

Truthfully, the way the proxy service references have always worked had its flaws despite its convenience.

The problem boils down to two things. First, if you’re correctly using WCF services you should be binding to DataContracts and Interfaces rather than any concrete implementations anyway. Secondly, you’re stuck with hard-coded values that live in your web.config, with what is inherently dynamic and often not known at compile time (ip addresses).

So how do you solve it?

Remarkably simply, it takes the form of the channel factory and provided you have both your datacontracts and your service interfaces referenced you can then do this.

Image

Download the example.

 

Calling WebAPI service from Windows Phone 8 using HttpClient

I had to solve what I figure must be a typical problem for a windows phone developer today, invoking a WebAPI service from the Mobile side. I found documentation on this process rather scarce, so here’s how you do it.

NuGet is your friend in this regard.

Step 1.

PM>  Install-Package Microsoft.AspNet.WebApi.Client -Pre

Step 2.
Confirm references

References

Step 3.

Now you can use  the HttpClient Async API to invoke your WebAPI service and return data. Here’s an example.

code

Which can then be used like this

StockService

To download the source click here.

Implementing WCF Net.Tcp binding/activation in Azure Web Role

I’ve been spending a significant amount of time recently working with the Azure platform and all I can say is WOW! Congratulations to Microsoft for creating an awesome cloud computing platform. The power, scalability, robustness and small learning curve of Azure is a godsend.

Niceties aside, working out how to get WCF Net.Tcp bindings working in an Azure web role has been far from a trivial process so I figure its time to share the magic.

Step 1 (Configure the internal endpoint):

Image

Step 2 (Configure the WebRole to run in elevated execution context in the ServiceDefinition.csdef file):

Image

Step 3 (In the WebRole OnStart() method add code that installs NonHttp Activation and configures the site bindings to support net.tcp):

Note that this code requires a reference to Microsoft.Web.Administration which is located in C:\Windows\System32\inetsrv\

private void InstallWCFNonHTTPActivation()
{
    using (Process installer = new Process())
    {

        installer.StartInfo.UseShellExecute = false;
        installer.StartInfo.RedirectStandardOutput = true;
        installer.StartInfo.FileName = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), "dism.exe");
        installer.StartInfo.Arguments = " /online /enable-feature /featurename:WCF-NonHTTP-Activation";
        installer.StartInfo.CreateNoWindow = true;
        installer.Start();
        //string output = installer.StandardOutput.ReadToEnd();
        installer.WaitForExit();
    }
}

private void ConfigureSite()
{
    try
    {
        InstallWCFNonHTTPActivation();

        ServerManager manager = new ServerManager();
        Site CurrentSite = manager.Sites.FirstOrDefault();

        if (CurrentSite != null)
        {
            Application app = CurrentSite.Applications.FirstOrDefault();

            if (app != null)
                app.EnabledProtocols = "http, net.tcp";

            CurrentSite.Bindings.Add("123:" + CurrentSite.Bindings.First().EndPoint.Address, "net.tcp");
        }

        manager.CommitChanges();
    }
    catch (Exception ex)
    {
        System.IO.File.WriteAllText(Path.Combine(Directory.GetCurrentDirectory(), "ConfigureSiteException.txt"), ex.Message);
    }

}

And there you have it, your Azure Web Role will now Install Non-Http Activation, configure bindings and automatically start without any intervention. Simple as that, only took me 3 days to work out! :-p

Building a generic security framework

Its a mind blowing fact that despite the countless libraries and frameworks available for the ASP.NET platform there still doesn’t appear to be any options regarding a plug and play security framework.

This is now the second time I have had to build a security framework for my applications and each and every time it seems to prove just as frustrating as the last. For every generic implementation I am able to concoct and two steps forward that I take, I am subsequently pulled 3 steps back when I confront a requirement that simply doesn’t fit anywhere within my implementation.

Despite my issues I do however have some tips.

Use a generic approach

  1. It may initially seem an like overwhelmingly complicated problem to solve generically but it isn’t, just like most things in our field it needs to be solved using a staggered approach.
  2. Start by implementing only the most basic functionality (Edit and View for example) and slowly move to more complicated requirements (If this value is x this control is enabled, if this value is y this control is hidden). Slowly as you solve these problems generically, you will build an overall solution.
  3. Testing a non generic approach is nearly impossible and will cost you much more in the long run.

Use bitwise operations (flag enumerations)

  1. I have tried both an approach with and without flags and I can confidently say that the code in the latter is cleaner and more understandable (even if it does make DBAs go mad)

Create a separation of permissions in the following way

  • Groups
  • Page Level Permissions
  • Control Level Permissions
  1. Groups are your standard security groups as with any other application.
  2. Page level permissions are the permissions that are tied to a single page or a group of pages and will typically only require View, Create, Edit, Delete functionality.
  3. Control level permissions are usually where things get tricky, these can require any number of ‘truths’ to either enable or show the control and the logic to express this can become very convoluted. I approach this part of the problem with the idea of invoking defined methods (that are linked by control names) that perform the required validation returning either true or false.

The above separation will cover just about any scenario you can envisage and if implemented with even the smallest of foresight should be enough for the basis of any generic security framework. Having said that, if anyone wants to become another Telerik, go get started on this project immediately…