Blog posts by Amit Mittal

Migrating Optimizely 11 to 12: SQL Membership & Legacy Hashes (Part 2)

Mon, 01 Dec 2025 09:13:44 GMT

In [Part 1], we handled the migration of users who were already using ASP.NET Identity. Now, we tackle the more complex scenario: the MembershipUsersUpgrade project.

This project is still using the legacy SQL Server Membership Provider (aspnet_* tables). This adds two layers of complexity:

Data Migration: We need to physically move user data from the old aspnet_Users tables to the new AspNetUsers tables.
Complex Hashing: The SQL Membership provider used a specific (and somewhat quirky) implementation of HMACSHA512 (or SHA1/SHA256) that handles salts and keys differently than modern standards.

The Strategy: The "Legacy Container" Column

To keep the migration smooth, we won't try to convert the old passwords to the new format during the SQL migration (which is impossible without the user's plain-text password).

Instead, we will create a temporary container column called LegacyPasswordSalt in our new table. We will store the old Hash, the Salt, and the Format in this one column. When the user logs in, our code will parse this column, verify the old password, and then automatically upgrade them to the new format.

Step 1: The SQL Migration Script

I created an idempotent SQL script to handle this. It does three things:

Adds the LegacyPasswordSalt column to the new table.
Migrates Users, Roles, and mappings.
Concatenates the old password data into the new column using a pipe (|) delimiter.

SQL

/*
================================================================================
ASP.NET Membership to ASP.NET Core Identity Migration Script
================================================================================
*/
SET NOCOUNT ON;

-- 1. Add LegacyPasswordSalt column to store old hash/salt data
IF NOT EXISTS (SELECT 1 FROM sys.columns WHERE Name = N'LegacyPasswordSalt' AND Object_ID = Object_ID(N'dbo.AspNetUsers'))
BEGIN
    PRINT 'Adding column [LegacyPasswordSalt] to [dbo].[AspNetUsers]...';
    ALTER TABLE [dbo].[AspNetUsers] ADD [LegacyPasswordSalt] NVARCHAR(MAX) NULL;
END

GO

BEGIN TRANSACTION;
BEGIN TRY
    -- 2. INSERT USERS
    PRINT 'Migrating users...';

    INSERT INTO dbo.AspNetUsers (
        Id, UserName, NormalizedUserName, Email, NormalizedEmail, 
        EmailConfirmed, PasswordHash, SecurityStamp, ConcurrencyStamp, 
        PhoneNumber, PhoneNumberConfirmed, TwoFactorEnabled, 
        LockoutEnd, LockoutEnabled, AccessFailedCount, 
        LegacyPasswordSalt, -- <--- The Key Column
        IsApproved, CreationDate, LastLoginDate, LastLockoutDate, IsLockedOut
    )
    SELECT
        u.UserId,
        u.UserName,
        UPPER(u.UserName),
        m.Email,
        UPPER(m.Email),
        1, -- EmailConfirmed
        -- We store the formatted legacy string in PasswordHash strictly as a placeholder
        (m.Password + '|' + CAST(m.PasswordFormat AS VARCHAR(10)) + '|' + m.PasswordSalt), 
        NEWID(), NEWID(), NULL, 0, 0, 
        m.LastLockoutDate, 1, 0,
        -- Actual Legacy Data storage: Hash|Format|Salt
        (m.Password + '|' + CAST(m.PasswordFormat AS VARCHAR(10)) + '|' + m.PasswordSalt), 
        1, m.CreateDate, m.LastLoginDate, m.LastLockoutDate, 0
    FROM dbo.aspnet_Users u
    LEFT JOIN dbo.aspnet_Membership m ON u.UserId= m.UserId
    WHERE NOT EXISTS (SELECT 1 FROM dbo.AspNetUsers anp WHERE anp.Id = u.UserId)
      AND m.Password IS NOT NULL;

    PRINT 'Users migrated successfully.';

    -- 3. INSERT ROLES
    PRINT 'Migrating roles...';
    INSERT INTO dbo.AspNetRoles (Id, Name, NormalizedName)
    SELECT RoleId, RoleName, UPPER(RoleName)
    FROM dbo.aspnet_Roles r
    WHERE NOT EXISTS (SELECT 1 FROM dbo.AspNetRoles anr WHERE anr.Id = r.RoleId);

    -- 4. INSERT USER ROLES
    PRINT 'Migrating user-role relationships...';
    INSERT INTO dbo.AspNetUserRoles (UserId, RoleId)
    SELECT UserId, RoleId FROM dbo.aspnet_UsersInRoles ur
    WHERE NOT EXISTS (SELECT 1 FROM dbo.AspNetUserRoles anur WHERE anur.UserId = ur.UserId AND anur.RoleId = ur.RoleId);

    COMMIT TRANSACTION;
    PRINT 'Migration script completed successfully.';
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;
    PRINT 'Error: ' + ERROR_MESSAGE();
    THROW;
END CATCH

Step 2: Extending the Identity User

We need to tell ASP.NET Core Identity about our new column.

C#

using Microsoft.AspNetCore.Identity;
using System.ComponentModel.DataAnnotations.Schema;

public class MyCustomUser : IdentityUser // Or ApplicationUser depending on your setup
{
    [Column(TypeName = "nvarchar(max)")]
    public string? LegacyPasswordSalt { get; set; }
}

Step 3: The Membership Password Hasher

This is the most critical part. The old SqlMembershipProvider used a specific logic for HMACSHA512. It didn't just pass the salt to the constructor; it had a specific way of padding the key if the salt length differed from the key length.

Warning: You must use Encoding.Unicode (Little Endian UTF-16) for the password bytes. Modern systems use UTF-8, but legacy ASP.NET Membership used Unicode. If you change this, the hashes will not match.

C#

using Microsoft.AspNetCore.Identity;
using System;
using System.Security.Cryptography;
using System.Text;

public class FallbackPasswordHasher : PasswordHasher<MyCustomUser>
{
    // The legacy field format: Hash|Format|Salt
    private const int LegacyHashIndex = 0;
    private const int LegacyFormatIndex = 1; 
    private const int LegacySaltIndex = 2;
    private const int ExpectedLegacyPropertyCount = 3;
    private const int HashedPasswordFormat = 1; // 1 = Hashed

    public override PasswordVerificationResult VerifyHashedPassword(MyCustomUser user, string hashedPassword, string providedPassword)
    {
        // 1. Modern Hash Check
        // If LegacyPasswordSalt is empty, the user has already been migrated or is new.
        if (string.IsNullOrEmpty(user.LegacyPasswordSalt))
        {
            return base.VerifyHashedPassword(user, hashedPassword, providedPassword);
        }

        // 2. Legacy Hash Fallback
        string[] passwordProperties = user.LegacyPasswordSalt.Split('|');
        if (passwordProperties.Length < ExpectedLegacyPropertyCount)
        {
            return PasswordVerificationResult.Failed;
        }

        string legacyHashBase64 = passwordProperties[LegacyHashIndex];
        string saltBase64 = passwordProperties[LegacySaltIndex];
            
        // We assume format is '1' (Hashed).
        // If you have users with format '0' (Clear), handling that here is a security risk.
        byte[] providedHashBytes = HashLegacyPassword(providedPassword, HashedPasswordFormat, saltBase64);
        
        if (providedHashBytes == null) return PasswordVerificationResult.Failed;

        byte[] storedHashBytes;
        try
        {
            storedHashBytes = Convert.FromBase64String(legacyHashBase64);
        }
        catch (FormatException)
        {
            return PasswordVerificationResult.Failed;
        }

        // 3. Secure Comparison
        if (CryptographicOperations.FixedTimeEquals(providedHashBytes, storedHashBytes))
        {
            // Success! Return 'SuccessRehashNeeded' to trigger an automatic database update.
            return PasswordVerificationResult.SuccessRehashNeeded;
        }

        return PasswordVerificationResult.Failed;
    }

    public override string HashPassword(MyCustomUser user, string password)
    {
        // When creating a NEW hash (e.g. Change Password, or Re-hashing after login),
        // we must clear the legacy field to ensure future logins use the modern standard.
        user.LegacyPasswordSalt = null;
        return base.HashPassword(user, password);
    }

    /// <summary>
    /// Replicates the specific HMACSHA512 logic used by the legacy SqlMembershipProvider.
    /// </summary>
    private byte[] HashLegacyPassword(string password, int passwordFormat, string salt)
    {
        if (passwordFormat != HashedPasswordFormat) return null;
        if (string.IsNullOrEmpty(password) || string.IsNullOrEmpty(salt)) return null;

        byte[] passwordBytes;
        byte[] saltBytes;
            
        try
        {
            // IMPORTANT: Membership provider used Unicode (UTF-16), not UTF-8.
            passwordBytes = Encoding.Unicode.GetBytes(password);
            saltBytes = Convert.FromBase64String(salt);
        }
        catch
        {
            return null;
        }

        using (var hmac = (KeyedHashAlgorithm)HashAlgorithm.Create("HMACSHA512"))
        {
            // --- Replicated ASP.NET Membership Key Logic ---
            // Do not refactor this block. It handles specific key padding used by the old provider.
            if (hmac.Key.Length == saltBytes.Length)
            {
                hmac.Key = saltBytes;
            }
            else if (hmac.Key.Length < saltBytes.Length)
            {
                var key = new byte[hmac.Key.Length];
                Buffer.BlockCopy(saltBytes, 0, key, 0, key.Length);
                hmac.Key = key;
            }
            else 
            {
                var key = new byte[hmac.Key.Length];
                for (var i = 0; i < key.Length;)
                {
                    var len = Math.Min(saltBytes.Length, key.Length - i);
                    Buffer.BlockCopy(saltBytes, 0, key, i, len);
                    i += len;
                }
                hmac.Key = key;
            }
            // -----------------------------------------------

            return hmac.ComputeHash(passwordBytes);
        }
    }
}

Conclusion

Just like in Part 1, don't forget to register this in your Startup.cs before the Identity initialization:

C#

services.AddScoped(typeof(IPasswordHasher<>), typeof(FallbackPasswordHasher<>));
services.AddCmsAspNetIdentity<MyCustomUser>();

This solution provides a seamless experience. Users log in, the system detects the old "pipe-delimited" legacy data, verifies it using the old logic, and instantly upgrades them to the modern secure standard without them ever knowing.

Migrating Optimizely 11 to 12: Handling Legacy Password Hashes (Part 1)

Mon, 01 Dec 2025 09:04:18 GMT

Recently, I was tasked with a complex migration: moving existing users from two Optimizely 11 projects to the new Optimizely 12 (ASP.NET Core). The core requirement for both projects was seamlessness—existing users needed to be able to log in with their current passwords without being forced to reset them.

This presented two distinct scenarios:

Project IdentityUserUpgrade: Already using ASP.NET Identity (but the older .NET Framework version).
Project MembershipUsersUpgrade: Still using the legacy SQL Server Membership Provider.

In this post, I will focus on Project IdentityUserUpgrade. Even though this project was already using Identity, moving from .NET Framework to .NET Core changes the underlying hashing algorithm. We need a way to bridge that gap.

The Investigation: Analyzing the Web.Config

Since the IdentityUserUpgrade project was already on Identity tables, I didn't need to migrate data between SQL tables. However, I needed to understand how the passwords were encrypted.

I started by checking the legacy web.config file, specifically looking for passwordFormat and hashAlgorithmType.

XML

<membership hashAlgorithmType="SHA1">
  <providers>
    <add name="DefaultConnection" ... passwordFormat="Hashed" />
  </providers>
</membership>

The key takeaways here were:

passwordFormat: Hashed (This is crucial for the solution below).
hashAlgorithmType: SHA1.

Note: You may not explicitly see these values in your web.config if the project was using the system defaults, but SHA1 was the standard for older Identity V2 implementations.

The Solution: The Fallback Password Hasher

ASP.NET Core Identity (V3) uses PBKDF2 with HMAC-SHA256 (or SHA512 in newer versions) and a distinct binary format. The old Identity (V2) used PBKDF2 with HMAC-SHA1.

To solve this, we need a custom IPasswordHasher that attempts to verify the password using the new format first. If that fails, it falls back to the legacy format. If the legacy format matches, we report success and instruct Identity to re-hash the password immediately.

Here is the implementation:

using Microsoft.AspNetCore.Identity;
using System;
using System.Security.Cryptography;

/// <summary>
/// A password hasher that supports legacy ASP.NET Identity V2 hashes (PBKDF2-SHA1)
/// while ensuring all new passwords are created using the modern Identity V3 standard.
/// </summary>
public class FallbackPasswordHasher<TUser> : IPasswordHasher<TUser> where TUser : class
{
    // We use the default ASP.NET Core PasswordHasher for all new hashes and primary verification.
    private readonly PasswordHasher<TUser> _newHasher = new PasswordHasher<TUser>();

    /// <summary>
    /// Generates a hash for a password using the modern (V3) standard.
    /// </summary>
    public string HashPassword(TUser user, string password)
    {
        return _newHasher.HashPassword(user, password);
    }

    /// <summary>
    /// Verifies a password against a stored hash.
    /// Tries the modern hasher first; if it fails, falls back to the legacy V2 verifier.
    /// </summary>
    public PasswordVerificationResult VerifyHashedPassword(TUser user, string hashedPassword, string providedPassword)
    {
        if (string.IsNullOrEmpty(hashedPassword))
        {
            return PasswordVerificationResult.Failed;
        }

        // 1. Attempt to verify using the current (modern) standard.
        var result = _newHasher.VerifyHashedPassword(user, hashedPassword, providedPassword);

        // If the modern hasher recognizes it, return immediately.
        if (result == PasswordVerificationResult.Success || result == PasswordVerificationResult.SuccessRehashNeeded)
        {
            return result;
        }

        // 2. If modern verification failed, check if this is a legacy ASP.NET Identity V2 hash.
        if (VerifyAspNetIdentityV2Hash(hashedPassword, providedPassword))
        {
            // CRITICAL: Return 'SuccessRehashNeeded'.
            // This tells the Identity system: "Login allowed, but re-hash this password 
            // with the new format and update the database immediately."
            return PasswordVerificationResult.SuccessRehashNeeded;
        }

        // 3. Password matches neither format.
        return PasswordVerificationResult.Failed;
    }

    /// <summary>
    /// Manually verifies a hash against the specific binary layout and parameters of ASP.NET Identity V2.
    /// Format: [1 byte: Version (0x00)] + [16 bytes: Salt] + [32 bytes: Subkey] = 49 bytes total.
    /// </summary>
    private static bool VerifyAspNetIdentityV2Hash(string storedHash, string password)
    {
        byte[] decoded;
        try
        {
            decoded = Convert.FromBase64String(storedHash);
        }
        catch
        {
            return false; // Not a valid Base64 string
        }

        // Identity V2 hashes are exactly 49 bytes long.
        if (decoded.Length != 1 + 16 + 32)
        {
            return false;
        }

        // The version byte for Identity V2 is always 0x00.
        if (decoded[0] != 0x00)
        {
            return false;
        }

        // Extract the salt (next 16 bytes starting at index 1).
        var salt = new byte[16];
        Buffer.BlockCopy(decoded, 1, salt, 0, 16);

        // Extract the expected hash/subkey (next 32 bytes starting at index 17).
        var expectedSubkey = new byte[32];
        Buffer.BlockCopy(decoded, 1 + 16, expectedSubkey, 0, 32);

        // Re-compute the hash using the provided password and extracted salt.
        // Identity V2 explicitly used PBKDF2 with 1000 iterations and HMAC-SHA1.
        // NOTE: If your legacy app used a different iteration count, update '1000' below.
        using var deriveBytes = new Rfc2898DeriveBytes(password, salt, 1000, HashAlgorithmName.SHA1);
        var actualSubkey = deriveBytes.GetBytes(32);

        // Cryptographic comparison (constant time) to prevent timing attacks.
        return CryptographicOperations.FixedTimeEquals(actualSubkey, expectedSubkey);
    }
}

A Note on Algorithms

The code above explicitly handles HashAlgorithmName.SHA1 because that was the default for my project. However, Rfc2898DeriveBytes supports other algorithms if your legacy system used them (e.g., SHA256, SHA512, or MD5). You can adjust the HashAlgorithmName parameter in the VerifyAspNetIdentityV2Hash method to match your legacy configuration.

Service Registration

Finally, to make this work, you must register your custom hasher in Startup.cs (or Program.cs). This must happen before the call to AddCmsAspNetIdentity.

C#

// Register the fallback hasher
services.AddScoped(typeof(IPasswordHasher<>), typeof(FallbackPasswordHasher<>));

// Then add CMS Identity
services.AddCmsAspNetIdentity<ApplicationUser>();

With this setup, old users can log in seamlessly. Upon their first login, the system will detect the old hash, verify it, and automatically upgrade the database entry to the new secure format.

Stay tuned for Part 2, where I will tackle the more challenging MembershipUsersUpgrade project involving SQL Membership providers!

Troubleshooting Optimizely Shortcuts: Why PageShortcutLink Threw an Error and the Solution

Wed, 09 Jul 2025 05:59:16 GMT

As developers working with Optimizely, we often encounter unique challenges that push us to explore the platform's depths. Recently, I tackled a fascinating task involving content migration and external linking, which led me down a rabbit hole of property management and ultimately, a much smoother solution. I wanted to share my journey, especially for anyone else who might encounter similar hurdles.

The Scenario: A Tale of Two Companies

Our company recently sold a subsidiary, and as part of the transition, we needed to facilitate a smooth redirection from their old content on our Optimizely site to their new home on another Optimizely instance. The core task was to convert existing pages on our site into external shortcuts, pointing to their corresponding URLs on the new company's website.

I was provided with an Excel file containing two columns: FirstUrl (the existing URL on our site) and SecondUrl (the target URL on the new company's site). My goal was to create a custom add-on that would automate this process, turning hundreds of internal pages into external links.

The Initial Approach: Properties and Puzzlement

My first instinct, and a common approach when manipulating page data in Optimizely, was to leverage the Property collection. I knew that Optimizely pages have properties like PageShortcutType and PageShortcutLink to manage shortcuts. So, I started with this:

writablePage.Property["PageShortcutType"].Value = PageShortcutType.External;
writablePage.Property["PageShortcutLink"].Value = importResponse[index].SecondUrl;

The first line, setting PageShortcutType to PageShortcutType.External, worked perfectly. This correctly flagged the page as an external shortcut. However, the second line, where I attempted to set the PageShortcutLink with the SecondUrl from my Excel file, threw a rather cryptic exception:

{"ContentReference: Input string was not in a correct format."}

This was puzzling. The SecondUrl was a valid, absolute URL string. I double-checked the format, ensured there were no leading/trailing spaces, and even tried URL encoding – nothing seemed to work. A lengthy search on Google and various Optimizely forums yielded no clear solution to this specific error when assigning a direct URL string to PageShortcutLink via the Property collection.

The Technical Deep Dive: Why the Error?

This exception, "ContentReference: Input string was not in a correct format," strongly suggests that Optimizely's internal mechanisms for PageShortcutLink (when accessed via Property["PageShortcutLink"]) are expecting a ContentReference object, not a raw URL string, even if the PageShortcutType is set to External.

Here's the technical breakdown:

PageShortcutLink's Internal Expectation: While logically one might expect to store any external URL, it appears that when you interact with PageShortcutLink through the generic Property collection, Optimizely's underlying type conversion or validation expects a ContentReference. This is likely a design choice to maintain consistency within its content management system, potentially allowing for future enhancements or stricter validation.
ContentReference Nuance: A ContentReference is Optimizely's way of uniquely identifying a piece of content (a page, block, media file, etc.) within its system. It's not designed to hold arbitrary external URLs. The exception was a clear indicator that my string wasn't being parsed into a valid ContentReference.

This highlights a crucial aspect of Optimizely development: sometimes, the generic Property accessors might have underlying type expectations that aren't immediately obvious, especially for properties that can link to both internal content and external URLs.

The "Aha!" Moment: Direct Properties to the Rescue

Frustrated but undeterred, I started looking for alternative ways to achieve the same outcome. And then, it hit me. Optimizely's PageData object, which represents a page, has directly exposed properties for managing shortcuts!

writablePage.LinkType = PageShortcutType.External; writablePage.LinkURL = importResponse[index].SecondUrl;

I swapped out my problematic Property assignments for these direct properties, and to my immense relief, it worked flawlessly! No exceptions, no wrestling with content references, just clean, straightforward assignment.

The Final Solution: Robust and Reliable

Here's the complete code snippet that successfully accomplished the task:

for (int index = 0; index < excelData.Count; index++)
{
try
{
// Resolve the existing page using the FirstUrl
var content = _urlResolver.Route(new EPiServer.UrlBuilder(excelData[index].FirstUrl)) as PageData;

// Ensure we found a page
if (content != null)
{
// Create a writable clone to modify the page
PageData writablePage = content.CreateWritableClone();

// Set the LinkType to External
writablePage.LinkType = PageShortcutType.External;

// Assign the external URL directly
writablePage.LinkURL = excelData[index].SecondUrl;

// Save the modified page
_contentRepository.Save(writablePage, SaveAction.Patch, AccessLevel.NoAccess);
}
else
{
// Handle cases where the URL doesn't resolve to a page
viewModel.ImportResponse[index].Errors.Add(new ValidationResult($"Record for '{excelData[index].FirstUrl}' couldn't be found or resolved."));
}
}
catch (Exception ex)
{
// Log the exception for debugging
// _logger.LogError(ex, "Error processing record for URL: {Url}", excelData[index].FirstUrl);
viewModel.ImportResponse[index].Errors.Add(new ValidationResult("Record couldn't be updated. Please validate the data again. " + ex.Message));
}
}

Technical Additions to the Final Code:

Error Handling and Logging: I've added a more specific error message if the _urlResolver.Route method doesn't find a page, which is crucial for real-world scenarios. Also, I've commented out a placeholder for logging the exception (_logger.LogError), which is a best practice for debugging and monitoring in production environments.
Null Check for content: It's vital to check if _urlResolver.Route actually returns a PageData object. If the FirstUrl doesn't correspond to an existing page, content would be null, leading to a NullReferenceException.

Lessons Learned

This experience reinforced a couple of key lessons for me:

Prefer Direct Properties When Available: While the Property collection is powerful for dynamic or custom properties, always check if there are direct properties on the PageData (or ContentData) object for common functionalities. These direct properties often encapsulate the correct underlying logic and type handling.
Understand Optimizely's Internal Expectations: The "ContentReference" error was a strong hint that Optimizely had a specific type in mind, even if my string looked like what was needed. Debugging these specific error messages often points to how Optimizely's APIs are designed internally.
Community and Documentation are Key (but not always exhaustive): While I initially struggled to find an exact solution for my specific error, the journey of looking through documentation and forums eventually led me to consider alternative approaches.

This task, while seemingly simple on the surface, provided a valuable opportunity to deepen my understanding of Optimizely's content model and property management. It's these kinds of challenges that truly help us grow as Optimizely developers!

Create Environment Banner that highlight current environment to editors!

Mon, 07 Aug 2023 12:48:34 GMT

Recently I got a request from editors, sometimes they forgot to check the browser URL and keep working, on wrong environment, and publish the content to wrong environment. for example, one of the editors was testing something on prep environment, and something came in between to small update to production, unintentionally he updated prop environment and thought he has done his job. So, editors requested if can we have banner on top of every page that indicate the current environment, It could help us to minimize the human error like this?

Let us see how I fulfill this requirement.

First of all, I created a new component class in business folder like this.

[Component(PlugInAreas = "/episerver/cms/action",
Categories = "cms",
WidgetType = "yourCompanyName/environments/environmentHighlighter")
]
public class EnvironmentHighlighterComponent
{}
There are three important part in component
PlugInAreas:- it defines where in cms the content of Component should display. there are various ways to get the value for PlugInAreas is to Use
EPiServer.Shell.PlugInArea class

But for my requirement I did not found any value that could be used for global menu area in EPiServer.Shell.PlugInArea. So, I decided to check what pre-defined Components are available into the system. Among various predefined Components Toolbar was most closed to my requirement

on further peek on the Toolbar definition, I found "/episerver/cms/action" PlugInAreas worked for me.
1. 1. Categories: I wanted to show the component for all cms pages, so I simply put "cms" as a category. other value could be "dashboard".
  2. WidgetType: this value belongs to various setings of your ClientResources, for example Editors, widgets etc. for our case we used
    "yourCompanyName/environments/environmentHighlighter"

Second part is update or create new module.config file at the root of the website and update like this
<?xml version="1.0" encoding="utf-8"?>
<module>
<dojoModules>
<add name="yourcompanyname" path="Scripts/widgets" />
</dojoModules>
<dojo>
<paths>
<add name="yourcomapanyname" path="Scripts" />
</paths>
</dojo>
</module>

in the above config file, we are trying to map widgets folder with ClientResources folder.

Third part is to create Dojo script file. in our case file name is environmentHighlighter.js file.
define([
"dojo/_base/declare",
"dijit/_WidgetBase",
"dijit/_TemplatedMixin"
],
function (declare, _WidgetBase, _TemplatedMixin)
{
return declare("yourcomapanyname/environments/environmentHighlighter",
[
_WidgetBase,
_TemplatedMixin
],
{
templateString: dojo.cache("/EnvironmentHighlighter/Index")});
});

there are two important parts in above script.

declare statement: the value is same as WidgetType value.
templateString statement tell the dojo from where the html should come from, in our case EnvironmentHighlighter is a controller and Index is a method.

Four and final part is create controller, view and setup route, these parts are self-explanatory
Controller
public class EnvironmentHighlighterController : Controller
{
public ActionResult Index()
{
return PartialView();
}
}
View:

@{
var currentEnvironment = Environments.CurrentEnvironment;
var greenColor = "#2cd31f";
var orangeColor = "#ff6a00";
var colorScheme = currentEnvironment == Environments.Environment.Production.ToString() ? orangeColor : greenColor;
}

<div style="text-align: center;">
<div style="width:300px; margin:0 auto; background:@colorScheme; color:#FFF;">
You are working on @currentEnvironment environment
</div>
</div>

Routing:
RouteTable.Routes.MapRoute("EnvironmentHighlighter", "environmenthighlighter/Index", new { controller = "EnvironmentHighlighter", action = "Index" });

That’s it!