One "security practice" that I have found very useful is to put a small-random-delay when someone enters an incorrect email and password during the login process. Combined with other good practices, this approach brings many benefits.
I'm on of those that pretty much abuse the usage of the em dash in my writings. It is mostly due to my inability to form elegant sentence structures — that's another story. For the longest time, I got by with typing two short en dashes, and MS Word automatically converts them to one em dash. I don't have that luxury when editing markdown blog files with just a text editor. There are a few ways to get those sweet sweet em dashes on Windows. These options are order from least painful to most painful — in my opinion.
Alright, admittedly the title sounds a bit like a click bait -- but that was essentially what my team was told in a training. At first, we got defensive: "What do you mean I don't talk to the users? I've been developing products for years. Where do you think my 'requirements' came from?" Turns out, the training staff were right. Let me elaborate.
A few months ago, I created a bot to scan GitHub for publicly exposed Azure Storage connection strings. The bot then notifies the repository owners (to its best effort). What gave me the idea? Well, I accidentally pushed a connection string to GitHub. Even though it was a personal demo project and there's no sensitive data, I thought that it was still a poor practice on my part.
Upon launch, the scanner quickly found a multitude of exposed connection strings. Since then, it has been detecting about 100 some valid unique connection strings per month:
The numbers aren't really too surprising. It's so easy to just hard code the connection string somewhere and tell yourself "I'll remove it later. Just let me quickly get the prototype out." Guess what, if you're using GIT and making commits along the way, it's in your commit history.
At //BUILD 2016, Microsoft announced the preview of the Bot Framework. To paraphrase the documentation, this framework helps facilitate conversations between you and users via SMS messaging, Skype, Slack, etc. The framework takes over the burdens of setting up communication pipelines, managing user state data, and more. From the Bot Framework developer page:
This post will walk us through the process of creating a bot that can keep tally using the built in user state data. You can test out TallyBot at https://tallybot.azurewebsites.net.
Recently, someone from our team sent out a code review. I noticed that the call to
base() from some class contructors were automatically removed by ReSharper. At first I didn't think it would make a difference, then I got curious and did a little testing. There's a subtle difference between explicitly calling the
base() constructor or let the base constructor called on by .NET.
I'm probably late to the party, but in this post I'll discuss a little bit about what CloudFlare provides, what one loses or what one might have to pay extra for.
There are a lot of cases where we need to perform an async task then rethrow an exception.
For example, we want to put a message in the queue when there's a processing failure. This action of queuing a message could be async. Unless you're using C# 6, it's not possible to do
await inside a
catch block. In this post, I'll show some common incorrect approaches, why they are incorrect, and show the recommended approach for this particular problem.
As simple as it sound, the .NET framework does not have anything built in that one can use to read each line of a text file, and find the seek position (to determine where the next line starts). In this post, I'll give a little background about the problem I had, or why I needed to do what's described in this post; and the approach I had taken.