Just a quick note – if you want to use an IIS rule to redirect users from HTTP to HTTPS, the following rule seems to work pretty well. You’ll need the IIS URL Rewrite module installed.
<rule name="Redirect to HTTPS" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="^OFF$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther" />
</rule>
Okay, I’ll admit, I felt I knew the answer to this – but after my work with the CustomCache object, I felt that this was an interesting experiment.
If I just need to read string, is it faster to read from the configuration file with Sitecore.Configuration.Settings.GetSetting() or using the cache?
Well, the short answer is that the file is roughly twice as fast. Good, no cache needed! Continue reading “Is reading the web config faster than Sitecore’s Cache?”
Previously I posted about the generalities of implementing a Cache in Sitecore using the CustomCache class. Well, I’ve actually implemented a few caches for Sitecore using this; let’s have a look at my general pattern. Continue reading “An example caching class for Sitecore”
A quick shout out to this page – Adding Options to Sitecore Applications by Alistair Deneys . It’s a nice guide about how to do exactly that – add options to the menus in Sitecore. It was pretty straight forward to do for the User Manager:
The parameters to the Execute method contains which usernames have been selected. This is as a pipe separated list:
public override void Execute(CommandContext context)
{
string usernamesParameter = context.Parameters["username"];
string[] usernames = null;
if (!string.IsNullOrEmpty(usernamesParameter))
{
char[] splitter = {'|' };
usernames = usernamesParameter.Split(splitter, StringSplitOptions.RemoveEmptyEntries);
}
That might help.
I was configuring a new Sitecore 8.1 instance. It’s a vanilla, straight-off-the-installer instance, and yet I noticed that the node’s request validation was off:
<pages validateRequest="false">
This did, at least, come with a comment above it:
If requestValidationMode attribute of httRuntime node is set to 2.0, Sitecore requires this setting to be set to “false” for Sitecore client to work and it shouldn’t be changed. You can however set ValidateRequest attribute in the @Page directive to “true” for your layout .aspx files.
This is bonkers. The default configuration for this site is to remove request validation on my brand new Sitecore instance on the off-chance I should want to configure it to use an older, non-default requestValidationMode. Instead, I should stumble across this comment in the web.config file and add the appropriate attribute to all the layouts of my solution. And someone thought that this was a good idea?
Even if I were upgrading and I did rely on the httpRuntime requestValidationMode being 2.0, I would prefer that this was set to true, with instructions for how I should handle it in the case of an upgrade.
Crazy. One to be aware of.
This one puzzled me a bit – but I wanted to encrypt my viewstate in Sitecore. I set my machine key, and set my algorithms – but it didn’t seem to do anything.
Well, the <pages> node has a viewStateEncryptionMode setting.
<pages validateRequest="true" viewStateEncryptionMode="Always">
Turn that on, and all seems good.
I recently had to work with a Sitecore instance where one of my colleagues – who has gone – had not documented the password.
The quickest answer I could find to this was to reset the password to its default:
-- Might want to check that 'B09BBCDE-9B3C-4DCD-B69E-67F615CE01E9' is your Administrator
Update [aspnet_Membership]
set [Password] = 'qOvF8m8F2IcWMvfOBjJYHmfLABc=',
[PasswordSalt] = 'OM5gu45RQuJ76itRvkSPFw=='
where UserId = 'B09BBCDE-9B3C-4DCD-B69E-67F615CE01E9'
