Pokud Vám IIS pro nově zakládané web-site přednastavuje jinou verzi ASP.NET, než si představujete, můžete toto výchozí nastavení ovlivnit spuštěním příkazu aspnet_regiis.exe od nově požadované verze ASP.NET s níže uvedenými parametry:
aspnet_regiis -sn W3SVC/
Utilitu aspnet_regiis najdete v C:\WINDOWS\Microsoft.NET\Framework\<číslo verze>\.
Pozoruhodná situace může nastat, pokud explicitně nenastavíme encoding mailů odesílaných z ASP.NET aplikací (resp. obecně .NET aplikací).
Může se nám totiž stát, že aplikace, která na jednom serveru korektně odesílá maily, v pohodě s češtinou, po přesunu na server jiný (jinak nastavený), najednou posílá maily „napůl české“. Ono „napůl“ je na tom to nejzáludnější, zprávy totiž nechodí ve stylu rozsypaný čaj, jak to známe ze špatně nastaveného encodingu, nýbrž jsou ve zprávě odebrány háčky a čárky od většiny českých znaků (zůstává třeba á, í, é). Člověka tak hned nenapadne, v čem je problém a bádá někde mimo aplikaci.
…v mém konkrétním případě druhý server díky svému nastavení posílal zprávy v encodingu iso-8859-1 a sám (předpokládám CDO, ale nebádal jsem nad tím) si je upravoval na nejlépe čitelné.
Zásadně tedy vždy explicitně určovat encoding zpráv!!!
// v případě System.Web.Mail i System.Net.Mail
using (MailMessage mail = new MailMessage())
{
mail.BodyEncoding = Encoding.GetEncoding("iso-8859-2");
// System.Net.Mail.MailMessage má i SubjectEncoding
...
}
ASP.NET 2.0 má v sobě jednu novou málo známou pomůcku – možnost dočasného odstavení webové aplikace umístěním souboru App_offline.htm do rootu webové aplikace.
Pokud do rootu aplikace umístíme soubor App_offline.htm, webová aplikace se zastaví a dokonce se zruší její aplikační doména (AppDomain), takže se odpojí všechny otevřená spojení, databázové soubory, zruší user-instance SQL, atp.
Případný request dostane v odpovědi obsah App_offline.htm souboru. Můžeme si tak připravit nějaký rozumný soubor a pouhým přejmenováním na App_offline.htm web shazovat.
Funkčnost je zamýšlena pro krátkodobé odstavení webové aplikace za účelem jejího update a využívá jí například i Visual Studio při „Publish Web Site“.
Na CodeProject.com jsem pod názvem Simple encrypting and decrypting data in C# našel pěkný ukázkový kód na šifrování. Kód je připraven ve formě utils-třídy se statickými metodami Encrypt() a Decrypt() s několika overloady, je hezky komentován a demonstruje základní schéma pouužití šifrování.
//
// This sample code is provided "AS IS" with no warranties,
// and confers no rights.
//
// ATTENTION: This sample is designed to be more of a
// tutorial rather than something you can copy and paste in
// the production code!
//
using System;
using System.IO;
using System.Security.Cryptography;
//
// Sample encrypt/decrypt functions
// Parameter checks and error handling
// are ommited for better readability
//
public class EncDec
{
// Encrypt a byte array into a byte array using a key and an IV
public static byte[] Encrypt(byte[] clearData, byte[] Key, byte[] IV)
{
// Create a MemoryStream to accept the encrypted bytes
MemoryStream ms = new MemoryStream();
// Create a symmetric algorithm.
// We are going to use Rijndael because it is strong and
// available on all platforms.
// You can use other algorithms, to do so substitute the
// next line with something like
// TripleDES alg = TripleDES.Create();
Rijndael alg = Rijndael.Create();
// Now set the key and the IV.
// We need the IV (Initialization Vector) because
// the algorithm is operating in its default
// mode called CBC (Cipher Block Chaining).
// The IV is XORed with the first block (8 byte)
// of the data before it is encrypted, and then each
// encrypted block is XORed with the
// following block of plaintext.
// This is done to make encryption more secure.
// There is also a mode called ECB which does not need an IV,
// but it is much less secure.
alg.Key = Key;
alg.IV = IV;
// Create a CryptoStream through which we are going to be
// pumping our data.
// CryptoStreamMode.Write means that we are going to be
// writing data to the stream and the output will be written
// in the MemoryStream we have provided.
CryptoStream cs = new CryptoStream(ms,
alg.CreateEncryptor(), CryptoStreamMode.Write);
// Write the data and make it do the encryption
cs.Write(clearData, 0, clearData.Length);
// Close the crypto stream (or do FlushFinalBlock).
// This will tell it that we have done our encryption and
// there is no more data coming in,
// and it is now a good time to apply the padding and
// finalize the encryption process.
cs.Close();
// Now get the encrypted data from the MemoryStream.
// Some people make a mistake of using GetBuffer() here,
// which is not the right way.
byte[] encryptedData = ms.ToArray();
return encryptedData;
}
// Encrypt a string into a string using a password
// Uses Encrypt(byte[], byte[], byte[])
public static string Encrypt(string clearText, string Password)
{
// First we need to turn the input string into a byte array.
byte[] clearBytes =
System.Text.Encoding.Unicode.GetBytes(clearText);
// Then, we need to turn the password into Key and IV
// We are using salt to make it harder to guess our key
// using a dictionary attack -
// trying to guess a password by enumerating all possible words.
PasswordDeriveBytes pdb = new PasswordDeriveBytes(Password,
new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d,
0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});
// Now get the key/IV and do the encryption using the
// function that accepts byte arrays.
// Using PasswordDeriveBytes object we are first getting
// 32 bytes for the Key
// (the default Rijndael key length is 256bit = 32bytes)
// and then 16 bytes for the IV.
// IV should always be the block size, which is by default
// 16 bytes (128 bit) for Rijndael.
// If you are using DES/TripleDES/RC2 the block size is
// 8 bytes and so should be the IV size.
// You can also read KeySize/BlockSize properties off
// the algorithm to find out the sizes.
byte[] encryptedData = Encrypt(clearBytes,
pdb.GetBytes(32), pdb.GetBytes(16));
// Now we need to turn the resulting byte array into a string.
// A common mistake would be to use an Encoding class for that.
//It does not work because not all byte values can be
// represented by characters.
// We are going to be using Base64 encoding that is designed
//exactly for what we are trying to do.
return Convert.ToBase64String(encryptedData);
}
// Encrypt bytes into bytes using a password
// Uses Encrypt(byte[], byte[], byte[])
public static byte[] Encrypt(byte[] clearData, string Password)
{
// We need to turn the password into Key and IV.
// We are using salt to make it harder to guess our key
// using a dictionary attack -
// trying to guess a password by enumerating all possible words.
PasswordDeriveBytes pdb = new PasswordDeriveBytes(Password,
new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d,
0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});
// Now get the key/IV and do the encryption using the function
// that accepts byte arrays.
// Using PasswordDeriveBytes object we are first getting
// 32 bytes for the Key
// (the default Rijndael key length is 256bit = 32bytes)
// and then 16 bytes for the IV.
// IV should always be the block size, which is by default
// 16 bytes (128 bit) for Rijndael.
// If you are using DES/TripleDES/RC2 the block size is 8
// bytes and so should be the IV size.
// You can also read KeySize/BlockSize properties off the
// algorithm to find out the sizes.
return Encrypt(clearData, pdb.GetBytes(32), pdb.GetBytes(16));
}
// Encrypt a file into another file using a password
public static void Encrypt(string fileIn,
string fileOut, string Password)
{
// First we are going to open the file streams
FileStream fsIn = new FileStream(fileIn,
FileMode.Open, FileAccess.Read);
FileStream fsOut = new FileStream(fileOut,
FileMode.OpenOrCreate, FileAccess.Write);
// Then we are going to derive a Key and an IV from the
// Password and create an algorithm
PasswordDeriveBytes pdb = new PasswordDeriveBytes(Password,
new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d,
0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});
Rijndael alg = Rijndael.Create();
alg.Key = pdb.GetBytes(32);
alg.IV = pdb.GetBytes(16);
// Now create a crypto stream through which we are going
// to be pumping data.
// Our fileOut is going to be receiving the encrypted bytes.
CryptoStream cs = new CryptoStream(fsOut,
alg.CreateEncryptor(), CryptoStreamMode.Write);
// Now will will initialize a buffer and will be processing
// the input file in chunks.
// This is done to avoid reading the whole file (which can
// be huge) into memory.
int bufferLen = 4096;
byte[] buffer = new byte[bufferLen];
int bytesRead;
do {
// read a chunk of data from the input file
bytesRead = fsIn.Read(buffer, 0, bufferLen);
// encrypt it
cs.Write(buffer, 0, bytesRead);
} while(bytesRead != 0);
// close everything
// this will also close the unrelying fsOut stream
cs.Close();
fsIn.Close();
}
// Decrypt a byte array into a byte array using a key and an IV
public static byte[] Decrypt(byte[] cipherData,
byte[] Key, byte[] IV)
{
// Create a MemoryStream that is going to accept the
// decrypted bytes
MemoryStream ms = new MemoryStream();
// Create a symmetric algorithm.
// We are going to use Rijndael because it is strong and
// available on all platforms.
// You can use other algorithms, to do so substitute the next
// line with something like
// TripleDES alg = TripleDES.Create();
Rijndael alg = Rijndael.Create();
// Now set the key and the IV.
// We need the IV (Initialization Vector) because the algorithm
// is operating in its default
// mode called CBC (Cipher Block Chaining). The IV is XORed with
// the first block (8 byte)
// of the data after it is decrypted, and then each decrypted
// block is XORed with the previous
// cipher block. This is done to make encryption more secure.
// There is also a mode called ECB which does not need an IV,
// but it is much less secure.
alg.Key = Key;
alg.IV = IV;
// Create a CryptoStream through which we are going to be
// pumping our data.
// CryptoStreamMode.Write means that we are going to be
// writing data to the stream
// and the output will be written in the MemoryStream
// we have provided.
CryptoStream cs = new CryptoStream(ms,
alg.CreateDecryptor(), CryptoStreamMode.Write);
// Write the data and make it do the decryption
cs.Write(cipherData, 0, cipherData.Length);
// Close the crypto stream (or do FlushFinalBlock).
// This will tell it that we have done our decryption
// and there is no more data coming in,
// and it is now a good time to remove the padding
// and finalize the decryption process.
cs.Close();
// Now get the decrypted data from the MemoryStream.
// Some people make a mistake of using GetBuffer() here,
// which is not the right way.
byte[] decryptedData = ms.ToArray();
return decryptedData;
}
// Decrypt a string into a string using a password
// Uses Decrypt(byte[], byte[], byte[])
public static string Decrypt(string cipherText, string Password)
{
// First we need to turn the input string into a byte array.
// We presume that Base64 encoding was used
byte[] cipherBytes = Convert.FromBase64String(cipherText);
// Then, we need to turn the password into Key and IV
// We are using salt to make it harder to guess our key
// using a dictionary attack -
// trying to guess a password by enumerating all possible words.
PasswordDeriveBytes pdb = new PasswordDeriveBytes(Password,
new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65,
0x64, 0x76, 0x65, 0x64, 0x65, 0x76});
// Now get the key/IV and do the decryption using
// the function that accepts byte arrays.
// Using PasswordDeriveBytes object we are first
// getting 32 bytes for the Key
// (the default Rijndael key length is 256bit = 32bytes)
// and then 16 bytes for the IV.
// IV should always be the block size, which is by
// default 16 bytes (128 bit) for Rijndael.
// If you are using DES/TripleDES/RC2 the block size is
// 8 bytes and so should be the IV size.
// You can also read KeySize/BlockSize properties off
// the algorithm to find out the sizes.
byte[] decryptedData = Decrypt(cipherBytes,
pdb.GetBytes(32), pdb.GetBytes(16));
// Now we need to turn the resulting byte array into a string.
// A common mistake would be to use an Encoding class for that.
// It does not work
// because not all byte values can be represented by characters.
// We are going to be using Base64 encoding that is
// designed exactly for what we are trying to do.
return System.Text.Encoding.Unicode.GetString(decryptedData);
}
// Decrypt bytes into bytes using a password
// Uses Decrypt(byte[], byte[], byte[])
public static byte[] Decrypt(byte[] cipherData, string Password)
{
// We need to turn the password into Key and IV.
// We are using salt to make it harder to guess our key
// using a dictionary attack -
// trying to guess a password by enumerating all possible words.
PasswordDeriveBytes pdb = new PasswordDeriveBytes(Password,
new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d,
0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});
// Now get the key/IV and do the Decryption using the
//function that accepts byte arrays.
// Using PasswordDeriveBytes object we are first getting
// 32 bytes for the Key
// (the default Rijndael key length is 256bit = 32bytes)
// and then 16 bytes for the IV.
// IV should always be the block size, which is by default
// 16 bytes (128 bit) for Rijndael.
// If you are using DES/TripleDES/RC2 the block size is
// 8 bytes and so should be the IV size.
// You can also read KeySize/BlockSize properties off the
// algorithm to find out the sizes.
return Decrypt(cipherData, pdb.GetBytes(32), pdb.GetBytes(16));
}
// Decrypt a file into another file using a password
public static void Decrypt(string fileIn,
string fileOut, string Password)
{
// First we are going to open the file streams
FileStream fsIn = new FileStream(fileIn,
FileMode.Open, FileAccess.Read);
FileStream fsOut = new FileStream(fileOut,
FileMode.OpenOrCreate, FileAccess.Write);
// Then we are going to derive a Key and an IV from
// the Password and create an algorithm
PasswordDeriveBytes pdb = new PasswordDeriveBytes(Password,
new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d,
0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});
Rijndael alg = Rijndael.Create();
alg.Key = pdb.GetBytes(32);
alg.IV = pdb.GetBytes(16);
// Now create a crypto stream through which we are going
// to be pumping data.
// Our fileOut is going to be receiving the Decrypted bytes.
CryptoStream cs = new CryptoStream(fsOut,
alg.CreateDecryptor(), CryptoStreamMode.Write);
// Now will will initialize a buffer and will be
// processing the input file in chunks.
// This is done to avoid reading the whole file (which can be
// huge) into memory.
int bufferLen = 4096;
byte[] buffer = new byte[bufferLen];
int bytesRead;
do {
// read a chunk of data from the input file
bytesRead = fsIn.Read(buffer, 0, bufferLen);
// Decrypt it
cs.Write(buffer, 0, bytesRead);
} while(bytesRead != 0);
// close everything
cs.Close(); // this will also close the unrelying fsOut stream
fsIn.Close();
}
}
Pokud na straně klienta odešleme formulář klávesou ENTER, pak máme-li na stránce jediný submit-prvek (tlačítko) a k tomu jediný input-prvek (TextBox), pak díky chování mnohých prohlížečů (včetně Internet Exploreru), nedojde k vyvolání serverové události Click submit-prvku, nýbrž proběhne jen hluchý postback.
Ošálit to lze přidáním dalšího skrytého TextBoxu:
<asp:TextBox ID="EmailTB" Runat="server"/> <asp:TextBox ID="dummy" Style="display:none;" Runat="server"/> <asp:LinkButton ID="SubscribeLB" Text="Přihlásit" Runat="server"/>
Dejme tomu, že jsme v hostovaném prostředí a víme, že je na disku zhruba následující adresářová struktura:
<nevíme>/Zakaznik/
<nevíme>/Zakaznik/wwwroot/
<nevíme>/Zakaznik/data/
…a potřebujeme se z webové aplikace dostat na soubory ve složce ../data/.
Na problém narazíme, pokud bychom použili
Server.MapPath("../data/cosi.xyz");
Server.MapPath("/../data/cosi.xyz");
Server.MapPath("~/../data/cosi.xyz");
…dostaneme výjimku HttpException: Cannot use a leading .. to exit above the top directory.
Pomoc je snadná, pokud máme na cílové místo opravdu přístupová práva, pak stačí použít:
Path.Combine(Server.MapPath("/"), "../data/cosi.xyz")
…a jsme tam.
Když si v ASP.NET spustíme nový thread (vlákno), tak tento sice získá některé vlastnosti z původního threadu (např. culture), ale nemá přístup k HttpContext.Current, resp. je v něm null.
V každém případě musíme vědět, co děláme, protože druhé vlákno například nemůže moc manipulovat s Response, neboť není vůbec jisté, do jakého stavu Response uvedl thread první, např. už totiž mohl Response odeslat na klienta.
První možností je připravit hodnoty, které bude nový thread potřebovat, do uložiště, které je přístupné oboum threadům, klasicky třeba statické property nějaké třídy.
public static string RootUrl
{
get
{
if (rootUrl == null)
{
if (HttpContext.Current != null)
{
rootUrl = "http://" + HttpContext.Current.Request.Url.Host + HttpContext.Current.Request.ApplicationPath;
}
else
{
rootUrl = "http://nejaky/default/url";
}
}
return rootUrl;
}
}
private static string rootUrl;
Výše uvedený příklad statické property zahrnuje i určitou logiku. Rozhodující je však uložení výsledku prvního volání do statické privátní proměnné rootUrl. Pokud si tedy před spuštěním nového threadu zaručíme alespoň jedno čtení dané property, ta si inicializuje svojí hodnotu v prvním threadu a v druhém threadu už dá rovnou výsledek připravený v rootUrl (nebude HttpContext.Current potřebovat).
Teoreticky lze do statické property typu HttpContext cachovat celý HttpContext.Current, nepovažuji to však za příliš vhodné.
Druhou možností, která je vhodnější, pokud už potřebujeme předat do druhého threadu opravdu celý context, je zapouzdření druhého threadu do samostatné třídy:
public class MyClass
{
private HttpContext _context;
public MyClass(HttpContext context)
{
_context = context;
}
public void Start()
{
ThreadStart start = new ThreadStart(DoWork);
Thread.Start(start);
}
private void DoWork()
{
// tady můžem něco dělat z contextem,
// ale pozor, že request už může být odeslán na klienta
}
}
private void Page_Load(object sender, EventArgs e)
{
MyClass myClass = new MyClass(HttpContext.Current);
myClass.Start();
}
Pokud potřebujeme jen HttpContext.Current.Cache, tak je vše výše uvedené nesmysl, protože na cache máme přístupovat přes HttpRuntime.Cache, a to funguje i v novým threadu…
Datové typy ntext, text a image budou z budoucích verzích Microsoft SQL Serveru odstraněny. Doporučuje se tedy místo nich používat nové typy nvarchar(MAX), varchar(MAX) avarbinary(MAX).
Mnoho vývojářů tápe, kterou z metod Int32.Parse() a Convert.ToInt32() používat pro parsování textových vstupů na číslo. Rozdíl je malý, a sice v interpretaci vstupu null. Vše je jasné, pokud se podíváme na vnitřnosti Convert.ToInt32():
public static int ToInt32(string value)
{
if (value == null)
{
return 0;
}
return int.Parse(value, CultureInfo.CurrentCulture);
}
Metoda Convert.ToInt32() tedy na vstup null vrátí hodnotu 0, zatímco int.Parse() vyhodí výjimku ArgumentNullException.
Někdy se nám může hodit kompletní vyčištění webové application cache (datové cache přístupné přes HttpRuntime.Cache, Control.Cache, HttpContext.Current.Cache, …), například po změně cachovaných hodnot „read-only“ číselníků.
.NET Framework pro takovou operaci žádnou přímou pomůcku nemá, nebo o ní alespoň nevím. Jde to však obejít poměrně snadno. Třída Cache totíž implementuje rozhraní IEnumerable a metoda GetEnumerator() vrací IDictionaryEnumerator. Stačí tedy po jedné vyházet všechny položky:
foreach (DictionaryEntry de in Cache)
{
Cache.Remove(de.Key.ToString());
}
Implementováno v Havit.Web.HttpServerUtilityExt.ClearCache().
HAVIT Knowledge Base 