Generating your own hexadecimal encryption keys may be very useful, especially when you are hosting your web application on a web farm of multiple servers. Providing unified security tokens on application level will ensure that your page state will be preserved across postbacks.
If you want to, you can simply type in your encryption keys yourself using the keyboard and your own mind as a randomizer. Just make sure they are of the proper lengths (48 HEX characters for decryptionKey and 128 HEX characters for validationKey) and you are good to go.
If you are feeling more geeky, however, you might want to try the programmatic way of creating your keys. Under normal circumstances, you could use the regular Random class as randomizer, but why not use the more advanced Cryptographic Service Provider, which apparently offers better security? »Read More
You may have noticed that when your ASP.NET pages are running in a hosted environment, there are issues with preserving and parsing postbacks.
An ASP.NET application is not particularly well-equipped for handling postbacks on hosted servers out of the box. The reason for this is that postbacks (and ViewState) normally get encrypted (hashed) so that they cannot be tampered with on the way back to the server.
The keys used to encrypt the information stored in ViewState are supplied by the configuration files. Say hello to decryptionKey and validationKey.
Just as all other configuration properties, system.web.machineKey is normally specified in Machine.config, which—as its name implies—is unique to every machine. You do not have to provide your own hashing codes – they are supplied (randomized) by the IIS installer. »Read More
The original Twitter button is nice and useful. It has one major disadvantage though – it comes as an
In this post, I will show you how to make a Twitter share button (or a ‘tweet button’) that looks exactly like the original, loads lightning-fast and does not query any server but yours.