Relate+ in CMS 6

I hate when people write on their blogs that it has been a while since the last post and that they intended to blog a lot more than they have done so far. But now I’m going to do it as well. The reason for sporadic blogging the last couple of months is that – as some of you already know – I have moved to Sydney to help out starting up the EPiServer ANZ office – that is Australia and New Zealand. Sine the end of October I live with my wife in Sydney, and the EPiServer office in CBD in Sydney is the place to find me.

Ok, enough said about that and over to the juice parts of my first blog post on Australian soil.

By now most of you have probably tried either the CTP or the RC1 of the upcoming EPiServer CMS 6 – the next big release of EPiServer’s content management system – or seen a couple of screenshots of how it may look like. However the screenshots I’m going to show you comes with a twist – it’s Relate+ (1.0.1.0) running on CMS 6!

I have not tested all the features yet, but what I’ve seen so far almost everything works great. I have only found two flaws;

1. The CSS for the Mail admin gets effected and looks a bit off
2. By default you have to append the language code to the URL to reach the start page

As you can see, these are minor issues and pretty easy to fix. So how did I accomplish this? It’s really easy. I just installed a standard Relate+ site and then upgraded it to a CMS 6 using the excellent EPiServer Deployment Center. If you want to see more details on upgrading CMS 5 sites to CMS 6, read this blog post by Per Bjurström.

So if your about to start a Relate+ project, but you are curious on the new CMS 6 maybe this is the way to go! No guarantees that everything will work though…

Windows Authentication in EPiServer Community and EPiServer Mail

Lately I have seen more and more of our partners using Windows Authentication in their EPiServer Community and EPiServer Mail solutions. I guess the reason is the products are being more and more used within an intranet environment, which is really cool.

However I have noticed that a lot of developers are having difficulties configuring this type of environment. I’m sad to say that the documentation about this type of setup is sparse at best – so I can’t blame the developers who comes asking for help. I decided to write this blog post instead of sending the same mail to everyone who needs help.

In an environment where you use Forms Authentication you are fine using the instructions in my previous post, EPiServer Community role and membership providers. But if you are using Windows Authentication the EPiServerCommonIntegrationProvider will not be able to do the syncing of the users and roles. The reason is because the ValidateUser(username, password) method in EPiServerCommonIntegrationProvider is not called, since the WindowsAuthentication ticket stores everything needed to validate the user. This causes the user to be authenticated, but not synchronized (Identity of the request is set, but the Name of the Identity is not present in the EPiServerCommon database).

The rescue is a HTTP Module that is part of the EPiServer Common. Simply add the following module to your list of HTTP Modules in the web.config:

<add name="EPiServerCommonWindowsAuthenticationIntegration" type="EPiServer.Common.Web.Authorization.IntegrationHttpModule, EPiServer.Common.Web.Authorization" preCondition="managedHandler" />

What this module will do, is to first make sure that there’s a MembershipUser for the current request. This object would originate from the configured MembershipProvider. If it is set, but there’s no user in EPiServer.Common, it will synchronize the user using EPiServer.Common.Web.Authorization.Integrator.SynchronizeUser(MembershipUser, Password, createNew).

(Remember to remove the preCondition="managedHandler" attribute if you're not using IIS7 – thanks Erik)

Hanselman’s Tool List Revisited

I’m constantly in the hunt for new tools and programs that can make life easier, not only as a programmer but for my everyday personal life as well. Since I’m a programmer on the .Net platform I follow Scott Hanselman’s blog (if you are .Net programmer you don’t follow his blog; head over to this address straight away). Every year Scott produces the “Ultimate Developer and Power Users Tool List for Windows”, this list is my golf mine for finding new tools and util programs to use.

If you haven’t read Scott’s post before, I suggest you to start out by doing that - Scott Hanselman's 2009 Ultimate Developer and Power Users Tool List for Windows – because this blog post is my reflection on that list.

First of all, kudos to Scott for compiling this awesome list! I have not tested out all the programs that he mentions, but some of them I would like to comment and I have a few additions.

• The best text editor for the Windows platform is in my opinion Notepad++. I used UltraEdit before, but Notepad++ is just as good and at the same time for free! It’s an obvious choice for me.
• Never heard of Evernote before I read Scott’s list. Now I’ve downloaded it and started to use it. Since I both use Mac and Windows I really love applications that work on both, and especially apps that sync with over the web as well. I really hope that this app can replace Onenote.
• Dropbox is the app/service I use to store stuff in the cloud. It has a nice web interface, but also applications for both Mac and Windows – which I love. You get 2 GB for free and it’s really easy to use, just drop your files in the Dropbox folder on your machine and it’s synced to the cloud. Fantastic!
• Since I’m a Mac user I also have to mention WMware Fusion, which is the best virtualization software for the Mac.
• Again, since I’m a Mac user – Bootcamp, could it be better?!
• Writing comments in code is boring, but it’s more fun with GhostDoc. GhostDoc is a plug-in to Visual Studio that generates comments for you. Use it as stubs for your comments. GhostDoc recently got acquired by SubMain – let’s hope that this only brings good to the application.
• Lately I have switched to Google Chrome as my preferred browser just because is so lightning fast and because I just love the  “One box for everything” idea.

SharePoint Connector on IIS 7

Came across an issue yesterday where a customer wanted to install EPiServer CMS on an IIS 7 together with EPiServer Connect for SharePoint for integration with SharePoint. As you probably already know, EPiServer CMS supports IIS 7 since the R2 release. However configuring the SharePoint connector is done somewhat different than for previous IIS versions.

If you are going to configure the SharePoint connector I suggest you to start of by reading this tech note, since this blog post will not cover all the details included. But when comes to configuring the IIS 7 for Basic Authentication you should look here instead, since it is here things are a bit different. In IIS 7 you can only turn on Basic Authentication on for the entire site (or turn it off), and you cannot run it in combination with for instance Forms Authentication for obvious reasons. So just make sure that Basic Authentication is enabled in the Windows features, in Windows 7 it will look like this:

 
Also make sure that Basic Authentication is disabled for your site in IIS 7.

 
Now you might think, what the h***? If I turn off Basic Authentication how could SharePoint connector use it?! Well actually the tag you inserted in the web.config (see below) is an EPiServer hack to enable Basic Authentication on the requests made to a particular location.

<EPiServer.basicAuthentication sendBasicChallenge="true" basicRealm="" />

Hopefully now you will shout out something like; Hallelujah it works!

Turn off logging for EPiServer Community

The EPiServer Community does not have the same extensive logging capabilities as EPiServer CMS, which utilizes the log4net component. But there are some basic logging done to the standard Windows Event Log under the Application group. The problem is that there is no configuration for turning off the logging if you don’t want it.

But, as in many cases, there is a workaround. The installer for EPiServer Community will set up an entry in the registry to allow the application to write to the Event Log. To turn off the logging simply start up Regedit and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\EPiServer Common 

Either remove the entry or rename it. Now the application will not be allowed to write to the Event Log, and therefore no entries are written there!

EPiServer Community role and membership providers

From various sources I have found out that a lot of people are having trouble with the configuration of role providers and membership providers for EPiServer Community and EPiServer Mail. In this blog post I will try to describe the different setups that are available.

The basic facts

The first thing you need to know is that both Community and Mail has to have the users and groups in the database, independent of which membership provider and role provider you are using. The reason is the the user is such a central concept in the Community case, and Mail is using the same user management as Community. Ok, now we got this settled – let’s move on!

The most basic configuration

In the default installation for Community and Mail, the system will be configured to use the role provider named EPiServerCommonRoleProvider and the membership provider EPiServerCommonMembershipProvider. This means that the system will authenticate against the EPiServer Common tables, which is used by both Mail and Community. The system will also get the user roles, or groups, from the EPiServer Common tables. I.e. the user/group management and access rights is entirely managed by EPiServer Common.

<roleManager enabled="true" defaultProvider="EPiServerCommonRoleProvider" cacheRolesInCookie="true">

    <providers>

        <clear/>

        <add name="EPiServerCommonRoleProvider" applicationName="EPiServerCommonApplication" type="EPiServer.Common.Web.Authorization.RoleProvider, EPiServer.Common.Web.Authorization"/>

    </providers>

</roleManager>

<membership defaultProvider="EPiServerCommonMembershipProvider" userIsOnlineTimeWindow="10">

    <providers>

        <clear/>

        <add name="EPiServerCommonMembershipProvider" applicationName="EPiServerCommonApplication" type="EPiServer.Common.Web.Authorization.MembershipProvider, EPiServer.Common.Web.Authorization"/>

    </providers>

</membership>

A little bit more advanced configuration

In this case we want to use external membership provider and role provider. In my example I’m going to use Windows providers, but these could easily be substituted with SQL providers or something else.

We start off by setting the WindowsRoleProvider as default role provider, nothing tricky here. However when specifying the membership provider we will not set the WindowsMembershipProvider as default. Remember that every user/group needs to exist in the EPiServer Common tables. To solve this we use the EPiServerCommonIntegrationMembershipProvider and set it as default membership provider. This provider has an attribute called “provider”, here you specify your underlying provider – in this case the WindowsMembershipProvider.

You will also specify the attributes “roleToSynchronizeX” where X is a number (has to be in sequence and start with 1). If a user logs in and gets authenticated the system will look at the user’s groups – if the user is member of any of the groups specified in the “roleToSynchronize” attributes, then the user and all of its groups will be copied to the EPiServer Common tables. Note that only the user’s groups will be copied, not the other users in these groups.

If you use the notation roleToSynchronize1=”*”, the user will be copied independent of the group memberships it has. Note that you have to have EPiServer Common 2.3 Hotfix 1 for this to work.

<roleManager enabled="true" defaultProvider="WindowsRoleProvider" cacheRolesInCookie="true">

    <providers>

        <clear/>

        <add name="WindowsRoleProvider" applicationName="EPiServerSample" type="EPiServer.Security.WindowsRoleProvider, EPiServer"/>

    </providers>

</roleManager>

<membership defaultProvider="EPiServerCommonIntegrationMembershipProvider" userIsOnlineTimeWindow="10">

    <providers>

        <clear/>                

        <add name="WindowsMembershipProvider" type="EPiServer.Security.WindowsMembershipProvider, EPiServer" deletePrefix="BUILTIN\" searchByEmail="true"/>                

        <add name="EPiServerCommonIntegrationMembershipProvider" applicationName="EPiServerCommonApplication" type="EPiServer.Common.Web.Authorization.IntegrationMembershipProvider, EPiServer.Common.Web.Authorization" provider="WindowsMembershipProvider" roleToSynchronize1="Group1" roleToSynchronize2="Group2" />

    </providers>

</membership>

Advanced configuration

The last type of configuration is where you want to use a series of providers, something we at EPiServer would call a multiplexing scenario. In this case will make us of the IntegrationMultiplexingMembershipProvider which can be found in EPiServer Common 2.3 Hotfix 1. This is actually a combination of the multiplexing provider found in EPiServer CMS and the integration provider mentioned above. This will be used in combination with the MultiplexingRoleProvider in EPiServer CMS.

When using this provider you will be able to specify several underlying providers. The system will try the providers one after another until either the user is authenticated or the the list of providers runs out.

In my example below I’m using the Windows provider as primary provider and SQL provider as secondary.

<roleManager enabled="true" defaultProvider="MultiplexingRoleProvider" cacheRolesInCookie="true">

    <providers>

        <clear/>

        <add name="MultiplexingRoleProvider" type="EPiServer.Security.MultiplexingRoleProvider, EPiServer" provider1="WindowsServerRoleProvider" provider2="SqlRoleProvider" providerMap1="WindowsServermembershipProvider" providerMap2="SqlMembershipProvider"/>

        <add name="WindowsRoleProvider" applicationName="EPiServerSample" type="EPiServer.Security.WindowsRoleProvider, EPiServer"/>

        <add name="SqlServerRoleProvider" connectionStringName="EPiServerDB" applicationName="EPiServerSample" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

    </providers>

</roleManager>

<membership defaultProvider="MultiplexingMembershipProvider" userIsOnlineTimeWindow="10">

    <providers>

        <clear/>

        <add name="MultiplexingMembershipProvider" type="EPiServer.Common.Web.Authorization.Multiplexing.IntegrationMultiplexingMembershipProvider, EPiServer.Common.Web.Authorization.Multiplexing" provider1="WindowsServerMembershipProvider" provider2="SqlMembershipProvider" roleToSynchronize1="*" />

        <add name="WindowsMembershipProvider" type="EPiServer.Security.WindowsMembershipProvider, EPiServer" deletePrefix="BUILTIN\" searchByEmail="true"/>

        <add name="SqlServerMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="EPiServerDB" requiresQuestionAndAnswer="false" applicationName="EPiServerSample" requiresUniqueEmail="true" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" passwordStrengthRegularExpression=""/>

    </providers>

</membership>

Confusion about what Relate+ is

Ever since the Relate+ package was released I have experienced that partners, customers and sometimes even EPiServer employees are a bit confused about what Relate+ really is from a technical point of view. Or maybe I should say that probably they are not confused, but they are using the Relate+ name in a confusing way. My idea here is to sort out once and for all what Relate+ is, and what Relate+ is not.

First thing first; Relate+ is not equal to EPiServer Community. This is the most common misinterpretation. With that said, it’s best to also say Relate+ is not equal to EPiServer CMS.

What is Relate+ then? From a technical point of view Relate+ is set of templates, pretty much like the public templates for EPiServer CMS, built on top of EPiServer Community and EPiServer CMS. The templates are then bundled together with EPiServer Community and EPiServer Mail and sold as an add-on package to EPiServer CMS. The idea is to show off the greater part – not all – of the functions in EPiServer Community. This means that you can run a community site without Relate+. It also means that there are more functions in EPiServer Community besides those implemented in Relate+.

To summarize, Relate+ is a template package and not a separate product.