PropertyTranslator and Interfaces

I my last post I introduced PropertyTranslator – an easy way to translate computed properties in a LINQ query into their implementation right before execution.

This post covers how PropertyTranslator enables you to use LINQ queries written towards properties of an interface, instead of the implementing class.

The Context

Let’s assume you’ve got an IPerson interface as follows:

public interface IPerson
{
    string DisplayName { get; }
}

Additionally there are the two classes Student and Teacher implementing the IPerson interface.

To keep your code base clean you pay great attention to the DRY principle and want to implement a search algorithm for filtering objects implementing IPerson only once in a single place:

public IEnumerable<T> Search<T>(IEnumerable<T> list, string name) 
    where T : IPerson
{
    return list.Where(p => p.DisplayName.Contains(name));
}

Implementation using PropertyTranslator

Implementing this using PropertyTranslator is straight forward:

public class Student : IPerson
{
    private static readonly CompiledExpressionMap<Student, string> displayNameExpression
        = DefaultTranslationOf<Student>.Property(s => s.DisplayName).Is(s => s.Name + " (" + s.MatrNo + ")");

    public string DisplayName
    {
        get { return displayNameExpression.Evaluate(this); }
    }

    public string Name { get; set; }

    public string MatrNo { get; set; }
}
public class Teacher : IPerson
{
    private static readonly CompiledExpressionMap<Teacher, string> displayNameExpression
        = DefaultTranslationOf<Teacher>.Property(s => s.DisplayName).Is(s => s.Name);

    public string DisplayName
    {
        get { return displayNameExpression.Evaluate(this); }
    }

    public string Name { get; set; }
}

The “magic” happens inside of PropertyTranslator, when the interface type is automatically resolved to the class right before query execution: https://github.com/peschuster/PropertyTranslator/blob/master/src/PropertyTranslator/PropertyVisitor.cs#L57-66

LINQ: How to dynamically map properties

A few month ago i struggled with calculated properties in Entity Framework model objects.

A property like

public string FullName
{
    get { return this.FirstName + " " + this.LastName; }
}

can’t be used in a LINQ query to the database, because the LINQ provider transforming the expression tree to SQL can’t deal with it. This is kind of obvious, because there is no field named “fullName” or similar in the database, but on the other hand it shouldn’t be to difficult to achieve support for these kind of properties as it is quite simple to translate them into SQL.

The Idea

So I did some research and discovered a blog post by Damien Guard and David Fowler: http://damieng.com/blog/2009/06/24/client-side-properties-and-any-remote-linq-provider. They described exactly what I was trying to do and also provided a ready solution for translating properties in LINQ expressions.

Although their solution is really great, it has some caveats:

  1. You have to include a call to WithTranslations() on every query.
  2. It is not possible to build queries on an common interface for multiple classes (more about this in another blog post).
  3. I wanted to be able to provide different property implementations based on the current thread ui culture (I know, sounds scary…).

So I took a stab at it and tried to add the “missing” functionality. The result is a fork of Microsoft.Linq.Translations named “PropertyTranslator”.

The mayor differences between Microsoft.Linq.Translations and PropertyTranslator are the three points described above. At that time Microsoft.Linq.Translations wasn’t at GitHub, yet. Otherwise I probably would have forked it in the github-sense and tried to contribute back.

PropertyTranslator

So, how does it work? I think this is best described with a few examples:

Basic example

A POCO entity class from EntityFramework.

Although in the database only a FirstName and a LastName field exists, the property Name can be used in queries, because right before execution it is translated to FirstName + ' ' + LastName.

public class Person
{
    private static readonly CompiledExpressionMap<Person, string> fullNameExpression = 
        DefaultTranslationOf<Person>.Property(p => p.FullName).Is(p => p.FirstName + " " + p.LastName);

    public string FullName
    {
        get { return fullNameExpression.Evaluate(this); }
    }

    public string FirstName { get; set; }

    public string LastName { get; set; }        
}

UI culture dependent translations

The context: a database table, mapped with entity framework to POCO entity classes with two fields: EnglishName and GermanName. With the following snippet, you can use the Name property in LINQ queries which resolves to the name (either EnglishName or GermanName) depending on the current ui culture.

public class Country
{
    private static readonly CompiledExpressionMap<Country, string> nameExpression = 
        DefaultTranslationOf<Country>.Property(c => c.Name).Is(c => c.EnglishName);

    static Country()
    {
        DefaultTranslationOf<Country>.Property(c => c.Name).Is(c => c.EnglishName, "en");
        DefaultTranslationOf<Country>.Property(c => c.Name).Is(c => c.GermanName, "de");
    }       

    public string Name
    {
        get { return nameExpression.Evaluate(this); }
    }

    public string EnglishName { get; set; }

    public string GermanName { get; set; }      
}

How to enable PropertyTranslator

PropertyTranslator is on Nuget. So you can just add it to your project using the Package Manager Console.

You can enable PropertyTranslator by adding the PropertyVisitor to your EntityFramework ObjectSets (of course it works not only with EntityFramework but with any LINQ provider).

Best way to do this is by using David Fowler’s QueryInterceptor (also on Nuget):

using QueryInterceptor;
using PropertyTranslator;

public class MyDataContext
{
    ObjectContext context = new MyEfContext();

    public IQueryable<Person> PersonTable
    {
        get
        {
            var objectSet = context.CreateObjectSet<Person>("Persons");

            return objectSet.InterceptWith(new PropertyVisitor());
        }
    }
}

Conclusion

With PropertyTranslator it is really simple to translate calculated properties to their implementation right before execution so that it is possible to use them in LINQ queries with any LINQ provider.

Great thanks to Damien Guard and David Fowler for the general idea and their implementation. I mainly just added an additional layer of abstraction (CompiledExpressionMap) and did some restructuring/fixes to enable a convenient usage with QueryInterceptor and writing queries towards interfaces.

How to add an uac shield icon to a MenuItem

Since Windows Vista an application needs administrator privileges to perform some system operations like starting or stopping a Windows service. To gain these privileges you can add an “app.manifest” file to your project in Visual Studio and set the requestedExecutionLevel to requireAdministrator.

In Windows there is always the small shield icon to inform the user that administrator privileges are required for the desired action:

image

To add this icon to your own context menu in a WinForms project the following steps are required:

1. Check that the user currently has no administrator privileges:

public bool HasAdministratorRights
{
    get
    {
        var pricipal = new WindowsPrincipal(WindowsIdentity.GetCurrent());

        return pricipal != null && pricipal.IsInRole(WindowsBuiltInRole.Administrator);
    }
}

2. Use a ContextMenuStrip and ToolStripMenuItems instead of the old ContextMenu and MenuItems.

3. Import the SHGetStockIconInfo method from shell32:

private static class NativeMethods
{
    [DllImport("Shell32.dll", SetLastError = false)]
    public static extern Int32 SHGetStockIconInfo(SHSTOCKICONID siid, SHGSI uFlags, ref SHSTOCKICONINFO psii);

    public enum SHSTOCKICONID : uint
    {
        SIID_SHIELD = 77
    }

    [Flags]
    public enum SHGSI : uint
    {
        SHGSI_ICON = 0x000000100,
        SHGSI_SMALLICON = 0x000000001
    }

    [StructLayoutAttribute(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
    public struct SHSTOCKICONINFO
    {
        public UInt32 cbSize;
        public IntPtr hIcon;
        public Int32 iSysIconIndex;
        public Int32 iIcon;

        [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)]
        public string szPath;
    }
}

4. Fetch the shield icon and create a bitmap out of the HIcon:

private void SetUacShield(ToolStripMenuItem menuItem)
{
    NativeMethods.SHSTOCKICONINFO iconResult = new NativeMethods.SHSTOCKICONINFO();
    iconResult.cbSize = (uint)System.Runtime.InteropServices.Marshal.SizeOf(iconResult);

    NativeMethods.SHGetStockIconInfo(
        NativeMethods.SHSTOCKICONID.SIID_SHIELD, 
        NativeMethods.SHGSI.SHGSI_ICON | NativeMethods.SHGSI.SHGSI_SMALLICON, 
        ref iconResult);

    menuItem.DisplayStyle = ToolStripItemDisplayStyle.ImageAndText;
    menuItem.Image = Bitmap.FromHicon(iconResult.hIcon);
}

That’s all. Now you can restart you application with administrator rights or call another executable with the “runas” verb:

private void RunAsAdmin(string fileName, string args)
{
    var processInfo = new ProcessStartInfo
    {
        Verb = "runas",
        FileName = fileName,
        Arguments = args,
    };

    try
    {
        Process.Start(processInfo);
    }
    catch (Win32Exception)
    {
        // Do nothing...
    }
}

New line bug in ASP.NET MVC Textarea helper

To render a textarea for a model property in ASP.NET MVC you usually perform a call to @Html.TextAreaFor(…):

@Html.TextAreaFor(m => m.MyProperty)

Recently I encountered the strange behavior that it always adds a new line at the beginning of the textarea. How comes?

Analysis

Note: if you just look for a workaround for this bug scroll down to “Conclusion and solution”.

Internally the TextAreaFor(…) method uses the TextAreaExtensions class in System.Web.Mvc.Html. The code responsible for generating the html output looks roughly like the following:

private static MvcHtmlString TextAreaHelper(HtmlHelper htmlHelper, ModelMetadata modelMetadata, string name, IDictionary<string, object> rowsAndColumns, IDictionary<string, object> htmlAttributes)
{
    // Some initialization here...

    TagBuilder tagBuilder = new TagBuilder("textarea");

    // Some more logic...
 
    tagBuilder.SetInnerText(Environment.NewLine + attemptedValue);
    return tagBuilder.ToMvcHtmlString(TagRenderMode.Normal);
}

So, the intended output of TextAreaFor is:

<textarea>
This is the content...</textarea>

This should be fine and not add an extra new line at the beginning, right? Well, the actual html output looks like this:

<textarea>&#13;&#10;This is the content...</textarea>

There seems to be some more magic in place. And by risking a deeper look at TagBuilder.SetInnerText(…) we discover that it does a call to HttpUtility.HtmlEncode(…):

public void SetInnerText(string innerText)
{
    this.InnerHtml = HttpUtility.HtmlEncode(innerText);
}

Now the pieces come together and one important fact surfaces: the bug only appears when the popular AntiXssEncoder is used as HttpEncoder. The AntiXSS encoder encodes output in views in a safer way by using a white list approach for allowed characters. Till now you had to manually include the AntiXSSEncoder in your ASP.NET MVC project, but up from the next version (ASP.NET 4.5) it is already included and can be activated via web.config.

Conclusion and solution

In contrast to the default HttpEncoder the AntiXssEncoder also encodes new line characters to “&#13;&#10;”, but for the browser this is not the same like just a new line in the html markup. In ASP.NET MVC4 Developer Preview (and most likely also in the soon coming stable version) this is fixed, but till then the probably easiest workaround is to create your own helper for rendering textarea markup in views:

public static MvcHtmlString FixedTextAreaFor<TModel, TProperty>(this HtmlHelper<TModel> htmlHelper, Expression<Func<TModel, TProperty>> expression)
{
    return new MvcHtmlString(htmlHelper.TextAreaFor(expression)
        .ToHtmlString()
        .Replace(">&#13;&#10;", ">" + Environment.NewLine));
}

(On demand you can just create fixed versions of TextAreaFor(…) for the other overloaded methods like in the example above.)

WIF in depth: Validating Security Tokens outside of WIF

Sometimes it is necessary to validate SecurityTokens issued by an Windows Identity Foundation (WIF) driven Identity Provider (IdP) in a Service Provider (SP) application that has no reference to WIF.

When it came to validating the xml signature of the token I ran into an exception on calling the CheckSignature() method of the SignedXml class:

System.Security.Cryptography.CryptographicException: 
SignatureDescription could not be created for the signature algorithm supplied.

What this exception message basically states is that it does not know the specified signature algorithm. The name of this algorithm is set by the corresponding xml attribute in the raw token data as http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.

The problem here is that this signature algorithm is not supported by the core .NET framework (http://blogs.msdn.com/b/shawnfa/archive/2008/08/25/using-rsacryptoserviceprovider-for-rsa-sha256-signatures.aspx). I found some blog posts on how to activate support for this algorithm, but it did not really work out for me.

So after I failed trying to adjust the code of the SP application to fit WIF, I had a look at the other side of the pipe: my Identity Provider implemented using WIF:

I did not tell WIF to use RSA-SHA256 as signature algorithm anywhere and my X.509 certificate also used RSA-SHA1. So obviously this algorithm must be set somewhere inside of WIF as default value. And indeed it is: If you do not explicitly specify the signature algorithm when calling a constructor of the X509SigningCredentials it is set to RSA-SHA256 by default:

public X509SigningCredentials(X509Certificate2 certificate, SecurityKeyIdentifier ski) 
    : this(
        new X509SecurityToken(certificate), 
        ski, 
        "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256", 
        "http://www.w3.org/2001/04/xmlenc#sha256")
{
}

So the solution to this problem is to use another constructor of the X509SigningCredentials class on setting the SigningCredentials of the SecurityTokenService.

An example:

this.SigningCredentials = new X509SigningCredentials(
    certificate,
    "http://www.w3.org/2000/09/xmldsig#rsa-sha1",
    "http://www.w3.org/2000/09/xmldsig#sha1");

Another issue I was facing on manually validating the xml signature of a security token is that the default SignedXml class was not able to find the Id element of the security token. The following article did the trick for me: http://blogs.msdn.com/b/shawnfa/archive/2004/04/05/108098.aspx

WIF in depth: What’s a SecurityKeyIdentifierClause

Windows Identity Foundation (WIF) is a powerful framework for implementing a federated (i.e. distributed) authentication and authorization scheme into your application. It is fairly easy to use with already existing security token services (STS) like Windows Azure Access Control Services (ACS) or the Active Directory Federation Services 2.0 (ADFS 2.0), but when it comes to implementing your own STS it gets really tricky.

The first part – creating the SecurityTokenService class – is covered by several tutorials and blog posts on the web and the WIF SDK from Microsoft also contains a Visual Studio project template for this task. But when it comes to creating your own SecurityTokenHandler (required for custom security token formats) your pretty much on your own.

In this post I am gone explain what the purpose of the classes SecurityKey, SecurityKeyIdentifier and SecurityKeyIdentifierClause in the context of your own SecurityToken implementation is.

To understand the full concept of these SecurityKey concerned classes you have to be aware that there are several types of SecurityTokens. What is commonly referred to as security token are so called “Bearer Tokens” (carrying information with them, e.g. like claims). But a SecurityToken could for example also be a wrapped X.509 certificate (see also the other post about the IssuerNameRegistry).

SecurityKey

As the name already suggests a SecurityKey is just a “security key” for cryptographic operations (like signing or encrypting security tokens). This could be a X.509 certificate, a rsa key (pair) or anything similar. Returning a collection of SecurityKeys is required on a class inheriting from SecurityToken, but usually you just don’t care about security keys in your custom bearer SecurityToken implementation and return an empty, read-only list:

public override ReadOnlyCollection<SecurityKey> SecurityKeys 
{ 
    get { return new List<SecurityKey>().AsReadOnly(); }
}

SecurityKeyIdentifierClause

A SeurityKeyIdentifierClause is something like the unique identifier of a security key. It is used to reference a specific token (or security key) without including the whole content of the token.

You most probably stumble upon this the first time when implementing the CreateSecurityTokenReference method of your custom SecurityTokenHandler class.

As this method is called during issuing tokens and a SecurityTokenIdentifierClause is expected as return value, you have to take care of the logic behind it.

For Saml tokens the CreateSecurityTokenReference() implementation looks like the following:

public override SecurityKeyIdentifierClause CreateSecurityTokenReference(SecurityToken token, bool attached)
{
    if (token == null)
        throw new ArgumentNullException("token");

    return token.CreateKeyIdentifierClause<SamlAssertionKeyIdentifierClause>();
}

Purpose of a SecurityKeyIdentifierClause is to compare tokens. Therefore it has a Matches(object keyIdentifierClause) method. This method is used by a SecurityTokenResolver to return the corresponding SecurityToken for the specified SecurityKeyIdentifierClause.

Summing all this up: a SecurityKeyIdentifierClause is an identifier with some logic to compare equality with other SecurityKeyIdentifierClause objects. So the best implementation for your custom bearer SecurityToken is most probably to use the LocalIdKeyIdentifierClause with the id of your token as localId parameter.

SecurityKeyIdentifier

A SecurityKeyIdentifier is simply a collection of SecurityKeyIdentifierClauses. When ever needed you can use the implementation in System.IdentityModel.Tokens here. There is usually no need to take care of this by your self.

WIF in depth: Validating a security token against an IssuerNameRegistry

The Windows Identity Foundation (WIF) provides an IssuerNameRegistry for validating the issuer of a security token. There are multiple implementations of the abstract class IssuerNameRegistry. ConfigurationBasedIssuerNameRegistry is probably the most commonly used one. You can add trusted issuers to this implementation by adding them in the respective section of your web.config file.

The method GetIssuerName of the IssuerNameRegistry (which is responsible for validating issuers) expects a SecurityToken as parameter and returns the name of the issuer (if valid) or null. Internally the paramter is casted to a X509SecurityToken and the thumbprint of the corresponding certificate is looked up in the list of registered trusted issuers.

This sounds pretty simple and straight forward, but the actual question that came to my mind is: how to obtain the thumbprint of the issuer, as it does not seem to be included in the security token?

It took me some time of research and reading through decompiled framework code, but finally I “discovered” a solution in the SAML2 implementation inside WIF:

Validating signatures of incoming security tokens inside WIF is usually done with an EnvelopedSignatureReader. After reading and validating the xml signature this reader provides the SigningCredentials of the signature:

var root = XElement.Load(wrappedSignatureReader);
var signingCredentials = wrappedSignatureReader.SigningCredentials;

When the security token was signed with a X509 certificate (that’s the most common way), the SigningCredentials are of type X509SigningCredentials and contain somehow a reference to the used certificate.

You can obtain a reference to this certificate by using a X509CertificateStoreTokenResolver. This SecurityTokenResolver is usually present in the property SecurityTokenServiceConfiguration.IssuerTokenResolver (i.e. through your service configuration).

To resolve the SigningCredentials to a X509SecurityToken simply pass the SigningKeyIdentifier to the method TryResolveToken of the IssuerTokenResolver:

protected virtual bool TryResolveIssuerToken(SigningCredentials signingCredentials, SecurityTokenResolver issuerResolver, out SecurityToken token)
{
    if (signingCredentials != null && signingCredentials.SigningKeyIdentifier != null && issuerResolver != null)
    {
        return issuerResolver.TryResolveToken(signingCredentials.SigningKeyIdentifier, out token);
    }

    token = null;

    return false;
}

All this fragments come together in the ReadToken method of your custom SecurityTokenHandler:

protected override SecurityToken ReadToken(XmlReader reader)
{
    using (var wrappedSignatureReader = new EnvelopedSignatureReader(reader, this, this.Configuration.IssuerTokenResolver, true, true, false))
    {
        var root = XElement.Load(wrappedSignatureReader);
        var signingCredentials = wrappedSignatureReader.SigningCredentials;

        SecurityToken issuerToken;
        this.TryResolveIssuerToken(signingCredentials, this.Configuration.IssuerTokenResolver, out issuerToken);

        SecurityToken token;

        // create and fill your custom security token with data here...

        return token;
    }
}

The obtained SecurityToken is of type X509SecurityToken, which can be used to verify the issuer with an IssuerNameRegistry. This is/should be done in the ValidateToken method of your SecurityTokenHandler.

Upgrading user settings

Or: Why your saved settings are always overridden by the previous ones

In an application of mine I persist user settings (like username, form position, window state, etc.) in a user configuration file (for more information on this topic in general have a look at this MSDN article).

In code you can access this settings like this:

var user = Properties.Settings.Default.User;

Properties.Settings.Default provides also methods for saving changed settings and upgrading persisted settings from a previous application version.

What upgrade does is to copy the settings file from a path like “path-to-settings/Company/MyApplication/1.0.0.1/user.config” to the path reflecting the current application version: “path-to-settings/Company/MyApplication/1.0.0.2/user.config”.

The crux of the matter is that copying the file is always performed, never the less whether there is already a user configuration file for the current version or not.

In conclusion this means you as the programmer have to make sure that Upgrade is only called once after you upgraded to a new version. Otherwise all changed values are always replaced by the last state from the old application version.

An easy solution to circumvent the described behavior of the upgrade method is to check whether a property in the user settings has still its default value, although it should have been set already:

if (String.IsNullOrEmpty(Properties.Settings.Default.User))
    Properties.Settings.Default.Upgrade();

Using tx_crawler with tx_simulatebe

Today I encountered a strange behavior of the extension crawler in a TYPO3 installation:

Due to a bug in the extension, tx_crawler got stuck in an infinite redirect loop while trying to call a site as a logged in frontend user. This lead to a “maximum execution depth” php/suhosin error:

ALERT - maximum execution depth reached - script terminated
(attacker 'REMOTE_ADDR not set', file
'xxxxxxxxxxx/typo3conf/ext/crawler/class.tx_crawler_lib.php', line 1228)

It turned out that the TYPO3 site always returned a “HTTP 302 Found” response. But the specified redirect url (in the “Location” header) was the same as the request url.

I emulated the tx_crawler request with Fiddler, but couldn’t reproduce the behavior.

Finally I added some debug calls to the class tx_crawler_lib and noticed a strange cookie in the webserver response headers:

simulatebe=deleted

This cookie seems to be set through the extension simulatebe, which is also used on the site. I looked at the source code of tx_simulatebe_pi1 and indeed, simulatebe does a redirect to t3lib_div::getIndpEnv(“TYPO3_REQUEST_URL”), which returns just the url of the the current request.

In my case simulating a backend user does not really make sense, when calling the site through tx_crawler. To prevent simualtebe from returning a “HTTP 302 Found” response on tx_crawler requests we have to deactivate the plugin just for these requests.

The crawler extension sets “TYPO3 crawler” as user agent header. Therefore an easy solution for conditional inclusion of tx_simulatebe_pi1 is to check the user agent header data against the string “TYPO3 crawler”.

With the following TypoScript code in the site template tx_simulatebe is included only when the request does not come from tx_crawler:

page.headerData.20 < plugin.tx_simulatebe_pi1
[useragent = TYPO3 crawler]
  page.headerData.20 >
[global]