For most of my career I've been an ASP.NET dev and a JavaScript dev. If I was going to say I was more of an expert in one of them it would be the .NET side of things but I've never really lost touch with JavaScript.

Right now I think it's fair to say technologies in the world are starting to shift how we build websites, with JavaScript frameworks reaching a point with features like static site generation where they actually now offer a decent performance incentive to use them. At some point Blazor may get to a point where it reverses this, but right now there's a compelling argument to move.

For a ASP.NET dev this can be a daunting task. You might be thinking of trying out a headless CMS with a JavaScript front end, but just take a look at this screen grab from Prismic's sdk list.

There's 7 different JavaScript based SDK's listed there! Over half of the total and none of them are that Angular thing you had heard about. Where do you start?

Lets compare to .NET

Well recently I've been updating my JS skills again trying out some of the frameworks I hadn't used before, so I thought I'd share some learnings. The good news is as always it's not really as different as it first seems. To take some of the pain out of understanding what all these frameworks are I thought it would be good to try and relate them back to .NET and what the almost equivalent is.

Assembly Code

No not actual assembler but what does our code actually compile to. In the .NET world we have CIL (Common Intermediate Language), previously known as MSIL (Microsoft Intermediate Language) that our C#, F#, VB etc all compile down to before then being converted to the correct machine code for where they run.

In the front end world think of JavaScript being a bit like this (apart from the fact you actually write JavaScript and we don't write CIL).

View Engine

To render views into HTML, in the ASP.NET world we have Razor, but not just Razor. We also have WebForm, Brail, Bellevue, NDjango (see more here), it just happens that we mostly just use Razor.

I see the equivalents of these being ReactJS, VueJS and Angular. Its not an exact match as they also aren't exact equivalents or each other, but they're largely your functionality that will take a model and turn it into HTML.

Web Application Framework

The problem with the name framework is it applies to basically anything, but this is what I'm going with for describing ASP.NET MVC/ASP.NET Razor Pages/Web Forms, you know all those things built on-top of .NET that make it a website rather than a desktop app. They do things like routing, organising our files into controller and view folders, know how to respond to http requests etc.

Here we have Next.js, Nuxt.js and maybe Gatsby. The link between these and View Engine is a bit stronger than the ASP.NET MVC world as you essentially have a one to one mapping Next.js -> React, Nuxt.js -> Vue but they are what adds routing, static site generation and organization to your code.

Lower Level Framework

Now this one could be wrong :)

In .NET we have different version of the framework. e.g. .NET Framework /3.5/4, .NET Core, .NET 5, Mono. On the front end side they have Node.

Languages

In .NET we have choices including C#, F#, VB among other.

JavaScript has JavaScript (which I know I said was assembly), TypeScript, Coffee Script maybe more.

Not so daunting

There's probably a bunch of flaws with my comparison list and reasons people can point out why things I've said are the same are in fact different, but my point was really to show that while .NET may appear as one button on a SDK list alongside 7 JavaScript based SDK's its not that different. Out of the 7 Node is based on JavaScript. Vue and React are based on Node, and Next/Gatsby/Nuxt are based on Vue/React. There just isn't the same concept of all of it being built by one company or one particular combination being dominant in the same way that ASP.NET MVC + C# + Razor has been for the last generation of .NET websites.

If you have a website where you are implementing 3D Secure payments, you may find that you have an issue where on receipt of the payment setup confirmation the users Session ID has changed with no apparent cause.

Lets have a quick run through of the payment process in this scenario (this is roughly how SagePay and WorldPay both work):

1. User completes payment details on your site (some wizardry normally happens at this point with an iFrame for the card number to maintain PCI compliance) and the form is submitted to your server
2. You server call's an API from the payment gateway to setup a 3D Secure payment. It passes the users Session ID along with all the payment details.
3. Payment gateway responds with a URL for you to redirect the user too by posting a form to it. You do this, likely in an iFrame so that the page still looks like your website (otherwise it's a very ugly page).
4. User may or may not get prompted by some sort of authentication by the bank. This could be something like receiving a text message with a code to enter.
5. When authenticated the user is sent back to your website (in the iFrame) with a post request.
6. Your server picks out the form details from the request and then calls an API to complete the transaction. In this API call you send the Session ID so that the payment gateway can validate it is the same as the one at the start of the process.
7. Confirmation shown to the user.

Introducing the Same Site Cookie Policy

In 2020 a change made to how cookies function in browsers to defend against cross site scripting. Troy Hunt has a brilliant explanation of the issue with how cookies used to work and how this has changed here. I'm going to try a much shorter explanation;

When a request is made from a browser, as part of the request all the cookie values for that domain are sent with the request. This will include one for the Session ID. The theory here is that because the cookies are only being sent to the domain which set them in the first place, then information is only being shared back with the place that set it to begin with, which is therefor safe.

However the workings of the internet and what domain a button click might call isn't overly obvious to most people. So what if clicking a link on one site causes the user to be redirected to another site? Answer: all the cookies are still sent. The same thing happens if a form is posted from one site to another site. The problem here is that if you are authenticated on the other website, then its possible for a cross site scripting attack to be using your session via your browser without you even realising you were on the site again. This is why it's always a good idea to log out of websites!

The introduction of the same site policy changes how cookies work with three options:

1. None: which is what the browsers used to do. i.e. send all the cookies with cross-origin request
2. Lax: some limits on sending cookies with cross-origin request
3. Strict: tight limits on sending cookies with cross-origin request

None is sending everything and a strict policy will basically stop cookies from being sent when they have a cross-origin request.

A Lax policy is slightly more interesting though, because it depends if the request is a GET or a POST. If it is a GET then the cookies will still be sent, which means that if you follow a link from another site or a search engine your cookies will still be sent to the site. However a POST (like what the 3D Secure page is doing) will no longer send the cookies.

If the policy isn't set, then Lax is used as the default.

So why is my Session ID changing?

The problem is that post request back to your site, unless the Session ID had a cookie policy of None then the Session ID cookie won't be sent. The server will then see that there is no Session ID and treat the users as if they are new on the site and as a result start a new session. From this point on the user has lost the old session and you can't complete the payment. Worse still they've probably just been logged out and anything else using session data has also been lost.

In .Net 4.7.2 and up, Microsoft has implemented the ability to set the cookie policy of the session ID. You can do this in your web.config file like this:

You can find more about this here. In everything older the policy wont be set and will default to Lax.

However just because you can set the cookie policy to None, it doesn't mean you should. After all, that just re-opens the vulnerability the browser was trying to protect against.

The solution I went with was to have a page that the users is redirected back to from the payment gateway that does nothing other than re-submit the values from the payment gateway to the site again. This way I can be sure of what form data is being posted to the site, and when I re-post it, it is a same site post and not a cross-origin which means the Session ID cookie will be sent.

To stop my initial page setting a new session cookie (which it will try to do because it won't recieve one), I use the IIS URL Rewrite module to strip out the set cookie response headers from the page.

You can do this with an outbound rule as follows:

With this solution the cookies are still secure as the policy is set to Lax and I can take payments using 3D Secure which will soon become a requirement.

So here's the scenario, you have a web application which people log into and some of the pages (like a dashboard) contain ajax functionality. Inevitably the users session expires, they return to the window change a filter and nothing happens. In the background, your JavaScript is making http calls to the server which triggers an unauthorised response. The front end has no way to handle this and some errors appear in the JS console.

A few things are actually combining to make life hard for you here. Lets take a look at each in more detail.

WebAPI and the 301 Response

To protect your API's from public access a good solution is to use the Authorize attribute. i.e.

However chances are your solution also has a login page configured in your web.config so that your regular page controller automatically trigger a 301 response to the login page.

So now what happens, is instead or responding with a 401 Unauthorised response, what's actually returned is a 301 to the login page.

With an AJAX request from a browser you now hit a second issue. The browser is making an XMLHttpRequest. However if that request returns a 301, rather than returning it your JavaScript code to handle, it "helpfully" follows the redirect and returns that to your JavaScript. Which means rather than receiving a 301 redirect status back, your code is getting a 200 Ok.

So to summarise your API was set up to return a 401 Unauthorised, that got turned into a 301 Redirect, which was then followed and turned into a 200 Ok before it gets back to where it was requested from.

To fix this the easiest method is to create are own version of the AuthorizedAttribute which returns a 403 Forbidden for Ajax requests and the regular logic for anything else.

Now for any Ajax requests a 403 is returned, for everything else the 301 to the login page is returned.

Redirect 403 Responses in AngularJs to the login page

As our Ajax request is being informed about the unauthorised response, it's up to our JavaScript code trigger the redirect in the browser to the login page. What would be really helpful would be to define the redirect logic in one place, rather than adding this logic to every api call in our code.

To do this we can use add an interceptor onto the http provider in angular js. The interceptor will inspect the response error coming back from the XmlHttpRequest and if it has a status of 401, use a window.locator to redirect the user to the login page.

You'll notice a line updating the headers. This is to make the IsAjaxRequest() method on the api recognise the request as being Ajax.

Finally you'll also notice the loginUrl being passed into the interceptor. As it's not a great idea to have strings like urls littered around your code, this is using a value recipe to store the url. The code to do this is follows:

This can happen in any ASP.NET Web Application, but as Sitecore 8's default web.config file is now 246 kb this makes it extremely susceptible to exceeding the default 250 kb limit.

To change the size limit you need to modify/create the following registry keys:

HKLM\SOFTWARE\Microsoft\InetStp\Configuration\MaxWebConfigFileSizeInKB  (REG_DWORD)

On 64-bit machines you may also have to update the following as well

HKLM\SOFTWARE\Wow6432Node\Microsoft\InetStp\Configuration\MaxWebConfigFileSizeInKB (REG_DWORD)

You will probably find that these keys need to be created, rather than just being updated. After changing them you will also need to reset IIS.

Alternatively

Alternatively you can leave the default values at 250 kb and split the web.config files into separate files.

More information on doing this can be found here:

http://www.davidturvey.com/blog/index.php/2009/10/how-to-split-the-web-config-into-mutliple-files/

My personal preference for Sitecore projects is to update the the max file size as this allows keeping the web.config file as close to the default install as possible. The benefit of doing this is it makes upgrades easier, rather than needing to know why your web.config doesn't match the installation instructions.

There's various ways to add bundling and minification to a site, but one of the easiest is to use Microsoft's support from the Microsoft.AspNet.Web.Optimization package. This implementation has some great features including:

• Automatically create the bundles and minify them as files are changed
• Create unique urls to each version of a bundle to force browser refreshing of the file
• Debug mode which outputs links to the raw files rather than the bundled minified version

The functionality is also fully compatible with Sitecore. To use it in your Sitecore solution follow these steps:

1. Add Microsoft.AspNet.Web.Optimization to your project from NuGet. This is the package from Microsoft that contains the functionality to do bundling and minification

2. Create your CSS and Javascript bundles. Where you put the logic for this is up to you but it will need to run when the application starts. Outside of Sitecore my main development is on bespoke ASP.NET MVC and Web API projects so I like to organise startup scripts into an App_Start folder and reference it from the Application_Start event in the global ascx file.

If you are running a Sitecore instance with multiple sites or if you do not have direct access to the production config files, it may be better to keep the logic separate and use a pipeline to create the bundles.

My bundle definitions would look something like this

And in my Global.asax.cs file I would have some logic like this to call the other function

3. Replace your Javascript/CSS references in your layout or rendering files with a call to render the bundle

Webforms

MVC

4. In your web.config file there are a couple of changes needed to get things to work.

First you need to set an ignore url prefix to stop Sitecore trying to resolve the URL to the bundle. In this example mine is called bundles (note: you should add the prefix the what is already in your config file. e.g. |/bundles)

Next a dependant assembly binding needs to be set up for Web Grease. Without it you will see an error about the Web Grease version number

If you have done this and are still getting a version number error check the assembly binding tag. Older versions of Sitecore have the applies to property set which may be only applying the bindings to .Net 2 and you may be using .Net 4.

5. If you are using IIS7 you will also need to make a change in your web.config file

6. Publish your changes into your Sitecore site. Depending if you have compilation mode set to debug or not you will now either have a bundle reference for all your JavaScript and CSS or the individual file references.

For various reasons at times you may need to create a 301 redirect to another URL. This could be as a result of a page moving or you just need to create some friendly URLS.

As a developer you may be tempted to do something like this in code...

But do you really want your project cluttered up with files who's only purpose is to redirect to another page!

You may also be tempted to try doing something with .NET's RouteCollection. This would certainly solve an issue on creating a redirect for anything without a file extension, but there is a better way.

In your web.config file under the configuration node create something like this

The location path specifies that path on your site that this redirect will apply to. The destination value in the httpRedirect is where the redirect will go to. As well as setting Permanent for the httpResponseStatus you can also specify Found or Temporary depending on your needs.

A users session on an ASP.NET site by default will time-out after 20 minutes. This however can be changed through either the web.config file or IIS.

To edit through the web.config file you need to edit the sessionState tag under system.web

Or through IIS click on your site name and then click Session State under the ASP.NET heading. There will be a field labeled Time-out (in minutes).

The value you enter for time-out must be an integer.

Help it doesn't seem to work!

If your sessions still seem like there timing out after 20 minutes it could be because your site isn't very active.

The application pool for your site also has an idle time-out that is set by default to 20 minutes. When the idle time-out is reached it will cause your application pool to recycle and therefore loose any active sessions (that's assuming you have the session state mode set to In Proc). Therefore it is a good idea to increase this to whatever you have set the session time-out to.

To do this go to your sites application pool in IIS, click advanced settings on the right and then look for the Idle Time-out (minutes) setting and update this to be the same as your session time-out value.

In ASP.NET 2 Microsoft introduced the Membership provider. By many accounts it is not perfect, but as a one size fits all solution it's not bad. Plus it had a major advantage that a lot of other people would also be using it, so if you wanted to grab a forum solution to stick on your site, chances were it would use the same Membership provider.

Now though there is a second Membership provider from Microsoft called SimpleMembership. It simplifies a lot of things that weren't needed with the original Membership provider and also introduces support for working with OAuth providers. Not only that but if you create the MVC 4 project from the default template that is what your solution will be set up to use.

The problem however is Membership and SimpleMembership are not compatible. They store their information in separate tables and if you do try to copy all the users from one to the other, you will soon discover the hashing algorithm used on the password is different. You probably also had all your passwords one way hashed so you can't even generate the new ones.

There is a solution however. Paul Brown has written a nice bit of code to update the MVC 4 account controller so that when your users log in they will first be authorised against SimpleMembership, if that fails it will then authorise against the original Membership and if that succeeds it will generate the new password in SimpleMembership using the one just provided by the user.

Over time as your users log in the will be slowly migrated over. The second time the log in the SimpleMembership will authorise them and the extra code won't even be hit.

http://pretzelsteelersfan.blogspot.co.uk/2012/11/migrating-legacy-apps-to-new.html

If you're like me you may have gone into design mode in visual studio 2010 hoping to do some work only to be greeted with the following message.

Which initially is a bit confusing, as your site may have just run without any problems. But even so you go to check the placeholders anyway and they look fine. Then you copy and paste the ID's out of the Master Page just to be sure, but still no luck. Check through the Master Page itself and that also looks fine, no squiggly lines to be seen. Finally create a new WebForm linked to the master page, but even this gives the same error.

Now if you have the problem I had, look at the title tag in the Master Page. Does it say <title /> or <title></title>? If it's the first then that's your issue. By default VS2010 will put in the correct tag, but if like me you've just slapped in some HTML from an old project or from a PSD conversion that's been done for you, then chances are you may end up overwriting the title tag as well.

I don't know if I should be happy to now know about this, or just concerned that it's taken me this long to discover. But one issue that surfaces time and time again when programming in ASP.NET, is that issue that pressing enter/return in a text field doesn't always do what you want it to do. 

On a normal website you can have many forms each with their own submit button which becomes the default action when pressing return on one of the forms fields. However in ASP.NET Web Forms there is only ever one form on a page, but there could be 10 different buttons each needing to be the default action for a particular text box. 

The solution as it turns out is very simple and you have two options both introduced in .NET 2.0 (yes that's how old it is!) 

1. Default button for the form. If your page has more than one button, but there is only one that you want to fire when you hit enter then in the code behind you can just type... 

or it can also be specified in your aspx file 

2. If you need to be more specific a panel can also have a default button...