Distribution of credentials to new users of a system is often done in an insecure way, with passwords being sent over unsecure e-mail. With ASP.NET Identity, the password recovery functionality can be used to create a secure account activation mechanism.
The scenario for ASP.NET Identity, in the default MVC template is to let users self register. Then there are mechanisms to confirm the e-mail address, to make sure that the user actually is in control of the given e-mail address. There are also support for letting the user associate the account with external sign on solutions such as Google, Facebook and Twitter. That’s perfectly fine, but not for most applications I build.
I’m building line of business applications. They are actually often exposed on the Internet as they need to be available for partners. But, they are not meant to be available through self registration for anyone on the Internet. Those applications are invite only. That means that a user account is created for a new user. Then that user somehow has to be notified that the account has been created. The usual way to do that is to create the account, set a good password like “ChangeMe123″ and send the user a mail with the new credentials. There are two problems with this
- A lot of users don’t get the hint and keep the “ChangeMe123″ password.
- The e-mail can be sitting unread for a long time in the inbox, until someone gets hold of it – and the account.
Fortunately, there is a much more secure way to do account activation with ASP.NET Identity without much coding at all – by reusing the password recovery mechanism.
This is a guest post by Albin Sunnanbo, introducing a burst filter preventing log4net from filling up a support mailbox.
One Friday afternoon, just before leaving for the weekend, I glanced at our support mail inbox.
The unread counter was literally spinning. Three mails a second.
To make a long story short we had two problems.
A lost db connection due to a DNS failure.
A mail logger that tried to nuke Outlook into oblivion. A mail logger that took a while to stop because we could not reach our server due to the aforementioned DNS failure.
This incident taught us two lessons. Write down the IP addresses of all your servers and throttle your logging.
That project mentioned above used Enterprise Library Logging block.
When starting a new project I decided to try log4net for logging. I also decided to not repeat previous mistakes.
So you created an awesome pull request with a couple of features, but the evil(?) maintainer (could be me) just denied it and said you shouldn’t make pull requests from master? Then you’ve come to the right place to learn what went wrong and how to fix it.
Current (Incorrect) State
Looking at the history of your repository, it probably looks something like the image to the right. There’s a base commit and then you’ve added one commit for each of the features to it. And everything is done on the branch
The image was created with Git Extensions. Although I prefer using the command line when working with git, having a tool that can display the branches and commits graphically is indispensible to understand what’s happening.
Doing everytying on
master as shown in the image is wrong for a couple of reasons that might not be obvious when first starting working with git.
- Every single feature should be created in its own branch. Branches are so lightweight in git that it’s okay to branch all the time.
- Submitting a pull request from your own
master branch is a recipe for disaster, as it effectively prevents you from getting the latest code from the upstream repository (more on that later).
Unfortunately it’s easy to end up in this situation with git. Fortunately, it’s also quite easy to fix.
It’s call for papers season and I’m preparing abstracts and sending them off hoping that I’ll be accepted with my talks. What surprises me is how huge quality difference there is between different conferences in their call for papers (CFP). It’s basically anything ranging from very detailed information to a
I still have quite limited experience in submitting to conferences (and even less experience of being accepted). But when looking at what’s in a good CFP I think that is actually an advantage. A seasoned speaker will know how to write an abstract and what to expect – and what to demand(!) from the conference organizers. Someone less experienced need more information. To get relevant content and a wider selection of speakers it should be in the interest of conference organizers to have a good CFP.
This is a guest post by Albin Sunnanbo introducing a great hack to work with mails in test environments.
If you have a .NET application that sends emails, this is probably something for you.
PickupMailViewer is a simple web viewer for emails saved by the
specifiedPickupDirectory SMTP setting in a .NET application.
Download the source, publish to your test server, configure pickup directory and you should be up and running within five minutes.
Outgoing Emails in Test Environments
In your test environment will typically not send real emails, but rather use the specifiedPickupDirectory delivery method for your SMTP-settings in
web.config. This puts all outgoing emails as *.eml files in the file system instead of sending real emails.
IMHO that is the way to go regarding emails in your test environment.
However, there is one drawback, the emails gets dropped in a folder somewhere on your test server. Typically in a location that nobody looks at regularly. In my case I first have to connect a VPN, then open a remote desktop connection to our server, open the folder and copy the desired file back to my own computer (no eml viewer, a.k.a. Outlook, on the test server) and finally open it in Outlook.
Even worse for our testers that don’t even have permissions to login on the test machine. They have to ask a developer to get their emails out of the test system. As you can imagine this only happens when it is absolutely necessary.