Security

Roles are easy to create in Sitecore but sometimes you might want to ensure that some specific roles always exists. Not a very common scenario but nonetheless it happens. Once upon a time we needed to be able to ensure that a long list of specific roles always existed on the production instance otherwise some of our code and an integration to an external system could fail. Inspired by the EnsureAnonymousUsers processor in the initialize pipeline I made the following small module. It is very similar to the code I shown in my previous post on how to disable the admin user. ...

A basic Sitecore 1-0-1 security check is to see if the admin account still uses the standard password. It is commonly seen that sites go into production with the admin / b still working. A way to ensure this does not occur is simply to disable the admin account when building to release or other public facing configurations. Disable Sitecore admin user We first create a setting for toggling if the admin user should be disabled. ...

Or how to scare any project manager, sales guy or customer into choosing to run their site on https. This is not going to be a lesson in how to obtain cookie information sent over a network. You can find a ton of youtube videos and other resources on how to setup a tool like cain and abel to do this in minutes. This post is not really about Sitecore either, the example just shows a Sitecore site, ...

I would always recommend running all production site cms’ using security on the transport layer (https). Sitecore or no Sitecore, it is not safe to first send username and password unencrypted and then following having an insecure session cookie for the authentication information. This applies for both extranet users and the backend administrators. A basic best practice is simply to ensure that all requests containing authentication information such as the .ASPXAUTH cookie used by ASP.NET, only gets transferred using the https scheme. ...