I noticed something strange in Sitecore; for most of my nodes (not the Sitecore node!), the 13th Hex character of the identifying GUID is ‘4’.
I had a list of about 50 of these, and my eye was drawn to the pattern. Now, I thought Guids were entirely random, except that the chance of 50 page template IDs all having a 4 at that character was infinitesimal.
Weird. Except it turns out that they’re not random. I had no idea that there are different versions of guids, or than that character defined the version of the GUID.
This requires a test, so I wrote a program to print Guid.NewGuid() a lot:
All of them are 4s.
- GUIDs aren’t entirely random.
- They might not be very random at all, looking at some of the other GUID versions.
- Which is why they shouldn’t be used as a source of entropy for encryption.
- I still have things to learn.
We have been having a problem with Sitecore in Azure PAAS – it appears that when auto-scaling scales out, App Services are being put into rotation before they have started up. This is causing all sorts of weirdness.
Sitecore support recommended making sure that we had Application Initialization configured. That seems a good idea. I’m not sure why the guys who set up this instance didn’t; perhaps they were unaware of it (and to be fair, it’s something I’ve not looked at before).
Continue reading “Application Initialization for Azure Service Apps (and Sitecore)”
Google Tag Manager (GTM) is a tool that lets marketers put code for tracking users/analytics onto a website without having actually change the code of the website. Essentially, Google Tag Manager will inject the code, after the page has loaded. “Tags” in this instance aren’t just #hashtag, but are snippets of code that can record data and send it to third party services.
When uninstalling Sitecore 9, sometimes you have to delete the services it creates in Windows by hand.
The command for this is:
sc delete [service name]
Service name can be found on the properties of the service. Don’t forget to delete them both.
We all have to get zero errors when compiling solutions, but we all aim for zero warnings, too, right?
Supressing Code Analysis errors is easy enough – and I recommend using code analysis rules (though you don’t need to enforce ALL of them. Consider what rules are relevant.)
However – what do you do if you have errors like this, it can be a problem:
6> blah\Caching\TokenCacheItem.cs(39,48,39,65): warning CS0067: The event ‘TokenCacheItem.DataLengthChanged’ is never used
The thing is, I need DataLengthChanged to fulfil an interface. But yes, it isn’t used. Oh, the conundrum.
What I hadn’t realised was you can disable compiler warnings (steady – careful!). See: https://stackoverflow.com/questions/3820985/suppressing-is-never-used-and-is-never-assigned-to-warnings-in-c-sharp/3821035#answer-3821035
We’re instructing the compiler to disable the warning for rule 0067, which is the error given above, and then immediately after the problematic line, we’re re-enabling it.
And as noted on the post…
Caveat: As per the comment by @Jon Hanna, perhaps a few warnings is in order for this, for future finders of this question and answer.
First, and foremost, the act of suppressing a warning is akin to swallowing pills for headache. Sure, it might be the right thing to do sometimes, but it’s not a catch-all solution. Sometimes, a headache is a real symptom that you shouldn’t mask, same with warnings. It is always best to try to treat the warnings by fixing their cause, instead of just blindly removing them from the build output.
Having said that, if you need to suppress a warning, follow the pattern I laid out above. The first code line, #pragma warning disable XYZK, disables the warning for the rest of that file, or at least until a corresponding #pragma warning restore XYZKis found. Minimize the number of lines you disable these warnings on. The pattern above disables the warning for just one line.
Also, as Jon mentions, a comment as to why you’re doing this is a good idea. Disabling a warning is definitely a code-smell when done without cause, and a comment will prevent future maintainers from spending time either wondering why you did it, or even by removing it and trying to fix the warnings.
Roll on zero-warning compilations.
Finally, the web is really moving to using HTTPS (thank you Google/Chrome!) This change is long overdue, and it will be good to finally be able to eliminate the vulnerability of HTTP.
“But“, cry some customers, “I don’t wanna pay for certificates!“.
Bought TLS certificates, well, cost money, and often non-technical customers don’t see any value in them. All they see is cost. If only there were a free alternative.
Good news! LetsEncrypt freely offer free DV certificates for free. That is, in fact, their raison d’être. Bad news – they only last 90 days. Bugger. Our support team won’t dreadfully want to have to renew lots of certs every 90 days. If only this could be automated… Wait, it can be!
One of my colleagues mentioned using WinAcme to get/renew certificates with LetsEncrypt, so I thought I’d give it a go. How hard can it be? Continue reading “Using LetsEncrypt with IIS via WinAcme”
So, the NCSC has been running a study on the prevalence of the ‘Top 1000 Passwords’. It’s useful stuff, but I wondered – just how frequent are these passwords? How can they know? Where did this list come from?
I noticed, for example, that the list included baseball, which I gather is a degenerate form of rounders. It’s certainly not what I’d expect on a UK-centric list of passwords. Similarly, chicago, and redsox were unlikely. (There are, however, cricket and wanker, so it isn’t an entirely Americanised list).
I also noticed some passwords – like rasdzv3 – that I couldn’t see any obvious reason for being particularly popular.
Anyway – I wondered – how frequent are these? What was the most frequent? Continue reading “A brief analysis of the NCSC’s “Top 1000 Passwords” list”