Category Archives: Development

Na lokále mi .NET aplikace chodí, ale při spouštění ze síťové cesty padá na SecurityException

Problém, který poprvé zaskočí snad každého .NET programátora. Ani já nebyl kdysi výjimkou a tuto otázku dostávám stále dokola.

Symptom je jednoduchý – při spouštění .NET aplikace z lokálního počítače vše krásně funguje, při spouštění přes síť (např. po deploymentu do sdílené složky) aplikace padá na SecurityException.

Jádrem celého problému je .NETí mechanizmus Code Access Security Policy, který má mj. chránit hostující počítač před neoprávněným spouštěním kódu, popř. před závadným kódem. Stručně řečeno tento mechanizmus používá pro řízení práv k provádění jednotlivých operací sadu faktů zvanou Evidence (důkazy), přičemž jeden z podstatných faktů je zóna, z které je kód spouštěn (jde o klasické zóny Můj počítač, Lokální intranet, Internet, Důveryhodné servery, …). No a výchozí nastavení na hostujícím počítači po instalací .NET frameworku říká, že kód spouštěný ze zón Intranet/Internet má určitá omezení, např. nesmí přistupovat k souborovému systému, či nesmí pracovat se sítí (SQL serverem), atp.

V podstatě jsou dvě cesty k řešení:

  1. Rozšířit sadu Evidence aplikace tak, aby ve výchozím nastavení .NET frameworku měla aplikace práva lepší. Základem je např. podepsat aplikaci (strong-name), atp.
  2. Změnit výchozí nastavení zabezpečení .NET frameworku na hostujícím počítači tak, aby i aplikace z méně bezpečných zón směly provádět zabezpečené operace. Což provedeme:
    1. Spustíme MMC konzoli pro konfiguraci .NET Frameworku (z Nástrojů pro správu, popř. z Run mmc.exe a pak Přidat modul snap-in…)
    2. Donavigujeme se ve stromu na My Computer ~ Runtime Security Policty
    3. dáme Adjust Zone Security
    4. Make changes to this computer / to the current user only (dle potřeby)
    5. Vybereme zónu a šoupátkem zvýšíme její „trust“. Full Trust znamená „bez omezení“.

Pozor, neměňte bezhlavě tato nastavení. Týkají se totiž i kódu spouštěného z internetu, např. i přímo z webových stránek. Můžete tak nechtěně otevřít bránu do svého počítače i pro nežádoucí kód.

Správná cesta k řešení vede přes bod 1), nicméně připouštím, že pro začínajícího programátora a jednoduché síťové utilitky je to cesta složitější.

VasekB doplnil

lze to povolit i takto:

%SystemRoot%\Microsoft.NET\Framework\v1.1.4322\caspol.exe -q -f -cg 1.2 FullTrust

nastaveni se ulozi tady:

%SystemRoot%\Microsoft.NET\Framework\v1.1.4322\CONFIG\security.config

Jak podepsat tu aplikaci?

Musíte si nejprve vytvořit podpisový klíč, obvykle pomocí utility SN, spusťte „sn -k my.key“. Potom tento klíč připojíte ke své assembly pomocí atributu [assembly: AssemblyKeyFile(„C:\Path\my.key“)].  Obvykle se tyto atributy zapisují do souboru AssemblyInfo.cs, který lze navíc editovat pomocí UI VisualStudia (vlastnosti projektu).

Detekce ztráty ViewState při použití SessionPageStatePersisteru

Pokud směřujete ViewState do Session pomocí SessionPageStatePersisteru, pak se dříve nebo později setkáte s problémem ztrát ViewState a s potřebou detekovat a řešit tuto situaci.

Ke ztrátě ViewState může dojít v následujících případech:

  • v případě zániku/vyčištění Session, zejména při jejím timeoutování při nečinosti uživatele – uživatel si například nechá dlouho otevřenou stránku, vyprší mu mezi tím session, následně provede postback a problém je na světě, došlý postback nemá na serveru už ViewState,
  • v případě ztráty InProc Session díky restartování aplikace (deployment nové verze, recyklace poolu, atp.)
  • v případě vypadnutí stránky z fronty SessionPageStatePersisteru – persister omezuje totiž počet uložených ViewState a při uložení dalšího nejstarší vypadávají. Výchozí délka fronty je 9, je možné ji přenastavit na větší ve web.configu elementem sessionPageState, atributem historySize
    • pokud si například uživatel otevře současně 10 oken aplikace, pak pokud se vrátí k prvnímu oknu a provede postback, opět chybí ViewState,
    • pokud uživatel používá tlačítko Zpět browseru, např. pokud máme na stránce grid a každý řádek má na sobě tlačítko Detail, jehož obsluha události dělá redirect na stránku s detaily. Takový uživatel pokud klikne na detail prvního řádku, pak Zpět, druhého řádku, Zpět, … kliknutím na detail desátého řádku už způsobený postback na serveru nemá svůj ViewState (devět ViewState detailů vytlačilo z fronty ViewState stránky s gridem) a problém je zase na světě.

Jak takovou situaci detekovat? …overridováním metody LoadPageStateFromPersistenceMedium() v našich stránkách (obvykle pomocí společného předka všech stránek, nějakého PageBase):

protected override object LoadPageStateFromPersistenceMedium()
{
    // base implementace vrací new Pair(pageStatePersister.ControlState, pageStatePersister.ViewState);
    object pageState = base.LoadPageStateFromPersistenceMedium();

    // ztrátu ViewState můžeme tedy detekovat jako (pair.Second == null)
    // metoda LoadPageStateFromPersistenceMedium se volá jen pro IsPostBack
    Pair pair = pageState as Pair;
    if ((pair != null) && (pair.Second == null))
    {
        Trace.Warn("ViewStateLost !!!");

        FormsAuthentication.RedirectToLoginPage();
    }

    return pageState;
}

Základní (base) implementace metody LoadPageStateFromPersistenceMedium() totiž nedělá celkem nic jiného, než že z použitého persisteru získá ControlState, ViewState a udělá z nich Pair.

Situaci můžeme řešit například tím, že uživatele požádáme o nové přihlášení, či provedeme redirect kamsi do rootu nebo sami na sebe. ViewState už nikde nevydolujeme, musíme z toho nějak vybruslit, aniž bychom uživatele obšťastnili výjimkou NullReferenceException, InvalidFormatException a jinými podobnými, které v takových situacích nastávají.

Pozor na Response.Redirect(), Response.End() a obsluhu výjimek

Jak myslíte, že dopadne následující příklad po kliknutí na tlačítko? (Stránka obsahuje jen label MyLabel a button MyButton)

public partial class _Default : System.Web.UI.Page 
{
    protected override void OnLoad(EventArgs e)
    {
        base.OnLoad(e);

        MyLabel.Text = (string)Session["OK"];
    }

    void MyButton_Click(object sender, EventArgs e)
    {
        try
        {
            Session["OK"] = "ok";
            Response.Redirect("~/");
        }
        catch
        {
            Session["OK"] = "exception";
        }
    }
}

Mnohé z Vás asi překvapím, když řeknu, že do Session[„OK“] se uloží „exception“ a ten se v dalším requestu i zobrazí.

Response.Redirect(), resp. metoda Response.End(), kterou Redirect sám volá, totiž funguje tak, že vyvolá ve webové aplikaci interní výjimku (Thread.CurrentThread.Abort()), která je samotnou webovou aplikací zpracovávána tak, aby bylo dosaženo kýženého efektu, tj. aby se vykonávání kódu zastavilo v daném místě a další kód se nevykonal (resp. tato ThreadAbortException se na konci catch-bloků vyvolává znovu a jsou vykonány všechny příslušné catch/finally bloky a tedy např. i Page.OnUnload()).

Potíž však nastane v okamžiku, kdy sami obalíme volání Response.Redirect() či Response.End() zachytáváním výjimek a nespecifikujeme dostatečně typ výjimek, které chceme zachytávat. Pokud necháme chytat výjimky všechny, uvedeme jako typ Exception, pak se dočkáme nežádoucího efektu, kdy nám volání Response.Redirect()/End() způsobí vykonání obsluhy výjimky, blok catch.

Východiskem je tedy obsluhovat pouze specifické typy výjimek, tak, jak to ostatně obecné guidelines doporučují pro všechny situace.

Přenastavení počítadla pro identity sloupec (Identity Seed, RESEED)

Přenastavení počítadla pro identity sloupec na 1:

DBCC CHECKIDENT (MyTable, RESEED, 1)

Počítadlo vyresetuje na výchozí hodnotu i TRUNCATE TABLE, který slouží pro vymazání celé tabulky.

Více o DBCC CHECKIDENT [MSDN].

Roman Krejčí update:

1) syntaxe příkazu v dokumentaci je přesně

DBCC CHECKIDENT ('MyTable', RESEED, new_reseed_value)

to jest nazev tabulky by měl být v uvozovkách. Uvozovky jsou však vyžadovány jen pokud je název tabuky „multipart“, to jest je tvaru katalog.dbo.table_name. Pokud je název uveden jako single-part (bez kvalifikace katalogem a vlastníkem), lze uvozovky vynechat (ale lze je i nevynechat).

2) Hodnota new_reseed_value se použije takto – pokud od vytvoření tabulky do provedení příkazu DBCC do ní nebyl vložen žádný záznam, bude mít první vložený záznam v IDENTITY sloupci hodnotu přímo new_reseed_value. Pokud tabulka už nějaké záznamy obsahuje, bude IDENTITY sloupec v dalším přidaném záznamu obsahovat hodnotu (new_reseed_value + identity_increment), kde identity_increment je inkrement počítadla zadaný při vytvoření tabulky (lze zjistit jako select IDENT_INCR(TABLE_NAME))

Visual Studio Gallery – katalog doplňků pro VS

Microsoft připravil nový web, Visual Studio Gallery (http://visualstudiogallery.com), který má být katalogem všech možných doplňků pro Visual Studio, extenzí, add-inů, maker a podobných vylepšení. Zaregistrovat se můžete i se svými doplňky.

Znali jste například následující zajímavé bezplatné nástroje?

JavaScript: Metoda parseInt vrací nečekané výsledky

Metoda parseInt vrací celočíselnou hodnotu získanou z řetězce. Metoda toho umí ve skutečnosti více, než je od ní očekáváno – pokud řetězec začíná „0x“, považuje se řetězec za zápis čísla v šestnáckové soustavě, pokud začíná nulou, pak za zápis čísla v osmičkové soustavě. Druhým (nepovinným) parametrem můžeme metodě říct, v jaké číselné soustavě je hodnota uvedena. Pokud metoda při zpracování řetězce narazí na nepodporovaný symbol (znak), končí zpracování (což je v dokumentaci popsáno uvedeno jen v příkladu).

parseInt('abc')             // vrací NaN
parseInt('8abc')           // vrací 8 - zpracování skončí u nepodporovaného symbolu "a"
parseInt('0100')      // vrací 64 - nula na začátku říká, že jde o osmičkovou soustavu, v osmičkové soustavě je "100" reprezentací hodnoty 64
parseInt('08')               // vrací 0 - nula na začátku říká, že jde o osmičkovou soustavu, ta ale nepoužívá symbol 8, na kterém proto skončí zpracování
parseInt('08', 10)       // vrací 8 - uvedli jsme, že hodnota reprezentuje číslo v desítkové soustavě nepodporovanou mezerou
parseInt('1 000', 10) // vrací 1 - zpracování skončí

Pozor proto na zpracování hodnot od uživatele. Pokud není jasné, jak uživatel hodnotu zadá (a to podle mě není jasné nikdy), je potřeba předat metodě parseInt i druhý parameter, jinak se dočkáte stejného překvapení jako já při zpracování času zadaného uživatelem: Vstup „07“ vrátí 7, vstup „08“ vrátí 0.
Pozor i na situaci, kdy uživatel zadá formátované číslo – například s oddělovačem tisíců. A takový javascript nemusíme ani psát ručně, stačí použít některý z validátorů (ASP.NET), který používá parseInt.

IE: Při použití auto-complete se nevyvolá událost onChange

Internet Explorer při použití auto-complete nevyvolá na daném prvku (inputu) událost onChange, bug (i když někteří by možná řekli by-design).

Mimo obskurnějších řešení se dá auto-complete na daném prvku prostě vypnout:

<input ... autocomplete="off" />
<asp:TextBox ... autocomplete="off" />

Případně ho vypnout na celém formuláři:

<form ... autocomplete="off">

…nefunguje bohužel možnost na celém formuláři vypnout a uvnitř na některých prvcích zapnout.

Jednoduchý exception logging pomocí Trace/TraceSource mechanizmů .NET

Pokud se sháníte po jednoduchém mechanizmu, jak ve Vašich aplikacích logovat výjimky, pak zřejmě v .NET pro consolové/WinForm aplikace marně hledáte něco, jako je healthMonitoring pro ASP.NET, kde je připraven jednoduchý, ale mocný nástroj a lze pomocí pouhých několika řádků ve web.config souboru získat přehled o výjimkách ve Vaší aplikaci, např.:

<configuration>
    <system.web>
        <healthMonitoring enabled="true">
            <rules>
                <add name="Mail Notifications on All Errors" eventName="All Errors" provider="SimpleMailWebEventProvider" profile="Default"/>
            </rules>
            <providers>
                <add name="SimpleMailWebEventProvider" type="System.Web.Management.SimpleMailWebEventProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" from="errors@havit.cz" to="errors@example.cz" subjectPrefix="MyApplication: " buffer="true" bufferMode="Notification" maxEventLength="4096" maxMessagesPerNotification="2"/>
            </providers>
        </healthMonitoring>
    </system.web>
</configuration>

…výše uvedená konfigurace Vám zajistí zasílání mailových notifikacích o neobsloužených výjimkách a chyách Vaší aplikace, jednoduché, prosté.

Jak na to u consolových a WinForm aplikací?

Pro consolové či WinForm aplikace nic jako healthMonitoring připraveno není, nicméně s pár řádky kódu lze dosáhnout obdobného efektu a dokonce u toho využít široké možnosti pro tracing v .NET 2.0. Základní myšlenka je prostá:

  • .NET 2.0+ v sobě obsahuje široké možnosti pro tracing, kdy můžeme definovat různé zdroje zpráv (TraceSource), zprávy různé rozdělovat (Switch), filtrovat (TraceFilter) a směrovat na různé listenery (výstup do konzole, XML, textového souboru, event-logu, SQL, SMTP, atd. další si můžeme napsat) – to vše bez nutnosti jakýchkoliv doplňků – ať už Microsoftích Enterprise Library / Application Blocků, či produktů třetích stran typu Log4Net. Základní přehled o možnostech si můžeme udělat například z článku A Tracing Primer – Part I [Mike Rousos].
  • .NET sám nemá mechanizmus, jak výjimky zapisovat do trace
  • napsat pár řádků kódu, které zajistí zápis výjimek do trace je snadné!!!
  • do trace můžeme buď výjimky posílat explicitně (níže volání ExceptionTracer.TraceException(myException)),
  • nebo se můžeme přihlásit k odběru událostí, které neošetřené výjimky způsobují,
    • obecně jde o událost AppDomain.CurrentDomain.UnhandledException
    • ve WinForm aplikacích pak událost Application.ThreadException

Interface pro nasazení?  …prostý

V nejjednodušší variantě si můžeme udělat například třídu ExceptionTracer, kterou přihlásíme k odběru příslušných událostí a v obsluze událostí už budeme jen výjimku posílat do trace.

Pro konzolové aplikace:

class Program
{
    static void Main(string[] args)
    {
        ExceptionTracer.SubscribeToUnhandledExceptions();

        throw new InvalidOperationException("Chybka!");

        // ExceptionTracer.Default.TraceException(new ArgumentNullException("param", "Sakrapísek!"));
    }
}

Pro WinFormAplikace:

static class Program
{
    [STAThread]
    static void Main()
    {
        ExceptionTracer.SubscribeToWindowsFormsThreadExceptions();

        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new Form1());
    }
}

App.config pak může vypadat nějak takto:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.diagnostics>
        <sources>
            <source name="Exceptions" switchValue="Error">
                <listeners>
                    <add name="LogFileListener"
                        type="System.Diagnostics.TextWriterTraceListener"
                         initializeData="Exceptions.log"
                    />
                    <add name="XmlListener"
                         initializeData="Exceptions.xml"
                         type="System.Diagnostics.XmlWriterTraceListener"
                    />
                </listeners>
            </source>
        </sources>
    </system.diagnostics>
</configuration>

ExceptionTracer [Simplified Version]

Jednoduchá, ale plně funkční verze ExceptionTracekru může vypadat třeba takto:

 

using System;
using System.Collections.Generic;
using System.Text;
using System.Diagnostics;
using System.Windows.Forms;

namespace Havit.Diagnostics
{
    public class ExceptionTracer
    {
        /// <summary>
        /// Přihlásí ExceptionTracer k odběru všech neobsloužených výjimek (event AppDomain.CurrentDomain.UnhandledException).
        /// </summary>
        public static void SubscribeToUnhandledExceptions()
        {
            AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
        }
        private static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            if (e.ExceptionObject is Exception)
            {
                TraceException((Exception)e.ExceptionObject);
            }
        }

        /// <summary>
        /// Přihlásí ExceptionTracer k odběru všech neobsloužených výjimek WinForm (event Application.ThreadException).
        /// </summary>
        public static void SubscribeToWindowsFormsThreadExceptions()
        {
            Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
        }
        private static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
        {
            TraceException(e.Exception);

            // původní implementace obsluhy výjimky, WinForm dialog s chybou
            using (ThreadExceptionDialog excptDlg = new ThreadExceptionDialog(e.Exception))
            {
                DialogResult result = excptDlg.ShowDialog();
                if (result == DialogResult.Abort)
                {
                    Application.Exit();
                }
            }
        }

        /// <summary>
        /// Pošle do trace zadanou výjimku.
        /// </summary>
        /// <param name="exception">výjimka k zaznamenání</param>
        public static void TraceException(Exception exception)
        {
            TraceSource ts = new TraceSource("Exceptions");

            ts.TraceEvent(TraceEventType.Critical, 0, exception.ToString());

            ts.Flush();
            ts.Close();
        }
    }
}

Příklad výstupu [XML]

<E2ETraceEvent xmlns="http://schemas.microsoft.com/2004/06/E2ETraceEvent">
<System xmlns="http://schemas.microsoft.com/2004/06/windows/eventlog/system">
  <EventID>0</EventID> 
  <Type>3</Type> 
  <SubType Name="Critical">0</SubType> 
  <Level>1</Level> 
  <TimeCreated SystemTime="2008-01-31T21:08:35.0625000Z" /> 
  <Source Name="Exceptions" /> 
  <Correlation ActivityID="{00000000-0000-0000-0000-000000000000}" /> 
  <Execution ProcessName="WindowsFormsApplication1" ProcessID="1232" ThreadID="1" /> 
  <Channel /> 
  <Computer>OSKAR</Computer> 
</System>
<ApplicationData>System.ApplicationException: Test !!! at WindowsFormsApplication1.Form1.button1_Click(Object sender, EventArgs e) in D:\Development\ExceptionLogging\WindowsFormsApplication1\Form1.cs:line 20 at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)</ApplicationData> 
</E2ETraceEvent>

Použití C# 3.0 pro runtime .NET Framework 2.0

Pokud vyvíjíte aplikaci ve Visual Studiu 2008 a aplikace je určena pro runtime .NET Framework 2.0, nic vám nebrání použít nové charakteristiky jazyka C# 3.0. Úžasné je, že pro to nemusíte udělat vůbec nic.
Není možné pochopitelně použít ty rysy jazyka, které vyžadují knihovny instalované .NET Frameworkem 3.5. Můžete využít například eleganci lambda výrazů nebo zkráceného zápisu vlastností, zapomeňte ale na LINQ.

Jak přepsat PageStatePersister

 

Jak již bylo napsáno v jiném našem článku, vlastnost PageStatePersister slouží k získání objektu, který zajišťuje uložení ViewState. Článek detailně popisuje použití třídy SessionPageStatePersister, která zajišťuje uložení ViewState do Session.

Chybná implementace

Pokud chceme použít SessionPageStatePersister bez konfigurace pomocí adaptéru, musíme přepsat zmíněnou vlastnost, ideálně ve společném předkovi všech stránek v aplikaci. Nejjednodušší (avšak nesprávná implementace) může při každém dotazu na hodnotu vlastnosti vyrobit instanci persisteru a tu vrátit.

protected override PageStatePersister PageStatePersister
{
    get
    {
        // takto ne!
        new SessionPageStatePersister(this.Page);
    }
}
Symptomy

Dosáhneme sice požadovaného efektu – ViewState se ukládá do Session, ovšem v dříve funkčních částech aplikace začneme pozorovat nečekané efekty:

  1. Mezi postbacky se nezachovávají některé hodnoty ukládané do control state (například DataKeys u GridView).
  2. V některých velmi specifických případech se neprovede nastavení hodnoty do vlastnosti, pokud tato vlastnost již měla hodnotu nastavenou v souboru ASPX a hodnota vlastnosti se vnitřně ukládala do ViewState (po provedení příkazMujControl.Vlastnost = novaHodnota nebude hodnota vlastnosti změněna).
Správná implementace

Ačkoliv se to nedočteme v dokumentaci, ale zjistíme po bližším zkoumání .NET reflektorem, musíme v jedné instanci třídy Page vracet stále stejnou instanci, protože na hodnotu vlastnosti se opakovaně dotazují metody třídy Page (jednou z nich je metoda RegisterRequiresControlState, což by vysvětlovalo symptomy v bodu 1). Po zapracování tohoto poznatku jsme se zmíněných problémů zbavili. Správně je tedy třeba vlastnost PageStatePersister přepsat takto:

protected override PageStatePersister PageStatePersister
{
    get
    {
        if (_pageStatePersister == null)
        {
            _pageStatePersister = new SessionPageStatePersister(this.Page);
        }
        return _pageStatePersister;
    }
}
private PageStatePersister _pageStatePersister;