ASP.NET 4 a C# 2010 - tvorba dynamických stránek profesionálně - KNIHA 2

E N C Y K L O P E D I E Z O N E R P R E S S

TVORBA DYNAMICKÝCH STRÁNEK PROFESIONÁLNTVORBA DYNAMICKÝCH STRÁNEK PROFESIONÁLN

KNIHA 2

KNIHA

2

TVOR

BA DYN

AMICKÝ

CH STR

ÁNEK PROFESION

ÁLN

ASP.NET 4 ASP.NET 4 a C# 2010a C# 2010

ASP.NET 4 a C# 2010

M a t t h e w M a c D o n a l d M a t t h e w M a c D o n a l d A d a m F r e e m a n A d a m F r e e m a n

M a r i o S z p u s z t aM a r i o S z p u s z t a

KNIHA 2

KNIHAKNIHA

Matthew MacDonald, Adam Freeman, Mario Szpuszta

ASP.NET 4 a C# 2010tvorba dynamických stránek

profesionálně, kniha 2

Pro ASP.NET in C# 2010, Fourth EditionMatthew MacDonald, Adam Freeman a Mario Szpuszta

Original edition copyright © 2010 by Matthew MacDonald, Adam Freeman, and Mario Szpuszta. Czech edition copyright © 2011 by ZONER software, a.s. All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright the publisher.

Copyright originálního vydání © 2010 Matthew MacDonald, Adam Freeman a Mario Szpuszta. Copyright českého vydání © 2011 ZONER software, a.s.. Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována nebo předávána žádnou formou nebo způsobem, elektronicky ani mechanicky, včetně fotokopií, natáčení ani žádnými jinými systémy pro ukládání bez výslovného svolení držitele autorských práv.

ASP.NET 4 a C# 2010 – tvorba dynamických stránek profesionálně, kniha 2Autor: Matthew MacDonald, Adam Freeman, Mario Szpuszta

Copyright © ZONER software, a.s. Vydání první v roce 2011. Všechna práva vyhrazena.

Zoner PressKatalogové číslo: ZR1004

ZONER software, a.s.Nové sady 18, 602 00 Brno

Překlad: RNDr. Jan PokornýOdpovědný redaktor: Miroslav KučeraŠéfredaktor: Ing. Pavel KristiánDTP: Dan Zůda, obálka: Lenka Křížová

Zdrojové soubory ke knize: http://zonerpress.cz/download/aspnet4-a-c2010.zip

Bonusové kapitoly:http://www.zonerpress.cz/download/bonusove-kapitoly-aspnet.zip

Informace, které jsou v této knize zveřejněny, mohou byt chráněny jako patent. Jména produktů byla uvedena bez záruky jejich volného použití. Při tvorbě textů a vyobrazení bylo sice postupováno s maximální péčí, ale přesto nelze zcela vyloučit možnost výskytu chyb. Vydavatelé a autoři nepřebírají právní odpovědnost ani žádnou jinou záruku za použití chybných údajů a z toho vyplývajících důsledků. Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována ani dis-tribuována žádným způsobem ani prostředkem, ani reprodukována v databázi či na jiném záznamovém prostředku či v jiném systému bez výslovného svolení vydavatele, s výjimkou zveřejnění krátkých částí textu pro potřeby recenzí.

Veškeré dotazy týkající se distribuce směřujte na:

Zoner Press ZONER soft ware, a.s Nové sady 18, 602 00 Brno

tel.: 532 190 883 e-mail: [email protected] www.zonerpress.cz

ISBN 978-80-7413-145-5

3

Stručný obsah

Část IV – Bezpečnost 21

Kapitola 19 Bezpečnostní model ASP.NET 23

Kapitola 20 Ověřování založené na formulářích 37

Kapitola 21 Členství 63

Kapitola 22 Ověřování systému Windows 115

Kapitola 23 Autorizace a role 143

Kapitola 24 Profi ly 173

Kapitola 25 Kryptografi e 207

Kapitola 26 Vlastní zprostředkovatelé členství 239

Část V – Pokročilé uživatelské rozhraní 277

Kapitola 27 Vlastní serverové ovládací prvky 279

Kapitola 28 Grafi ky, GDI+ a grafy 313

Kapitola 29 JavaScript a techniky Ajax 355

Kapitola 30 ASP.NET AJAX 413

Kapitola 31 Portály s webovými částmi 479

Část VI – Nové směry 539

Kapitola 32 MVC 541

Kapitola 33 Dynamická data 579

Kapitola 34 Silverlight 617

5

Obsah O autorech 15

O odborných korektorech 15

Úvod 16

Rozdělení knihy 16

Komu je tato kniha určena? 18

Co potřebujete, abyste mohli pracovat s touto knihou? 18

Sdělte nám svůj názor 18

Zdrojové kódy 19

Bonusové kapitoly 19

Část IV – Bezpečnost 21

Kapitola 19 Bezpečnostní model ASP.NET 23

Tvorba bezpečného softwaru 23

Potenciální hrozby 24

Zásady bezpečného programování 24

Strážní 25

Úrovně bezpečnosti 26

Ověřování 27

Autorizace 28

Důvěrnost a integrita 29

Jak všechno spojit dohromady 29

Jak na SSL? 31

Certifi káty 31

Co je SSL 32

Konfi gurace SSL na IIS 7.x 33

Shrnutí 36

Kapitola 20 Ověřování založené na formulářích 37

Úvod do ověřování s formuláři 37

Proč používat ověřování založené na formulářích? 38

Proč nepoužívat ověřování založené na formulářích? 40

Proč neimplementovat vlastní ověřování s cookie? 41

Třídy ověřování založeného na formulářích 42

6

Implementace ověřování založeného na formulářích 43

Konfi gurace ověřování založeného na formulářích 44

Odmítnutí přístupu anonymním uživatelům 47

Tvorba vlastní přihlašovací stránky 48

Vlastní úložiště přihlašovacích dokladů 54

Trvalé cookie při ověřování založeném na formulářích 55

IIS 7.x a ověřování založené na formulářích 57

Shrnutí 62

Kapitola 21 Členství 63

Úvod do API členství ASP.NET 63

Práce s API členství 66

Konfi gurace ověřování založeného na formulářích 67

Vytvoření úložiště dat 68

Konfi gurace připojovacího řetězce a zprostředkovatele členství 74

Vytváření a ověřování uživatelů 77

Práce s ovládacími prvky pro bezpečnost 79

Ovládací prvek Login 81

Ovládací prvek LoginStatus 92

Ovládací prvek LoginView 93

Ovládací prvek PasswordRecovery 94

Ovládací prvek ChangePassword 98

Ovládací prvek CreateUserWizard 99

Konfi gurace členství v IIS 7.x 104

Konfi gurace zprostředkovatelů a uživatelů 104

Použití API členství s jinými aplikacemi 106

Použití třídy Membership 108

Získávání uživatelů z úložiště 109

Aktualizace uživatelů v úložišti 112

Vytváření a odstraňování uživatelů 112

Ověřování uživatelů 113

Shrnutí 114

Kapitola 22 Ověřování systému Windows 115

Úvod do ověřování systému Windows 115

7

Proč používat ověřování systému Windows? 115

Proč nepoužívat ověřování systému Windows? 117

Mechanismy ověřování systému Windows 117

Implementace ověřování systému Windows 123

Konfi gurace IIS 7.x 124

Konfi gurace ASP.NET 125

Podrobněji o zpracovatelském kanálu IIS 7.x 125

Odepření přístupu anonymním uživatelům 129

Přístup k informacím o uživateli Windows 130

Zosobnění 136

Zosobnění a delegování ve Windows 136

Konfi gurované zosobnění 138

Programátorské zosobnění 138

Shrnutí 142

Kapitola 23 Autorizace a role 143

Autorizace URL 143

Autorizační pravidla 144

Souborová autorizace 150

Autorizační kontroly v kódu 151

Metoda IsInRole() 151

Třída PrincipalPermission 152

Autorizace založená na rolích s API rolí 154

Použití ovládacího prvku LoginView s rolemi 160

Programátorský přístup rolím 161

API rolí s ověřováním systému Windows 164

Autorizace a role v IIS 7.x 166

Autorizace s ASP.NET Roles v IIS 7.x 168

Správa ASP.NET Roles s IIS 7.x 171

Shrnutí 172

Kapitola 24 Profi ly 173

Co je profi l 173

Představení profi lů 174

Jak profi ly ukládají data 175

8

Profi ly a ověřování 176

Profi ly versus vlastní datové komponenty 176

Zprostředkovatel SqlProfi leProvider 177

Vytvoření tabulek pro profi ly 177

Konfi gurace zprostředkovatele 179

Defi nování vlastností profi lu 180

Použití vlastností profi lu 181

Serializace profi lu 183

Skupiny profi lu 185

Profi ly a vlastní datové typy 186

API pro profi ly 189

Anonymní profi ly 192

Vlastní zprostředkovatelé profi lu 195

Třídy vlastního zprostředkovatele profi lu 195

Návrh zprostředkovatele FactoredProfi leProvider 197

Naprogramování FactoredProfi leProvider 198

Testování FactoredProfi leProvider 203

Shrnutí 206

Kapitola 25 Kryptografi e 207

Šifrování dat: diskrétnost 207

Jmenný prostor .NET pro kryptografi i 208

Úvod do kryptografi ckých tříd .NET 212

Symetrické šifrovací algoritmy 213

Asymetrické šifrování 214

Abstraktní šifrovací třídy 215

Rozhraní ICryptoTransform 215

Třída CryptoStream 216

Šifrování citlivých dat 217

Správa tajných údajů 217

Používání symetrických algoritmů 219

Používání asymetrických algoritmů 224

Šifrování citlivých dat v databázi 227

Šifrování dotazovacího řetězce 232

Obalení dotazovacího řetězce 232

Vytvoření testovací stránky 235

Shrnutí 237

9

Kapitola 26 Vlastní zprostředkovatelé členství 239

Architektura vlastních zprostředkovatelů 239

Základní kroky při vytváření vlastních zprostředkovatelů 241

Návrh vlastního zprostředkovatele v obecných rysech 241

Návrh a implementace vlastního úložiště 242

Implementace tříd zprostředkovatele 250

Používání tříd vlastních zprostředkovatelů 272

Shrnutí 276

Část V – Pokročilé uživatelské rozhraní 277

Kapitola 27 Vlastní serverové ovládací prvky 279

Základy vlastního serverového ovládacího prvku 279

Vytvoření kostry vlastního ovládacího prvku 280

Použití vlastního ovládacího prvku 282

Vlastní ovládací prvky v Toolboxu 283

Webový ovládací prvek podporující vlastnosti stylu 286

Proces realizace (generování HTML) 289

Práce s různými prohlížeči 291

HtmlTextWriter 291

Detekce prohlížeče 292

Vlastnosti prohlížeče 293

Překrývání detekce typu prohlížeče 295

Adaptivní realizace 295

Stav ovládacího prvku a události 297

Stav zobrazení 297

Stav ovládacího prvku 299

Data odesílaná na server a události změn 301

Jak se spustí odeslání na server 304

Rozšiřování existujících webových ovládacích prvků 306

Složené ovládací prvky 306

Odvozené ovládací prvky 309

Shrnutí 312

Kapitola 28 Grafi ky, GDI+ a grafy 313

Ovládací prvek ImageMap 313

10

Vytváření aktivních oblastí 314

Ošetření kliknutí do aktivních oblastí 315

Vlastní aktivní oblast 317

Kreslení s GDI+ 319

Jednoduché kreslení 319

Formát a kvalita obrázku 321

Třída Graphics 322

Práce s třídou GraphicsPath 325

Pera 327

Štětce 329

Vkládání dynamické grafi ky do webové stránky 331

Použití formátu PNG 332

Předávání informací dynamickým obrázkům 333

Vlastní ovládací prvky používající GDI+ 335

Ovládací prvek Chart 340

Vytvoření základního grafu 340

Plnění grafu daty 346

Shrnutí 354

Kapitola 29 JavaScript a techniky Ajax 355

Základy JavaScriptu 356

HTML DOM (Document Object Model) 356

Události na straně klienta 357

Bloky skriptu 360

Manipulace s prvky HTML 361

Ladění JavaScriptu 362

Základní příklady JavaScriptu 365

Vytvoření stránkového procesoru v JavaScriptu 365

Asynchronní stahování obrázků pomocí JavaScriptu 368

Realizace bloků skriptu 373

Útoky injektáží skriptu 375

Validace požadavku 375

Vypnutí validace požadavku 376

Rozšíření validace požadavku 378

Vlastní ovládací prvky s JavaScriptem 380

Automaticky otevíraná okna 381

Překlápěcí tlačítka 385

11

Rámce 389

Navigace pomocí rámců 389

Vložené rámce 391

Úvod do technologie Ajax 392

Objekt XMLHttpRequest 393

Příklad použití Ajaxu 395

Použití Ajaxu se zpětným voláním klienta 399

Vytvoření zpětného volání klienta 400

Zpětná volání klienta "pod pokličkou" 407

Zpětné volání klienta ve vlastních ovládacích prvcích 407

Shrnutí 412

Kapitola 30 ASP.NET AJAX 413

Úvod do ASP.NET AJAX 414

ASP.NET AJAX na klientovi – knihovny skriptů 414

ASP.NET AJAX na serveru – ScriptManager 415

Serverová zpětná volání 416

Webové služby v ASP.NET AJAX 417

Umístění webové metody do stránky 425

Aplikační služby ASP.NET AJAX 426

Serverové ovládací prvky ASP.NET AJAX 433

Částečná realizace s prvkem UpdatePanel 434

Pravidelné aktualizace časovačem Timer 442

Časově náročné aktualizace s prvkem UpdateProgress 443

Správa historie prohlížeče 446

Hlubší pohled na klientské knihovny 450

Pochopení klientského modelu 451

Objektově orientované programování v JavaScriptu 452

Framework webové stránky 460

Extendery 465

Instalace ASP.NET AJAX Control Toolkit 466

Extender pro automatické dokončování 468

Obsah ASP.NET AJAX Control Toolkit 471

Shrnutí 477

Kapitola 31 Portály s webovými částmi 479

Typické portálové stránky 480

12

Základy stránek budovaných s Web Parts 481

Vytvoření návrhu stránky 482

WebPartManager a WebPartZone 484

Přidávání webových částí na stránku 485

Přizpůsobení stránky 489

Vytváření webových částí 491

Jednoduché úlohy webové části 492

Vývoj pokročilých webových částí 501

Editory webových částí 510

Propojování webových částí 516

Vlastní akční slovesa a webové části 525

Uživatelské ovládací prvky a pokročilé webové části 526

Dynamické nahrávání webových částí 529

Autorizace webových částí 536

Finální personalizační úlohy 536

Shrnutí 537

Část VI – Nové směry 539

Kapitola 32 MVC 541

Co zvolit, MVC nebo webové formuláře? 542

Vytvoření základní aplikace MVC 542

Vytvoření modelu 543

Vytvoření kontroléru 543

Vytvoření zobrazení Index 544

Otestování (nekompletní) aplikace 545

Zkompletování kontroléru a zobrazení 546

Modifi kace souboru Site.Master 550

Rozšiřování základní aplikace MVC 550

Konfi gurace směrování 550

Zpracování chyb 551

Ověřování identity 553

Konsolidace přístupu k datovému skladu 554

Přidání podpory pro omezení cizích klíčů 558

Přizpůsobování zobrazení 559

Modifi kace zobrazení 559

Přidávání dat k zobrazení 561

13

Přidávání do modelu, modifi kace zobrazení Edit 563

Validace dat 568

Základní validace 569

Přidávání validačních anotací 571

Pomocné metody třídy ActionResult 574

Formát dat JSON 575

Volání jiné metody kontroléru 576

Shrnutí 578

Kapitola 33 Dynamická data 579

Vytvoření aplikace dynamických dat 579

Vytvoření webu dynamických dat 579

Průzkum webu dynamických dat 582

Anatomie projektu dynamických dat 584

Přizpůsobování webu dynamických dat 586

Přizpůsobování se šablonami 586

Přizpůsobování se směrováním 595

Přizpůsobování s metadaty 604

Přizpůsobování validací 611

Shrnutí 616

Kapitola 34 Silverlight 617

Co je Silverlight 618

Silverlight versus Flash 619

Systémové požadavky Silverlightu 621

Vytvoření řešení Silverlightu 621

Kompilace Silverlightu 623

Vstupní stránka 624

Vytvoření projektu Silverlightu 628

Navrhování stránky Silverlightu 629

Co je XAML 632

Nastavování vlastností 634

XAML a kód v pozadí 635

Zpracování událostí 636

Prohlídka knihoven tříd Silverlightu 638

Layout 639

14

Prvek Canvas 639

Prvek Grid 645

Animace 650

Základy animace 650

Defi nice animace 651

Třída Storyboard 651

Příklad interaktivní animace 654

Transformace 658

Používání webových služeb se Silverlightem 662

Vytvoření webové služby 663

Přidání webové reference 663

Volání webové služby 664

Konfi gurace URL webové služby 666

Volání webové služby napříč doménami 666

Shrnutí 668

Rejstřík 669

15

MARIO SZPUSZTA pracuje jako architekt ve skupině Developer and Platform Group společnosti Microsoft v Rakousku a pomáhá softwarovým architektům nej-větších podniků a webovým zákazníkům se zaváděním nových technologií Micro-softu. Několik let se specializoval na vývoj bezpečného softwaru, webové služby a na integraci klientů a serverů Microsoft Office do zákaznických aplikací.

Mario pravidelně přednáší na místních a mezinárodních konferencích, jako např. DevDays a TechEd Europe Developers. V posledních dvou letech byl držitelem tech-nického obsahu TechEd Europe Developers.

O autorechMATTHEW MACDONALD je autor, pedagog a Microsoft MVP. Přispívá do ča-sopisů o programování a je autorem více než tuctu knih o programování .NET, na-příklad Pro Silverlight 3 in C# (Apress, 2009), Pro WPF in C# 2010 (Apress, 2010) a Beginning ASP.NET 4 in C# 2010 (Apress, 2010). V šerém dávnověku svého života studoval anglickou literaturu a teoretickou fyziku.

V současnosti žije v Torontu se svou ženou a dcerou.

ADAM FREEMAN je zkušený odborník v oblasti IT, který zastával vedoucí pozice v mnoha společnostech, naposledy jako CTO (chief technology officer) a COO (chi-ef operating officer) v jisté bankovní společnosti s celosvětovou působností.

Napsal několik knih o Javě a technologii .NET

O odborných korektorechFabio Claudio Ferracchiati je plodný spisovatel se zaměřením na technologie. Fabio spolupracoval na více než tuctu knih o .NET, C#, Visual Basicu a ASP.NET. Je držitelem MCSD (Microsoft Certified Solution Deve-loper) pro .NET a žije v Římě. Jeho blog naleznete na adrese http://www.ferracchiati.com.

Todd Meister pracuje s technologiemi Microsoftu více než deset let. Jako technický redaktor se podílel na vy-dání více než padesáti knih tématicky sahajících od SQL Serveru až k .NET Frameworku. Se svou manželkou Kimberly a čtyřmi fantastickými dětmi žije v centrální Indianě.

16

ÚvodKdyž se poprvé objevilo .NET, byla to malá lavina nových technologií. Najednou tu byl zcela nový způsob, jak psát webové aplikace (ASP.NET), zcela nový způsob, jak se připojovat k databázím (ADO.NET), nové, typově bezpečné jazyky (C# a VB .NET) a spravovaný runtime (CLR). Významnou novou technologií byly také for-muláře Windows (Windows Forms), knihovna tříd pro budování aplikací Windows.

Jak již bezpochyby víte, ASP.NET je nová generace technologií Microsoftu pro vytváření webových aplikací běžících na straně serveru. Je postavena na Microsoft .NET Frameworku, který je seskupením úzce souvi-sejících nových technologií, které přináší kompletní revoluci: od přístupu do databáze až po distribuované aplikace. ASP.NET je jednou z nejdůležitějších komponent .NET Frameworku – jedná se totiž o část, která vám umožní vyvíjet velmi výkonné webové aplikace.

ASP.NET nemá problémy se získáním zájmu programátorů. Bez nadsázky můžeme říci, že ASP.NET je nej-kompletnější platformou pro vývoj webu, která kdy byla sestavena. Převyšuje svého předchůdce ASP, kte-ré bylo navrženo jako "quick-and-dirty" sada nástrojů pro vkládání dynamického obsahu na běžné webové stránky. Oproti němu je ASP.NET plnohodnotnou platformou pro vývoj komplexních a velmi rychlých we-bových aplikací.

V této knize se naučíte všechno, co potřebujete ke zvládnutí ASP.NET 4. Pokud jste již programovali v před-chozí verzi ASP.NET, můžete se zaměřit výhradně na nové funkce, mezi něž patří ASP.NET MVC (kapitola 32), ASP.NET Dynamic Data (kapitola 33) a Silverlight (kapitola 34). Všechny tyto kapitoly naleznete v této knize 2. Pokud jste nikdy v ASP.NET neprogramovali, doporučujeme vám knihu 1 této publikace: poskytuje vhodné tempo výuky, při níž projdete všechny základní věci, které potřebujete znát. Rovněž se podíváte na to, co se děje na pozadí a jak ASP.NET interně funguje. Jediným požadavkem pro zvládnutí problematiky je obstojná znalost jazyka C# a základů .NET. Pokud patříte k vývojářům migrujícím z jazyka Java nebo C++, takže C# je pro vás novinkou, možná bude lepší začít s nějakou jinou knihou, která se věnuje základům .NET, například s knihou Pro C# 2010 and .NET 4 Platform od Andrewa Troelsena (Apress, 2010).

Rozdělení knihyVydavatelství Zoner Press v uplynulých letech vydalo několik knih popisujících problematiku ASP.NET a C#, například ASP.NET 3.5 a C# 2008 – tvorba dynamických stránek profesionálně, která vyšla v roce 2008, nebo ASP.NET 2.0 a C# – tvorba dynamických stránek profesionálně z roku 2006. Protože se ale jednalo o knihy, které se snažily pokud možno co nejvíce obsáhnout problematiku ASP.NET a C#, nepříznivě se to projevilo na velkém počtu stran těchto knih – který se blížil k číslu 1 600 – což znesnadňovalo jejich každodenní použí-vání ve vývojářské praxi. Další vydání, tentokrát s názvem ASP.NET 4 a C# 2010 – tvorba dynamických stránek profesionálně proto bylo z praktických důvodů rozděleno do dvou samostatných knih (dílů). V knize 1 (k za-koupení na www.zonerpress.cz) se věnujeme základům ASP.NET, přístupu k datům a budování webů ASP.NET. Kniha 2 pak popisuje pokročilejší záležitosti, jako je bezpečnost, pokročilé uživatelské rozhraní a nové technologie zahrnuté do ASP.NET (jako je ASP.NET MVC, Silverlight a ASP.NET Dynamic Data).

Kniha 1 obsahuje tato témata:

• Část I – Základy ASP.NET. V kapitole 1 začneme stručným pohledem na celou platformu ASP.NET, .NET Framework a uvedeme si přehled změn, k nimž došlo v ASP.NET 4. V kapitole 2 se pustíte do zvládání svých "nezbytných prostředků k obživě" – zde jmenovitě Visual Studia 2010. V kapitolách 3, 4, 5 a 6 zvládnete klíčové části infrastruktury ASP.NET, například model webové stránky, konfigura-ci aplikace a správu stavu. Jakmile ovládnete tyto základy, podíváme se na to, jak ASP.NET zpracovává

17

požadavky a spravuje dobu života webových aplikací. Rovněž se dozvíte, jakým způsobem rozšířit ar-chitekturu ASP.NET.

• Část II – Přístup k datům. V této části se budeme věnovat oblasti nezbytné pro vývoj veškerého soft-waru, což je přístup a manipulace s daty. V kapitolách 7 a 8 si popíšeme základy ADO.NET a naučíme se navrhovat komponenty pro přístup k datům. V kapitolách 9 a 10 naleznete informace o sadě inova-tivních ovládacích prvků pro vázání dat ASP.NET. Tyto prvky vám umožní naformátovat a zobrazovat data bez nutnosti psát vlastní kód. Kapitola 11 vás zavede k pokročilým strategiím ukládání do cache, což je funkcionalita, která zajišťuje vysoký výkon. Kapitoly 12, 13 a 14 vás přenesou mimo svět ADO.NET, protože si ukážeme, jak pracovat se soubory, s technologií LINQ a obsahem XML.

• Část III – Budování webů ASP.NET. Třetí a poslední část knihy 1 se věnuje základních technikách a funkcionalitách určeným pro správu skupin webových stránek. V kapitole 15 začnete pracovat s uživatelskými ovládacími prvky, které vám umožní opětovně používat části uživatelského rozhraní. V kapitole 16 probereme motivy (které slouží pro automatickou stylizaci ovládacích prvků) a vzory stránek (které jsou určeny pro opětovné použití vaší designové šablony na více webových stránkách). V kapitole 17 si ukážeme, jakým způsobem používat navigační model ASP.NET, aby návštěvníci mohli přecházet z jedné stránky vašeho webu na jinou. V kapitole 18 si pak podrobně popíšeme nasazování aplikací a software webového serveru IIS.

Kniha 2 obsahuje tato témata:

• Část IV – Bezpečnost. Kniha 2 bezprostředně navazuje na knihu 1. Začíná čtvrtou částí, kde se po-díváte na bohatou sadu funkcionalit vztahujících se k zabezpečení ASP.NET. V kapitole 19 začneme s celkovým přehledem principů zabezpečení. Poté se společně podíváme na ověřování založené na for-mulářích (kapitola 20) a funkcionalitu členství, která s ní spolupracuje (kapitola 21). V kapitole 22 se budeme věnovat ověřování systému Windows a v kapitole 23 se naučíte, jak omezit ověřené uživate-le prostřednictvím autorizačních pravidel a jakým způsobem používat zabezpečení na základě rolí. V kapitole 24 prozkoumáte funkcionalitu profilů – což je předem zhotovené řešení určené k ukládání informací specifických pro uživatele. S využitím informací z kapitoly 25 se naučíte šifrováním chránit nejenom data, která ukládáte do databáze, ale také informace, které zasíláte prostřednictvím URL ad-resy. V kapitole 26 vám poté ukážeme, jakým způsobem se můžete zapojit do bezpečnostního modelu ASP.NET vytvořením vlastního zprostředkovatele členství.

• Část V – Pokročilé uživatelské rozhraní. V této části si předvedeme, jakým způsobem lze rozšířit vaše webové stránky o různě pokročilé techniky. V kapitole 27 se podíváme na vlastní ovládací prvky. V kapitole 28 odbočíme k problematice GDI+ a ručně vytvářené grafiky. V kapitolách 29 a 30 bude-me rozvažovat o tom, jak technikami JavaScriptu a Ajaxu učinit webové stránky dynamičtější (tím, že do nich včleníme takové efekty jako automatické dokončování textu a přetahování myší) a vstřícnější (tím, že budou reagovat na události na straně klienta a plynule aktualizovat webovou stránku). Nako-nec v kapitole 31 detailně prozkoumáme funkcionalitu Web Parts ASP.NET, která vám jednoduchým způsobem umožní vytvářet webové portály.

• Část VI – Nové směry. V této části se budeme zamýšlet nad několika nejvíce vzrušujícími inovacemi v moderním webovém vývoji. V kapitole 32 prozkoumáme ASP.NET MVC, což je nová alternativa ke klasickému modelu webových formulářů, která dává vývojářům kompletní kontrolu nad realizací HTML a nad strukturou URL. V kapitole 33 budete zvažovat ASP.NET Dynamic Data, což je perfektní řešení pro rychlé budování takových aplikací, které se točí okolo prohlížení a editování informací ulo-žených v nějaké databázi. V poslední kapitole této knihy proniknete do kouzelného světa Silverlightu, což je plug-in Microsoftu do prohlížeče, který vám umožňuje rozšířit běžné webové stránky o bohatou grafiku, animace, zvuk a samozřejmě i video pro širokou paletu prohlížečů a operačních systémů.

18

Komu je tato kniha určena?Kniha je zamýšlena jako prvotní zdroj informací pro profesionální vývojáře, kteří mají slušné znalosti o webo-vém vývoji na straně serveru. Kniha neposkytuje vyčerpávající pohled na každou ingredienci nacházející se uvnitř .NET Frameworku – taková kniha by musela mít více než dvojnásobný počet stran. Proto se tato kniha raději zaměřuje na to, aby poskytla inteligentní úvod do ASP.NET pro profesionální programátory, kteří se nepotřebují zdržovat se základy. Průběžně se budete soustřeďovat na různá zákoutí .NET Frameworku, která potřebujete znát, abyste mohli budovat profesionální webové aplikace, mezi něž patří přístup k datům a XML. S těmito schopnostmi budete schopni vytvářet weby nové generace, a to s nejlepšími nástroji, jaké jsou dnes k dispozici.

Kniha je také velmi praktická. Nebudete se učit jen funkce ASP.NET, budete se také učit techniky ze sku-tečného světa, s jejichž pomocí budete moci převést svůj web na vyšší kvalitativní úroveň. Pozdější kapitoly knihy jsou zasvěcené břitkým tématům, jako jsou vlastní ovládací prvky, dynamická tvorba grafiky, pokročilá bezpečnost či vysoký výkon při přístupu k datům. Tohle všechno je potřebné pro vývoj profesionálních we-bových aplikací.

Abyste mohli z této knihy vytěžit co nejvíce, měli byste se dobře vyznat v syntaxi jazyka C# a v pojmech ob-jektově orientovaného programování. Nemusíte mít zkušenosti s předchozí verzí ASP.NET, protože veškeré potřebné věci se v této knize probírají. Pokud jste zkušenými programátory v jazycích Java nebo C++ bez jakýchkoliv zkušeností s .NET, měli byste raději začít s nějakou knihou, která se věnuje základům .NET, na-příklad "Pro C# 2010 and .NET 4 Platform" od Andrewa Troelsena (Apress, 2010).

Co potřebujete, abyste mohli pracovat s touto knihou? Chcete-li vyvíjet a testovat webové aplikace ASP.NET, potřebujete Visual Studio 2010. Přestože teoreticky se dá kód vytvářet ručně, je to nesmírně pracné, a to ani nemluvíme o vysoké pravděpodobnosti vzniku různých chyb. Tento ruční přístup se nikdy nepoužívá v profesionálních kruzích.

Pokud také plánujete hostovat weby ASP.NET, musíte používat nějakou serverovou verzi Windows, např. Windows Server 2003 nebo Windows Server 2008. Rovněž si musíte nainstalovat IIS (Internet Information Services), což je software pro hostování webů. Webový server IIS, který se podrobněji popisuje v kapitole 18 (viz ASP.NET 4 a C# 2010, kniha 1), je součástí operačního systému Windows.

Do této knihy je také začleněno několik příkladů, které využívají ukázkové databáze dodávané společně s SQL Serverem, aby bylo možné demonstrovat funkčnost kódu pro přístup k datům, techniky týkající se bezpeč-nosti a jiné funkce. Pro vyzkoušení těchto příkladů můžete používat libovolnou verzi SQL serveru, včetně SQL Server Express, která je součástí některých verzí Visual Studia (a volně ke stažení na stránkách http://msdn.microsoft.com/express/database). Pokud budete používat nějaké jiné relační databáze, pravdě-podobně se neobejdete bez drobných úprav kódu uvedeného v této knize.

Sdělte nám svůj názorJako čtenáři této knihy se stáváte těmi nejdůležitějšími kritiky a komentátory. Vážíme si vašeho názoru a chtě-li bychom vědět, co děláme správně, co bychom mohli dělat lépe, ve kterých oblastech bychom měli publiko-vat, a také bychom chtěli znát vaše další podnětné myšlenky, o které jste ochotni se s námi podělit.

Jako odborný redaktor Zoner Press vítám vaše názory. Můžete mi psát – poslat e-mail nebo dopis – a sdělit mi, co se vám v této knize lí bilo nebo nelíbilo, stejně tak, co bychom měli udělat, aby naše další knihy byly lepší. Pokud mi napíšete, nezapomeňte prosím připojit název knihy, ISBN, jméno autora, vaše jméno, telefon,

19

nebo e-mail. Pozorně zhodnotím vaše názory a poskytnu je autorovi a ostatním redaktorům, kteří pracovali na této knize. Prosím, vězte, že nemohu pomoci s technickými problémy, které se týkají obsahu knihy, a že díky velkému množství e-mailů, které dostávám, nemohu zaručit odpověď na každou zprávu.

E-mail: [email protected] nebo [email protected].

Adresa: ZonerPress, ZONER software, a.s, Miroslav Kučera, Nové sady 18, 602 00 Brno.

Zdrojové kódyZdrojové soubory k této knize je možné stáhnout na této adrese (velikost 14 MB):

http://zonerpress.cz/download/aspnet4-a-c2010.zip

Dále jsou k dispozici ke stažení dvě bonusové kapitoly (velikost 1.4 MB):

http://www.zonerpress.cz/download/bonusove-kapitoly-aspnet.zip

Bonusové kapitolyK této knize jsou k dispozici dvě bonusové kapitoly ve formátu PDF. V těchto kapitolách naleznete obsah, který kvůli technologickým omezením tisku nemohl být zařazen do této knihy. Jedná se o obsah, který není považován za důležitý z hlediska vývoje webu ASP.NET.

POZNÁMKA Tyto bonusové kapitoly pocházejí z předchozích vydání této knihy. Informace z bonusových kapi-tol se ale vztahují i k ASP.NET 4, protože v něm se tyto funkce nezměnily.

Podívejte se, co v nich najdete:

• Bonusová kapitola 1 (Zdroje a lokalizace). V této kapitole se popisuje, jak používat prostředky a lo-kalizace na webech vytvořených s ASP.NET. Jedná se o základní kapitolu pro vývojáře, kteří po třebují vytvořit webové stránky, které mají být k dispozici ve více jazykových variantách.

• Bonusová kapitola 2 (Podpora návrhového režimu). V této kapitole se popisuje, jak můžete do svých vlastních ovládacích prvků přidat podporu návrhového režimu, aby se v prostředí Visual Studia přívě-tivě chovaly, samy zařizovaly serializaci svých vlastností a podporovaly pokročilé návrhářské funkce, jako jsou inteligentní značky.

21

Bezpečnost

ČÁST IV

Správně navržená bezpečnostní strategie hraje klíčovou roli v libovolné distribuované aplikaci. Toto platí zejména u rozsáhlých webových aplikací, které jsou umístěny na ve-řejné síti internet. V této knize naleznete několik kapitol, které se věnují bezpečnostním funkcím ASP.NET.

V kapitole 19 začneme se stručným přehledem třech základních prvků zabezpečení: ověřování (authentication), autorizace (authorization) a důvěrnost (confidentiality). Jakmile vezmete v potaz tento pohled, jste připraveni zvážit klíčové systémy ASP.NET pro ověřování identity uživatelů: ověřování založené na formulářích (kapitola 20), které poskytuje sice jednoduchý, ale přesto flexibilní framework pro zabezpečení veřejných webových stránek, a ověřování systému Windows (kapitola 22), které využívá stáva-jící účty Windows k ověřování uživatelů a je nejčastěji používaným typem ověřování na místních intranetových webech. Dále prozkoumáme i vysokoúrovňové bezpečnost-ní služby ASP.NET, například členství, role a profily. Členství (kapitola 21) poskytuje zabudované bezpečnostní ovládací prvky a umožňuje ASP.NET řídit databázi, do které se ukládají identifikační doklady uživatelů. Role (kapitola 24) vám umožní rozdělit uži-vatele do logických skupin, které mohou mít odlišná oprávnění. Profily (kapitola 25) vám umožní ukládat informace specifické pro jednotlivé uživatele v databázi na straně serveru (a to bez psaní vlastního kódu ADO.NET). Ačkoliv jsou tyto rysy velmi výkon-né, ovlivňují na pozadí poměrně mnoho detailů. Pokud opravdu chcete modifikovat způsob, jakým tyto funkce pracují, musíte si vytvořit vlastního zprostředkovatele, což je téma, do něhož se pustíme v kapitole 26.

Kapitola 25 odbočuje ke kryptografickým funkcím .NET, které jsou zásadní pro zabez-pečení citlivých informací předtím, než je uložíte do souboru nebo databáze. Na rozdíl od ostatních bezpečnostních funkcí, které jsou popsány v této části, kryptografické tří-dy .NET se neomezují na ASP.NET, ačkoliv jsou často užitečné ve webových aplikacích a umožňují provádět zajímavé věci, jako je vytvoření dotazovacího řetězce znemožňu-jícího nedovolenou manipulaci.

23

KAPITOLA 19 Bezpečnostní model ASP.NET

Základním prvkem webových aplikací je jejich bezpečnost – mělo by se na ni myslet už v počátečních fázích vývoje. Znamená v podstatě ochranu proti neautorizovaným činnostem. K tomu se používají různé mechanismy jako identifikace uživatelů, udí-lení a odmítání přístupu k napadnutelným zdrojům a ochrana dat, která jsou ulože-na na serveru a přenášena po drátu. Pro všechny tyto činnosti potřebujeme nějaký podkladový framework poskytující základní bezpečnostní funkcionalitu. ASP.NET má tuto strukturu již zabudovanou, takže s její pomocí můžeme do vašich aplikací imple-mentovat potřebné zabezpečovací funkce.

Bezpečnostní framework ASP.NET obsahuje nejenom třídy pro ověřování a autorizaci uživatelů, ale také i třídy pro akce, které provádějí ověření uživatelé vašich aplikací. .NET Framework navíc obsahuje sadu základních tříd pro implementaci důvěrnosti (confidentiality) a integrity, které jsou založeny na šifrování a digitálních podpisech.

Po přečtení této kapitoly získáte přehled o zabezpečovacích funkcích ASP.NET. V dal-ších kapitolách se podíváme podrobněji na všechna témata, která jsou nastíněna v této kapitole. Zde získáte rychle vhled do hlavních zabezpečovacích funkcí .NET. A co je nejdůležitější – v základních rysech pochopíte, jak včlenit zabezpečovací funkce do vaší aplikační architektury a návrhu a ukážeme vám, jaké jsou nejdůležitější faktory pro tvorbu bezpečného softwaru.

Tvorba bezpečného softwaruI když je zabezpečovací struktura, kterou poskytuje .NET a ASP.NET, velmi výkonná, je nutné si stále uvědomovat určité základní principy, které je nutné používat v pravý čas korektním způsobem. Existuje příliš mnoho projektů, kde se otázky zabezpečení stále odkládají, přičemž tvůrci architektury a vývojáři s nimi v raných fázích projektu nepočítají. Pokud se na zabezpečení nemyslí od začátku – tzn. už v aplikační architek-tuře a návrhu – je pak vůbec možné korektně (a v pravý čas) používat všechny zabez-pečovací rysy, které jsou poskytovány .NET Frameworkem?

Z tohoto důvodu je naprosto nezbytné zahrnout otázky zabezpečení do procesu vývoje aplikace hned od začátku. Jinak není možné při tvorbě architektury a návrhu učinit správná rozhodnutí vztahující se k bezpečnosti.

Kapitola 19 – Bezpečnostní model ASP.NET24

Potenciální hrozbyPři tvorbě bezpečné architektury a návrhu je nutné porozumět do hloubky aplikačnímu okolí. Pokud nevíte, kdo má přístup k vaší aplikaci a kde mohou být potenciální místa ohrožení, není možné vytvořit bezpečný software. Nejdůležitější faktory pro tvorbu bezpečné aplikační architektury a návrhu proto závisejí na správ-ném pochopení takových faktorů vnějšího prostředí, jako jsou uživatelé, vstupní body, a co všechno vám hrozí, pokud budete vystaveni útokům.

V současném procesu vývoje programového vybavení se stává čím dál tím důležitějším modelování hrozeb (threat modeling). Modelování hrozeb strukturovaně analyzuje prostředí aplikace na možná ohrožení, seřa-zuje je podle stupně nebezpečnosti a následně rozhoduje o technikách, jak je zmírnit. Tento postup zaručuje, že rozhodnutí o typu zabezpečovací technologie (například ověřování uživatelů nebo šifrování pomocí SSL) se bude odvíjet od aktuální příčiny, tedy od samotné hrozby.

Modelování hrozeb je důležité ještě z dalšího důvodu. Pravděpodobně tušíte, že ne všechny potenciální hrozby mohou být zmírněny zabezpečovacími technologiemi, jako jsou ověřování a autorizace. Jinými slovy: některá ohrožení nemohou být eliminována technicky. Například pro on-line přístup k bankovním aplikacím může být použito SSL pro zabezpečení provozu na webové stránce. Jak ale uživatelé poznají, že opravdu používají webovou stránku banky, a ne fingovaný web podstrčený hackery? Dá se to zjistit jedině tak, že se podívají na certifikát, který byl použit pro vytvoření kanálu SSL. Uživatelé ovšem o této metodě musejí vědět také, takže je musíte o ní nějakým způsobem informovat. "Zmírňovací technika" zde není zabezpečovací technolo-gií. Zajišťuje pouze, aby všichni uživatelé věděli, jak se podívat na daný certifikát. (Nemůžete je samozřejmě k tomu nutit, ale pokud budou vaše informace vhodně prezentovány, můžete většinu uživatelů přimět ke kon-trole certifikátu.) Modelování hrozeb vám jakožto analytická metoda pomůže zjistit podobný typ problémů, který není jenom technické povahy.

TIP Modelování hrozeb je pochopitelně velké téma, které přesahuje rámec této knihy. Proto vám doporučuje-me, abyste se podívali na následující knihy – Michael Howard a David LeBlanc: Writing Secure Code, Second Edition (Microsoft Press, 2002) nebo Frank Swiderski a Window Snyder: Threat Modeling (Microsoft Press, 2004). Pro manažery projektu a architekty je naprosto nepostradatelný také tento titul: The Security Development Lifecycle od Michaela Ho-warda a Stevea Lipnera (Microsoft Press, 2006). Čtvrtá část této knihy se zaměřuje na to, jak zajistit, aby zabezpečení bylo integrální součástí životního cyklu vývoje softwaru, od prvotních kroků plánování přes architekturu, vývoj, testo-vání až po údržbu. Shrnuje, jak správa projektů Microsoftu zajistí, že otázka bezpečnosti bude integrována do projektu, a to nenásilným a pragmatickým způsobem.

Zásady bezpečného programováníBezpečná architektura a návrh samy o sobě neučiní vaši aplikaci zcela bezpečnou. Po vytvoření bezpečné architektury a návrhu musíme také napsat bezpečný kód. Jak už jsme zmínili, knihy Writing Secure Code, Se-cond Edition od Michaela Howarda a Davida C. LeBlanca (Microsoft Press, 2002), Threat Modeling od Franka Swiderskiho a Windowa Snydera (Microsoft Press, 2004) a také The Security Development Lifecycle od Mi-chaela Howarda a Stevea Lipnera (Microsoft Press, 2006) jsou výbornými zdroji podrobných informací pro každého vývojáře. Při tvorbě programového kódu webových aplikací musíme mít stále na paměti tyto zásady:

• Nikdy nevěřte uživatelskému vstupu. Předpokládejte, že každý uživatel má špatné úmysly, dokud se nepřesvědčíte o opaku. Proto je nutné pečlivě ověřovat uživatelský vstup. Ověřovací kód programu pište tak, aby se údaje od uživatele vždy porovnávaly pouze s povolenými hodnotami, nikoliv s hod-

ASP.NET 4 a C# 2010 – tvorba dynamických stránek profesionálně 25

notami neplatnými. (Vždy totiž existuje více neplatných hodnot, než si můžete v průběhu vytváření aplikace uvědomit.)

• Nikdy nepoužívejte spojování řetězců pro tvorbu výrazů SQL. Abyste zabránili průniku ( injektáží SQL) do aplikace, používejte vždy parametrizované výrazy, viz kapitolu 7.

• Z webové stránky nikdy neposílejte data zadaná uživatelem přímo na výstup, bez ověření a zakó-dování. Uživatel by totiž mohl zadat fragmenty nějakého kódu (např. JavaScriptu), což by mohlo vést k tomu, že váš web by mohl být napadnutelný. Pro eliminování speciálních znaků jako < nebo > před zobrazením na vaší stránce vždy použijte HttpUtility.HtmlEncode() nebo použijte nějaký webo-vý ovládací prvek, který toto zakódování provede automaticky.

• Nikdy neukládejte citlivá data, klíčová obchodní data nebo data ovlivňující rozhodování o inter-ních obchodních pravidlech, která jsou generována vaší aplikací, do skrytých polí webové stránky. Skrytá pole se dají snadno změnit zobrazením zdrojového kódu stránky, jeho modifikací a uložením do souboru. Útočníkovi pak stačí předložit serveru tuto lokálně uloženou a modifikovanou webovou stránku. Pomocí plug-inů v prohlížeči je to stejně snadné jako napsat e-mail v Microsoft Outlooku.

• Nikdy neukládejte citlivá nebo klíčová obchodní data ve stavu zobrazení. Stav zobrazení je jenom dalším skrytým polem na stránce, přičemž se dá snadno dekódovat a prohlížet. Šifrování stavu zob-razení (popsali jsme je v kapitole 6) pomůže ochránit jen takové informace, které jsou cenné jen ne-dlouhou dobu. Uvědomte si, že i zašifrovaná data se mohou rozluštit, má-li na to útočník hodně času, zdrojů a motivace.

• Zapněte SSL při použití základního ověřování nebo ověřování ASP.NET založeného na formulá-řích. Další informace o ověřování založeném na formulářích naleznete v kapitole 20. SSL se věnuje tato kapitola (viz sekci "Jak na SSL" dále v této kapitole).

• Chraňte vaše cookie. Používáte-li ověřování založené na formulářích, vždy ochraňujte vaše ověřovací cookie. Časové limity nastavujte co nejkratší a pouze na nezbytně dlouhou dobu.

• Používejte SSL. Obecně řečeno: pokud webová aplikace zpracovává citlivá data, chraňte celý web tím, že budete používat SSL. Nezapomeňte chránit i adresáře s obrázky nebo s jinými soubory, které aplika-ce nespravuje přímo prostřednictvím SSL.

Tyto zásady obsahují jen několik základních důležitých otázek. Abychom si mohli udělat ucelený obrázek o konkrétní aplikaci a sestavili kompletní seznam potenciálních rizik, musíme vytvořit simulační modely ohrožení. Investujte do dalšího vzdělávání, neboť hackerské dovednosti a techniky se vyvíjejí stejně rychle, jako se rychle rozvíjejí všechny ostatní obory.

Pokud zapomenete třeba jenom na jednu z těchto zásad, budou všechna ostatní zabezpečovací opatření více či méně neúčinná. Nikdy nezapomeňte na zásadu, že celkové zabezpečení je pouze tak kvalitní, jak kvalitní je jeho nejslabší článek.

StrážníJedním z dobrých způsobů pro vylepšení bezpečnosti aplikace je mít velké množství komponent, které pomá-hají prosadit bezpečnost. Strážní ( gatekeepers) představují konceptuální vzor, který používá pro bezpečnostní infrastrukturu model zpracovatelského kanálu (pipelining model). Tento model vám pomůže zvýšit zabezpe-čení vaší aplikace.

Model strážných vždy předpokládá, že bezpečná aplikace má vždy více zabezpečovacích mechanismů, než je nezbytné. Každý z těchto mechanismů je implementován jako jeden strážný, jenž je odpovědný za vynucování

Kapitola 19 – Bezpečnostní model ASP.NET26

některých podmínek souvisejících s bezpečností. Pokud jeden z těchto strážných selže, útočník ve zpracova-telském kanálu narazí na dalšího z řady strážných. Čím více jich bude aplikace obsahovat, tím to bude mít útočník složitější. Tento model vlastně naplňuje nejdůležitější princip tvorby zabezpečených aplikací – být co nejlépe zajištěný a co možná nejvíce komplikovat útočníkovi život.

Na obrázku 19-1 vidíte zpracovatelský kanál strážných. Na jeho konci vidíte chráněný zdroj (kterým může být cokoliv, dokonce i kód vaší vlastní stránky). Chráněný zdroj bude dosažitelný nebo spustitelný jen tehdy, po-kud k němu povolí přístup všichni strážní. Pokud odepře přístup třeba jenom jediný strážný, bude zpracování požadavku vráceno volajícímu společně s bezpečnostní výjimkou.

Obrázek 19-1. Zpracovatelský kanál strážných.

Tento způsob implementace použitý pro ochranu centrálního zdroje lze obecně označit za dobrou myšlen-ku. Tímto způsobem lze zabezpečit i obchodní vrstvu. Tento mechanismus rovněž používá aplikační infra-struktura ASP.NET. ASP.NET obsahuje několik strážných, kteří jsou použiti pro vynucování několika bez-pečnostních podmínek, pro ochranu vaší aplikace. V další sekci této kapitoly se dozvíte, jaké strážné vlastně framework ASP.NET zahrnuje a za co tito strážní zodpovídají.

Úrovně bezpečnostiPro převládající typ webových aplikací jsou nezbytné úkoly pro implementaci bezpečnosti stále stejné (kromě problémů identifikovaných během vaší relace modelující hrozby):

• Ověřování. Nejprve musíte ověřit totožnost uživatele (autentizace). Ověřovací procedura se zeptá, o koho jde. Pak určí, kdo pracuje s vaší aplikací na druhé straně.

• Autorizace. Jakmile se dozvíte, kdo pracuje s vaší aplikací, aplikace musí rozhodnout, jaké operace smí uživatel spouštět a k jakým zdrojům bude mít přístup. Autorizace se vlastně ptá, na co všechno máte oprávnění.

• Utajení. V době, kdy uživatel pracuje s aplikací, musíte zajistit, aby se nikdo jiný nemohl dostat k cit-livým datům zpracovávaným uživatelem. Proto je nutné zašifrovat přenosový kanál mezi klientským prohlížečem a webovým serverem. Kromě toho bude nezbytné šifrovat data ukládaná na pozadí (nebo ve formě cookie u klienta), pokud chcete zamezit tomu, aby správce databáze nebo další zaměstnanci společnosti, kde je vaše webová aplikace hostována, si mohli zobrazit data vaší aplikace.

• Integrita. Nakonec musíte zajistit, aby data přenášená mezi klientem a serverem nebyla změněna neautorizovanými činiteli. Ke zmírnění tohoto typu hrozeb přispívají digitální podpisy.

115

KAPITOLA 22 Ověřování systému Windows

Ověřování založené na formulářích je výborné, pokud si chcete vytvořit vlastní ověřo-vací systém se záložní databází a vlastní přihlašovací stránkou. Co když ale vytváříte webovou aplikaci pro menší skupinu známých uživatelů, kteří už mají své uživatelské účty Windows? V podobných situacích může být vhodnější nasazení systému, který do svého fungování zapojí již existující údaje o uživatelích a jejich členství ve skupi-nách. Řešením je ověřování systému Windows (Windows authentication), při němž se srovnávají údaje o uživatelích webu s uživatelskými účty Windows, které jsou defi-novány na místním počítači nebo v jiné doméně sítě. V této kapitole se dozvíte, jak ověřování systému Windows použít ve vašich webových aplikacích. Dozvíte se také, jak použít zosobnění (impersonation), potřebujete-li dočasně převzít cizí identitu.

Úvod do ověřování systému WindowsOvěřování systému Windows není na rozdíl od ověřování založeného na formulá-řích integrováno v ASP.NET. Ověřování systému Windows předává IIS zodpovědnost za ověřování identity. IIS požádá prohlížeč, aby sám sebe ověřil tím, že poskytne při-hlašovací doklady, jež jsou mapovány na nějaký uživatelský účet Windows. Jestliže se uživatel ověřil úspěšně, IIS povolí žádost o webovou stránku a předá informace o uži-vateli a roli ASP.NET tak, že programový kód může fungovat téměř stejně, jako když pracuje s informacemi o identitě ve scénáři s ověřením založeném na formulářích.

Celý proces názorně ukazuje obrázek 22-1.

Proč používat ověřování systému Windows?Jsou pro to čtyři hlavní důvody:

• Velmi málo programátorské práce pro vývojáře.

• Dovoluje použít již existující uživatelská přihlášení.

• Poskytuje jediný ověřovací model pro více typů aplikací.

• Dovoluje používat zosobnění a zabezpečení Windows.

Kapitola 22 – Ověřování systému Windows116

Obrázek 22-1. Ověřování systému Windows.

První důvod je zcela jednoduchý – při ověřování systému Windows je IIS a klientskému prohlížeči povoleno se postarat o ověřovací proces, takže nemusíte vytvářet přihlašovací stránku, kontrolovat databázi nebo psát nějaký vlastní programový kód. Systém Windows dále podporuje i takové základní aspekty uživatelského účtu jako je vypršení doby platnosti hesla, uzamčení účtu nebo členství ve skupinách.

Druhý a nejdůležitější důvod, proč používat ověřování systému Windows, spočívá v tom, že vám dovoluje zapojit do práce již existující účty Windows. Tento typ ověřování se standardně používá pro aplikace, v nichž uživatelé i webový server patří ke stejné lokální síti nebo intranetu. To znamená, že uživatelé mohou být ověřeni pomocí stejných přihlašovacích dokladů, které používají, když se přihlašují ke svým počítačům. Nej-větším přínosem této metody je, že lze provádět "neviditelné" ověřování, při němž (v závislosti na použitých nastaveních a architektuře sítě) není nutná samostatná přihlašovací procedura. Prohlížeč jednoduše používá identitu aktuálně přihlášeného uživatele.

Třetí zmíněný důvod je velmi zajímavý. Při práci s ověřováním systému Windows máte k dispozici jediný ově-řovací model pro různé typy aplikací. Tentýž ověřovací model můžete například používat pro webové služby, aplikace ASP.NET a služby založené na Windows Communication Foundation, bez ohledu na to, kde jsou hostovány. Proto vás ověřování systému Windows může ochránit před problémem toku identit mezi větším množstvím strojů. Windows s využitím Kerberosu nabízí dobře vymyšlený mechanismus pro takové scénáře.

Ověřování systému Windows vám umožní využít stávající nastavení zabezpečení Windows. Pouhým nastave-ním přístupových oprávnění k souborům Windows můžete například ovládat přístup k souborům. Je ovšem důležité si uvědomit, že tato oprávnění nemají automatický efekt. Je to proto, že vaše webová aplikace obvykle používá pevný účet (typicky Network Service na IIS 7.x). Lze to změnit opatrným použitím ověřování systé-mu Windows a zosobnění, jak je popsáno v sekci s názvem "Zosobnění" v této kapitole.


Proč nepoužívat ověřování systému Windows?Proč byste neměli používat tento způsob ověřování?

• Je spjat s uživateli Windows.

• Je spjat s klientskými počítači Windows.

• Neposkytuje velkou flexibilitu nebo možnost mít nad ním kontrolu. Nedá se snadno přizpůsobovat.

První problém spočívá v tom, že ověřování systému Windows nebude fungovat, pokud uživatelé, které ověřu-jete, nemají platné účty Windows. U veřejně přístupných webů tuto překážku prakticky nelze odstranit. I kdy-by bylo možné pro každého uživatele vytvořit účet Windows, nikdy to nebude tak efektivní jako databázový přístup pro větší množství uživatelů. Existuje zde také potenciální bezpečnostní riziko, protože účty uživatelů Windows mohou mít oprávnění k přístupu na počítač webového serveru nebo k jiným síťovým počítačům.

Druhý problém spočívá v tom, že některé ověřovací metody, které používá IIS, od uživatelů vyžadují, aby měli na počítači kompatibilní software, což limituje možnost používat ověřování systému Windows u těch uživa-telů, kteří nemají operační systém od Microsoftu nebo nepoužívají Internet Explorer.

A posledním velkým problémem je to, že ověřování systému Windows nedává žádné možnosti, jak mít kon-trolu nad ověřovacím procesem. Nelze tedy jednoduše programově přidávat, odstraňovat a spravovat infor-mace spjaté s účtem Windows nebo společně s přihlašovacími doklady ukládat nějaké dodatečné informace specifické pro jednotlivé uživatele. Jak jste se dočetli v předchozí kapitole, všechny tyto aspekty se dají snadno začlenit do ověřování založeného na formulářích, ovšem v ověřování systému Windows nehrají žádnou roli.

Mechanismy ověřování systému WindowsPokud implementujete ověřování systému Windows, IIS použije jednu ze tří ověřovacích strategií, s jejíž po-mocí bude ověřovat každý přijatý požadavek.

• Základní ověření. Uživatelské jméno a heslo je předáváno jako prostý text. Základní ověření je jediná ověřovací metoda, která je podporována všemi prohlížeči jako součást standardu HTML.

• Ověřování algoritmem Digest. Není přenášeno ani uživatelské jméno ani heslo. Místo nich se posílá hašovaná forma těchto údajů, která je z kryptografického hlediska bezpečná.

• Integrované ověřování systému Windows. Není přenášeno ani uživatelské jméno, ani heslo. Místo toho je údaj o identitě uživatele, který se právě přihlásil k Windows, automaticky předáván ve formě tokenu. Je to jediný typ ověřování, který se uskutečňuje zcela transparentně (bez zásahu uživatele).

Následující sekce této kapitoly probírají tyto tři uvedené možnosti.

POZNÁMKA Pro ověřování systému Windows existují i méně používané protokoly. Je to například ověřování založené na certifikátu. Pokud zvolíte tento typ ověřování, musíte všem klientům rozeslat digitální certifikát a každý certifikát mapovat na příslušný účet Windows. U této metody se bohužel příliš často objevují problémy s administrací a při nasazování. Další možností je pokročilé ověřování algoritmem Digest (Advanced Digest authentication), které fun-guje v podstatě stejně jako ověřování algoritmem Digest, ovšem s tím rozdílem, že hesla jsou ukládána bezpečněji.


Základní ověřeníNejpodporovanějším ověřovacím protokolem je základní ověření (basic authentication). Podporují ho téměř všechny webové prohlížeče. Pokud web vyžaduje ověření klienta pomocí základního ověření, prohlížeč zob-razí přihlašovací dialog pro zadání uživatelského jména a hesla, který je podobný dialogu na obrázku 22-2.

Obrázek 22-2. Přihlašovací dialog pro základní ověření.

Poté, co uživatel poskytne tyto údaje, jsou přeneseny na webový server (v tomto případě localhost). Jakmile IIS obdrží ověřovací data, pokusí se uživatele ověřit ve spolupráci s odpovídajícím účtem Windows.

Největším omezením metody základního ověření je to, že není bezpečná, alespoň co se týče jí samotné. Při-hlašovací doklady, které jsou reprezentovány uživatelským jménem a heslem a jež byly získány pomocí zá-kladního ověření, jsou mezi klientem a serverem přenášeny jako prostý text. Data jsou zakódována (nikoliv šifrována!) do řetězce typu Base64, který lze při odposlouchávání velmi snadno přečíst. V systému Windows Vista byl přihlašovací dialog změněn tak, aby zobrazil varování, pokud připojení není bezpečné, což znamená situaci, kdy pro komunikaci s webovým serverem není použito SSL/TLS a používá se základní ověřování. Toto varování je vidět na obrázku 22-2. Z tohoto důvodu byste měli základní ověření používat jen tehdy, když není potřeba chránit přihlašovací doklady uživatele, nebo pouze ve spolupráci s nějakým šifrovacím HTTP protokolem (jako je například SSL). Takto budou data, která jsou jinak snadno dostupná pro jakoukoliv utilitu slídicí po síti, zašifrována prostřednictvím složitého algoritmu. Více informací o SSL naleznete v kapitole 19.

Ověřování algoritmem DigestTento typ ověřování (stejně jako základní ověření) vyžaduje od uživatele, aby zadal informace do přihlašova-cího dialogu, který je zobrazen prohlížečem. Na rozdíl od základního ověřování ovšem ověřování algoritmem Digest předává hašovanou formu hesla, nikoliv heslo samotné. (Anglické slovo digest je synonymem slova haš – odtud pochází název tohoto ověřovacího schématu.) Protože heslo se nikdy neposílá do sítě v textové podobě (posílá se ve formě haše), není možné takové heslo ukrást ani tehdy, když se nepřenáší přes SSL.

Proces ověřování uživatele algoritmem Digest funguje takto: 1. Neověřený klient požaduje webovou stránku s omezeným přístupem. 2. Server odpoví odezvou HTTP 401. Tato odezva zahrnuje tzv. příležitostné slovo (nonce value), což je

náhodně vygenerovaná série bajtů. Server zajišťuje, že každé takové příležitostné slovo je jedinečné (předtím, než je vydá).


3. Klient pro vytvoření haše použije toto příležitostné slovo, heslo, uživatelské jméno a některé další hod-noty. Hodnota tohoto haše, tzv. digest, je poslána zpátky na server společně s uživatelským jménem ve formě prostého textu.

4. Server použije příležitostné slovo, heslo uložené pro uživatelské jméno a ostatní hodnoty pro vytvoření haše. Tento haš pak porovná s hašem získaným od klienta. Pokud obě hašované hodnoty souhlasí, ověření je úspěšné.

Pokud případný útočník získá digest, není mu příliš užitečný, protože příležitostné slovo se mění s každým novým ověřovacím požadavkem. Z digestu se původní heslo extrahovat nedá. Protože digest obsahuje náhod-né příležitostné slovo, nemůže být použit pro opakované útoky (replay attacks), kdy se útočník pokusí získat přístup ke chráněným zdrojům tak, že použije dříve zachycený digest.

Teoreticky je ověřování algoritmem Digest standardem a webové servery a prohlížeče by měly být schopny je používat pro výměnu informací sloužících k ověřování identity. Firma Microsoft bohužel interpretuje část specifikace ověřování algoritmem Digest trochu jiným způsobem než ostatní organizace, jako třeba Apache Foundation ( webový server Apache) a projekt Mozilla ( webový prohlížeč Mozilla). Důsledkem je, že ověřová-ní algoritmem Digest v IIS v současnosti funguje pouze v Internet Exploreru 5.0 a vyšších verzích.

Dalším omezením ověřování algoritmem Digest v IIS je to, že funguje pouze tehdy, když ověřovaný virtuální adresář běží pod doménovým kontrolérem Windows Active Directory.

Integrované ověřování systému WindowsTato metoda je nejvhodnějším ověřovacím standardem pro intranetové aplikace založené na WAN a LAN, neboť ověřování probíhá bez nutnosti interakce s klientem. Pokud IIS požádá klienta, aby se ověřil, prohlížeč pošle token reprezentující uživatelský účet Windows aktuálního uživatele. Pokud webový server při ověřování pomocí těchto údajů neuspěje, objeví se přihlašovací dialog, do kterého může uživatel zadat jiné uživatelské jméno a heslo.

Integrované ověřování systému Windows může fungovat jen tehdy, pokud jsou klient a webový server ve stej-né lokální síti nebo intranetu, neboť tato metoda de facto nepřenáší údaje obsahující uživatelská jména a hes-la. Místo toho pracuje v koordinaci s doménovým serverem nebo s instancí Active Directory, kde proběhlo přihlášení, přičemž přikáže příslušnému počítači, aby poslal na webový server příslušné ověřovací údaje.

Jako protokol pro přenášení ověřovacích údajů se použije buď NTLM (NT LAN Manager), nebo Kerberos 5: závisí to na verzi operačního systému klienta a serveru. Pokud na obou stranách běží Windows 2000 nebo vyšší a oba stroje pracují v doméně Active Directory, je jako ověřovací protokol použit Kerberos. Jinak se pou-žije NTLM. Ačkoliv oba protokoly jsou extrémně bezpečné (Kerberos je z aktuálně dostupných protokolů ten nejbezpečnější), i tak mají jistá omezení. Integrované ověřování systému Windows v podstatě pracuje pouze v Internet Exploreru a není podporováno mimo tento webový prohlížeč. Kerberos funguje jenom na počíta-čích, na kterých běží Windows 2000 nebo vyšší verze, přičemž ani jeden z protokolů nemůže pracovat přes proxy server. Kerberos navíc vyžaduje, aby byly otevřeny některé dodatečné porty na firewallech. V příští sekci se dozvíte základní věci o ověřovacích protokolech, které jsou používány pro integrované ověřování systému Windows, což vám pomůže lépe pochopit jednotlivé konfigurační kroky (zejména zosobnění a delegování).

Ověřování s protokolem NTLMOvěřování s protokolem NTLM je integrováno v operačním systému Windows od okamžiku, kdy byla do něj zahrnuta podpora sítí. NTLM ověřuje klienty pomocí mechanismu výzva/odezva, který je založen na trojí výměně mezi klientem a serverem. Všechny procesy, o nichž se dozvíte v této sekci, se odehrávají v operač-


ním systému zcela automaticky. Přirozeně – všechno tohle bude fungovat pouze za předpokladu, kdy klient i server používají operační systém Windows.

Klient zahajuje komunikaci vysláním zprávy na server, což signalizuje, že klient chce se serverem komuni-kovat. Server následně vygeneruje 64bitovou náhodnou hodnotu, které se říká příležitostné slovo (nonce) a na požadavek klienta odpoví tím, že toto příležitostné slovo vrátí. Této odezvě se říká výzva (challenge). Nyní operační systém klienta požaduje od uživatele uživatelské jméno a heslo. Okamžitě poté, co uživatel zadá tyto informace, systém heslo zahašuje. Tento haš hesla (říká se mu hlavní klíč, master-key) bude použit pro zašifrování příležitostného slova. Klient tedy posílá serveru svou odezvu (response) společně s uživatel-ským jménem a zašifrovaným příležitostným slovem, čímž se dokončuje mechanismus výzva/odezva.

Server musí nyní ověřit platnost vráceného příležitostného slova. Podle toho, zdali se jedná o místního uživa-tele nebo doménového uživatele, se validace uskutečňuje buď místně, nebo vzdáleně na doménovém kontro-léru. V obou případech je hlavní klíč uživatele, tedy hašovaná verze hesla, získáván z databáze zabezpečených účtů. S tímto hlavním klíčem se teď příležitostné slovo ve formě prostého textu zašifruje na serveru ještě jednou (server pochopitelně toto příležitostné slovo uloží do cache v textové podobě ještě předtím, než ho pošle klientovi). Pokud tato opětovně vytvořená zašifrovaná verze příležitostného slova souhlasí se zašifro-vanou verzí, která byla vrácena klientem, je ověření úspěšné, takže pro uživatele bude na serveru vytvořena přihlašovací relace. Obrázek 22-3 detailně ukazuje průběh tohoto procesu.

Obrázek 22-3. Letmý pohled na NTLM.

239

KAPITOLA 26Vlastní zprostředkovatelé členství

V předchozích kapitolách jste se dozvěděli všechny potřebné podrobnosti o ověřování a autorizaci uživatelů pomocí ASP.NET, a to jak prostřednictvím ověřování založeného na formulářích, tak i ověřování systému Windows. Dozvěděli jste se také, že pokud používáte ověřování založené na formulářích, zůstává na vás zodpovědnost za správu uživatelů ve vašem vlastním úložišti (a také za správu rolí, pokud chcete v aplikaci im-plementovat ověřování založené na rolích).

ASP.NET se naštěstí dodává s API členství a s API rolí, která poskytují framework pro správu uživatelů a rolí. O API členství jste se podrobně dočetli v kapitole 21, o API rolí pak v kapitole 23. Framework je možné rozšiřovat prostřednictvím zprostředkovatelů implementujících reálný přístup k podkladovému úložišti dat. V obou zmíněných ka-pitolách jste používali výchozího zprostředkovatele pro SQL Server, který se dodává společně s ASP.NET.

Tuto výchozí implementaci, která funguje s SQL Serverem, samozřejmě můžete nahra-dit implementací vlastních zprostředkovatelů členství a rolí. To vám umožňuje zvolit jiné podkladové úložiště, které bude používáno pro údaje týkající se uživatelů a rolí, aniž by se to nějak dotklo samotné webové aplikace.

V této kapitole se naučíte rozšiřovat API členství a API rolí tím, že implementujete vlastní zprostředkovatele členství a rolí. Dále se dozvíte, jak se konfiguruje a ladí vlast-ní zprostředkovatel pro webovou aplikaci. Informace z této kapitoly vám poskytnou dostatečnou výbavu pro vytváření dalších vlastních zprostředkovatelů – například pro API profilů nebo pro personalizační engine webových částí (web parts, viz kapitola 31), protože proces jejich tvorby je stejný.

Architektura vlastních zprostředkovatelůV kapitolách 21 a 23 jste se podrobně dočetli o integrovaných službách členství a rolí. Ty poskytují hotové, rovnou v praxi použitelné řešení správy uživatelů a rolí s ověřo-váním založeném na formulářích. Jak bylo už dříve vysvětleno, celý model můžete rozšiřovat prostřednictvím vlastních zprostředkovatelů. Při implementaci těchto zpro-středkovatelů byste vždy měli mít před očima jejich architekturu, která je znázorněna

Kapitola 26 – Vlastní zprostředkovatelé členství240

na obrázku 26-1. Vlastní zprostředkovatel je vždy založen na nejnižší úrovni vrstveného modelu, který byl zaveden prostřednictvím frameworku pro členství a role ASP.NET. Je důležité si uvědomit, že každé další roz-hraní API, které je založeno na zprostředkovatelích v ASP.NET, je strukturováno stejně. Z tohoto důvodu je implementace vlastních zprostředkovatelů pro API profilů (nebo pro personalizační engine ASP.NET) velmi podobná.

Obrázek 26-1. Framework členství a rolí.

Ze schématu základní architektury lze vysledovat, že služby členství a rolí jsou na sobě vzájemně nezávislé. Proto mají zprostředkovatelé členství a zprostředkovatelé rolí samostatné základní třídy. Uživatele členství a role můžete navíc ukládat v různých podpůrných systémech. Dobrým příkladem je používání služby rolí s ověřováním systému Windows. Vzpomeňte si, co jste se v kapitole 23 dozvěděli o rolích specifických pro aplikaci, které se používaly pro autorizaci v rámci aplikace (a nikoliv uvnitř skupiny Windows). Jinak řečeno, v případě potřeby jste schopni zrušit vazbu aplikace na podkladovou infrastrukturu Active Directory.

Než se začnete zabývat podrobnostmi implementace vlastních zprostředkovatelů, je důležité pochopit, proč a kdy je žádoucí vytvořit vlastního zprostředkovatele členství. Mezi nejčastější důvody patří:

• Chcete použít již existující databázi uživatelů a rolí, která má jiné schéma, než je standard ASP.NET.

• Místo Microsoft SQL Serveru chcete použít nějakou jinou databázi.

• Chcete použít nějaké neobvyklé datové úložiště ( soubor XML, webová služba, adresáře LDAP).

• Chcete implementovat dodatečnou ověřovací logiku. Charakteristickým příkladem této implementace bývají webové stránky státní správy, kde uživatelé často musejí ověřovat svou identitu třemi údaji – uživatelským jménem, subskripčním ID (subscription ID) a heslem.

Pokud chcete jen k informacím, které ukládá výchozí implementace, přidávat nějaké vaše vlastní informace, pak vám doporučujeme, abyste vlastního zprostředkovatele neimplementovali. Protože API pro členství na-


bízí přístup ke klíči, který jednoznačně identifikuje uživatele v úložišti, doporučujeme, abyste přidali do data-báze vlastní tabulky pro ukládání těchto dodatečných informací a prostřednictvím jedinečného uživatelského klíče propojili informace uložené v těchto tabulkách s aktuálním uživatelem úložiště zprostředkovatele člen-ství. Alternativním postupem je implementovat pro tyto dodatečné vlastnosti profily uživatelů. Pokud chcete pouze přidat pár hodnot navíc, je to mnohem snadnější než implementovat vlastního zprostředkovatele.

Z aplikace je možné přistupovat k jedinečnému klíči uživatele prostřednictvím vlastnosti ProviderUserKey třídy MembershipUser. V této kapitole se dozvíte, jak se tento jedinečný klíč reprodukuje do Provider-UserKey třídy MembershipUser.

Základní kroky při vytváření vlastních zprostředkovatelůNyní se dozvíte, jak implementovat vlastního zprostředkovatele pro služby členství a rolí. Tvorba vlastního zprostředkovatele zahrnuje tyto kroky:

1. Návrh a vytvoření podkladového úložiště dat. 2. Vytvoření utilitních tříd pro přístup k podkladovému úložišti dat. 3. Vytvoření třídy, která dědí z MembershipProvider. 4. Vytvoření třídy, která dědí z RoleProvider. 5. Vytvoření testovací aplikace zprostředkovatele. 6. Konfigurace vlastních zprostředkovatelů v testovací aplikaci. 7. Použití vlastních zprostředkovatelů ve vlastní aplikaci.

Implementace vlastních zprostředkovatelů je vcelku bezproblémová, nicméně zabere nějaký čas, protože mu-síte implementovat poměrně dost metod a vlastností. V příštích oddílech vytvoříte vlastního zprostředkova-tele členství a rolí, který bude jako podkladové úložiště dat používat XML soubor. Soubory XML sice nejsou dobrým řešením pro vysoce škálovatelné aplikace, nicméně to může být hezké alternativní řešení, pokud vytváříte jednoduchou aplikaci, kterou musíte hostovat na nějakém zprostředkovatelském serveru, a přitom vůbec nemáte přístup k databázi, jakou je například SQL Server.

Návrh vlastního zprostředkovatele v obecných rysechNež začnete vytvářet vlastního zprostředkovatele, měli byste si ujasnit hlavní body celkového návrhu řešení. Abyste se mohli soustředit na samotnou implementaci zprostředkovatele členství a rolí, potřebujete udržovat podkladovou funkčnost co nejjednodušší. V rámci XML bude nejjednodušší načítat a ukládat data do XML souborů prostřednictvím serializace XML. Ta umožňuje uložit kompletní obraz objektu ( objektový graf) do souboru prostřednictvím jediného volání funkce. Jeho čtení je pak rovněž možné prostřednictvím jediné-ho volání funkce.

Serializer = new XmlSerializer(typeof(List<SimpleUser>));

using (XmlTextReader reader = new XmlTextReader(fileName))

{

_Users = (List<SimpleUser>)Serializer.Deserialize(reader);

}


Zapamatujte si, že v okamžiku, kdy se vytváří instance serializátoru, musíte sdělit XmlSerializer typ, který chcete serializovat a deserializovat. Také nezapomeňte, že v kódu je potřeba importovat jmenné soubory Sys-tem.Xml a System.Xml.Serialization předtím, než použijete třídy XmlTextReader, XmlTextWriter a XmlSerializer.

Třídy jako je MembershipUser bohužel neumožňují přístup k některým informacím (například k heslu), takže je nemůžete použít k serializaci XML přímo. Serializace XML požaduje, aby všechny vlastnosti a členy, které potřebujete, byly uloženy jako veřejné vlastnosti, nebo jako veřejné členy. Pro podpůrné úložiště tedy vytvoříte vlastní reprezentaci uživatelů a rolí ve formě utilitní třídy. Tyto třídy nikdy nebudou předány apli-kaci, protože ta se jednoduše spoléhá na existující třídy členství. (Mezi interní reprezentaci uživatele a třídu MembershipUser pak začleníte nějakou mapovací logiku, což je věc, která půjde poměrně snadno.) Celkový návrh řešení vlastního zprostředkovatele ilustruje obrázek 26-2.

Obrázek 26-2. Návrh řešení vlastního zprostředkovatele.

Jak už bylo zmíněno, třídy SimpleUser a SimpleRole jsou právě těmi třídami, které umožňují serializaci XML. Ačkoliv pro podporu MembershipUser je potřebná určitá mapovací logika, celkový proces imple-mentace toto velmi usnadňuje. UserStore a RoleStore jsou obě utilitní třídy, které slouží pro zapouzdření přístupu k souboru XML. Tyto třídy zahrnují nejenom funkce pro načítání a ukládání souborů XML, ale také i některé základní utilitní funkce pro vyhledávání informací v úložišti.

A konečně – model obsahuje třídy XmlMembershipProvider a XmlRoleProvider. Třída XmlMember-shipProvider dědí základní funkčnost z MembershipProvider. Třída XmlRoleProvider je pak zděděna z RoleProvider. Obě tyto třídy jsou definovány ve jmenném prostoru System.Web.Security.

Návrh a implementace vlastního úložištěPo dokončení návrhu celkové architektury můžete začít přemýšlet nad podkladovým úložištěm dat. V této naší ukázce se bude datové úložiště skládat z jednoho souboru XML, který bude určen pro uživatele, a dalšího souboru XML určeného pro role. Aby přístup k těmto souborům byl co nejjednodušší, budeme jako primární mechanismus pro jejich čtení a zápis do nich používat serializaci XML. K tomu budeme potřebovat několik tříd, které budou data uložená v souborech XML uchovávat buď jako veřejná pole, nebo jako vlastnosti:

public class SimpleUser

{


public Guid UserKey = Guid.Empty;

public string UserName = "";

public string Password = "";

public string Email = "";

public DateTime CreationDate = DateTime.Now;

public DateTime LastActivityDate = DateTime.MinValue;

public DateTime LastLoginDate = DateTime.MinValue;

public DateTime LastPasswordChangeDate = DateTime.MinValue;

public string PasswordQuestion = "";

public string PasswordAnswer = "";

public string Comment;

}

public class SimpleRole

{

public string RoleName = "";

public System.Collections.Specialized.StringCollection AssignedUsers

= new System.Collections.Specialized.StringCollection();

}

V této ukázce použijete identifikátor GUID jako ProviderUserKey pro jednoznačnou identifikaci uživatelů v úložišti (což se trochu podobá primárnímu klíči, který je používán pro unikátní identifikaci záznamů v da-tabázové tabulce). Pro každého uživatele budete ukládat uživatelské jméno, hašované heslo, e-mailovou adre-su, nějaké informace vztahující se k datu, kontrolní otázku k zapomenutému heslu (a odpověď na ni) a také několik komentářů. U rolí budete ukládat název role a její asociaci s uživateli. Pro zjednodušení bude každá role obsahovat pole uživatelských jmen (což bude řetězec), která jsou asociována s touto rolí. Serializovaná verze pole uživatelů bude sloužit jako úložiště uživatelů. Serializovaná verze pole rolí pak bude sloužit jako úložiště rolí, viz obrázek 26-3.

Připomínáme, že obrázek 26-3 ukazuje serializovanou verzi uživatelů a rolí z již dokončené verze zprostřed-kovatele, kterého právě nyní vyvíjíme. Jak uvidíte v této kapitole později, v tomto zprostředkovateli budeme používat tzv. osolená hašovaná hesla (což jsou hesla, která jsou doplněna o hodnotu "salt"). Kromě toho se možná nyní ptáte, proč do souboru XML nebyly serializovány žádné komentáře. Je to proto, že XmlSeria-lizer serializuje pole pouze tehdy, pokud obsahují něco jiného než null (pokud chcete, aby se choval jinak, je možné to specifikovat prostřednictvím atributů XmlSerializer, které aplikujete na vlastnosti vaší třídy).

Existuje ovšem ještě jeden aspekt našeho návrhu, o kterém musíte uvažovat – jak budete k úložišti přistu-povat? Pro každé úložiště stačí mít v paměti pouze jednu instanci každé úložné třídy (UserStore a Role-Store), abyste ušetřili zdroje a vyhnuli se příliš častému načítání souborů XML. To se dá implementovat prostřednictvím vzoru Singleton, což je řešení, které zajišťuje přítomnost pouze jediné instance třídy v rámci procesu. Udělá se to tak, že konstruktor se změní na privátní, přičemž poskytne veřejnou statickou metodu pro získání instance. Tato veřejná metoda ověří, zdali tato instance už existuje. Pokud neexistuje, sama auto-maticky vytvoří novou instanci, kterou poté vrátí. Možná se nyní ptáte, proč jednoduše nepoužijeme nějakou statickou třídu se spoustou statických metod a členů. Když se ovšem podíváte na následující fragment kódu, nepochybně zjistíte, že informace úložiště jsou udržovány v paměti, čímž vlastně podporujete možnost simul-tánně otevírat více izolovaných úložišť, aniž byste museli pokaždé znovu načítat soubory XML. Tato logika je zapouzdřena prostřednictvím implementace vzoru Singleton vašich úložných tříd. V následujícím fragmentu kódu se pro každé úložiště v podobě XML souboru (například pro sadu uživatelů) udržuje v paměti pouze jediná instance UserStore, která zapouzdřuje izolovaný přístup k jednomu úložišti (přičemž stejná logika se


uplatňuje i na RoleStore pro role). Přestože tuto funkcionalitu v našem právě vytvářeném zprostředkovateli nepoužíváme, může to být velmi zajímavý vzor pro jiné scénáře.

Obrázek 26-3. Serializované verze polí SimpleUser a SimpleRole.

Prozkoumejme nyní všechny aspekty třídy UserStore, která byla představena na obrázku 26-3.

public class UserStore

{

private string _FileName;

private List<SimpleUser> _Users;

private XmlSerializer _Serializer;

private static Dictionary<string, UserStore> _RegisteredStores;

private UserStore(string fileName) private UserStore(string fileName)

{

_FileName = fileName;

_Users = new List<SimpleUser>();

_Serializer = new XmlSerializer(typeof(List<SimpleUser>));


LoadStore(_FileName);

} }

public static UserStore GetStore(string fileName) public static UserStore GetStore(string fileName)

{

// Vytvoří registrované úložiště, pokud ještě neexistuje

if (_RegisteredStores == null)

_RegisteredStores = new Dictionary<string, UserStore>();

// Vrátí příslušné úložiště, podle předaného názvu souboru

if (!_RegisteredStores.ContainsKey(fileName))

{

_RegisteredStores.Add(fileName, new UserStore(fileName));

}

return _RegisteredStores[fileName];

} }

}

Třída obsahuje několik privátních členů pro název souboru úložiště, seznam uživatelů a instanci XmlSeria-lizer používanou pro čtení a zápis dat.

Instance nemohou být vytvářeny mimo rámec třídy, protože konstruktor je privátní. Mimo třídy můžete in-stance opětovně získat pouze tak, že zavoláte veřejnou statickou metodu GetStore(). Implementace vzoru Singleton je v tomto případě ojedinělá. Vytváří jediné instance, které jsou založeny na názvech souborů. Pro každý soubor zpracovaný zprostředkovatelem se vytvoří jedna instance třídy UserStore. Pokud v rámci stej-ného procesu běží více webových aplikací, které používají tohoto zprostředkovatele, musíte zajistit, aby se pro různé názvy souborů vytvářely různé instance. Z tohoto důvodu třída nespravuje jednu statickou proměnnou pro jedinou instanci – má slovník (dictionary), který obsahuje všechny instance třídy (pro každý název sou-boru jednu).

Protože pro ukládání dat do úložiště a pro načítání dat z úložiště používáte serializaci XML, jsou funkce pro načítání úložiště a ukládání dat zpět do úložiště poměrně jednoduché:

private void LoadStore(string fileName)

{

try

{

// Připomínáme, že pokud soubor neexistuje, v tomto okamžiku

// to ignorujeme. Při ukládací operaci bude úložný soubor

// automaticky vytvořen implementací úložiště

if (System.IO.File.Exists(fileName))

{


{

_Users = (List<SimpleUser>)_Serializer.Deserialize(reader);

}

}


}

catch (Exception ex)

{

throw new Exception(string.Format("Nelze načíst soubor {0}", fileName), ex);

}

}

private void SaveStore(string fileName)

{

try

{


System.IO.File.Delete(fileName);

using (XmlTextWriter writer = new XmlTextWriter(fileName, System.Text.

Encoding.UTF8))

{

_Serializer.Serialize(writer, _Users);

}

}

catch (Exception ex)

{

throw new Exception(string.Format("Nelze uložit soubor {0}", fileName), ex);

}

}

Obě metody jsou privátní, neboť jsou volány pouze v rámci samotné třídy. Metoda LoadStore() se volá v rámci konstruktoru třídy UserStore(). Uvnitř této metody se inicializuje privátní proměnná _Users. Každý následný dotaz bude založen na dotazování se kolekce _Users třídy úložiště. Metoda SaveStore() oproti tomu pouze serializuje kolekci _Users do souboru specifikovaného v privátním členu _FileName, který se předává prostřednictvím konstruktoru (a nepřímo statickou metodou GetStore()). A konečně, třída podporuje několik metod pro dotazování se na informace v kolekci _Users.

public List<SimpleUser> Users

{

get { return _Users; }

}

public void Save()

{

SaveStore(_FileName);

}

public SimpleUser GetUserByName(string name)

{

return _Users.Find(delegate(SimpleUser user)

{


return string.Equals(name, user.UserName);

});

}

public SimpleUser GetUserByEmail(string email)

{


{

return string.Equals(email, user.Email);

});

}

public SimpleUser GetUserByKey(Guid key)

{


{

return (user.UserKey.CompareTo(key) == 0);

});

}

Users je jednoduchá vlastnost, která umožňuje aktuálnímu zprostředkovateli (XmlMembershipProvider) přistupovat k uživatelům v úložišti. Poté, co implementace zprostředkovatele něco změní v úložišti (například změní vlastnosti uživatele), zavolá veřejnou metodu Save(), která interně volá metodu SaveStore(), aby se informace serializovaly zpět do souboru specifikovaného v privátní proměnné _FileName této instance. Zbývající metody jsou určeny pro vyhledávání uživatelů podle různých kritérií. Obecně použitelný List<> obsahuje pro tento účel vyhledávací metodu. Tato metoda akceptuje referenci na další (porovnávací) metodu, která je volána pro každý prvek, zatímco probíhá iterace napříč seznamem. Pokud porovnávací funkce vrátí pro daný prvek hodnotu true, bude prvek zařazen do výsledků.

public SimpleUser GetUserByKey(Guid key)

{


{

return (user.UserKey.CompareTo(key) == 0);

});

}

V tomto kódu předáváte delegáta (referenci na funkci), který porovnává interní klíč třídy SimpleUser s pře-daným klíčem. Pokud je výsledkem hodnota true, je aktuální uživatel, který byl předán ve formě parametru List<>, vrácen jako výsledek. V opačném případě List<> pokračuje v iteraci svých prvků. Inline implemen-taci této metody, bez explicitního vytváření metody se samostatným prototypem, se říká anonymní metoda. Je to speciální rys jazyka C# , jímž se dá zkrátit zápis parametrů algoritmu.

Třída UserStore obsahuje implementaci, která slouží jen pro ukládání uživatelských informací. Role v ní za-hrnuty nejsou. Za tímto účelem musíte implementovat třídu RoleStore (která se podobá třídě UserStore), jak to ostatně můžete vidět zde:

public class RoleStore

{


XmlSerializer _Serializer;

private string _FileName;

List<SimpleRole> _Roles;

#region "Implementace vzoru Singleton"

private static Dictionary<string, RoleStore> _RegisteredStores;

private RoleStore(string fileName)

{

_FileName = fileName;

_Roles = new List<SimpleRole>();

_Serializer = new XmlSerializer(typeof(List<SimpleRole>));

LoadStore(_FileName);

}

public static RoleStore GetStore(string fileName)

{

// Vytvoří registrované úložiště

if (_RegisteredStores == null)

_RegisteredStores = new Dictionary<string, RoleStore>();

// Nyní vrátí patřičné úložiště

if (!_RegisteredStores.ContainsKey(fileName))

{

_RegisteredStores.Add(fileName, new RoleStore(fileName));

}

return _RegisteredStores[fileName];

}

#endregion

#region "Privátní výpomocné metody"

private void LoadStore(string fileName)

{

try

{

// Opět vytvoříme úložiště automaticky při

// ukládání – viz metoda SaveStorage.


{


{

_Roles = (List<SimpleRole>)_Serializer.Deserialize(reader);

}

479

KAPITOLA 31Portály s webovými částmi

Weby jsou v současné době promyšlenější než kdykoliv předtím. Dnes již nestačí, aby web měl skvělý vzhled a ohromoval svými parádičkami. Uživatelé kladou stále větší důraz na to, aby se web dal snadno používat a aby hlavně přinášel přesně ty informace, které chtějí vidět – a to nejlépe na základě jejich individuálních preferencí. V oblasti vývoje webových stránek se proto dostaly do popředí takové prvky, jako jsou persona-lizace a profily uživatelů.

Uživatelé si ovšem chtějí individuálně přizpůsobit nejenom jednoduché informace profilu. Jakmile se přihlásí ke svému účtu, chtějí mít možnost si individuálně přizpůso-bit uživatelské rozhraní webu tak, aby vyhovovalo jejich požadavkům, přičemž koneč-ným cílem je, aby měli pohodlný přístup k těm informacím, které nutně potřebují při své každodenní práci (a to hned, jakmile se přihlásí). V této kapitole se proto dozvíte, jak lze prostřednictvím frameworku Web Parts ASP.NET a personalizačních funkcio-nalit vytvářet modulární a dynamicky konfigurovatelné webové stránky, které uspokojí všechny druhy těchto požadavků.

WEB PARTS KONTRA ASP.NET AJAX

Existuje jistý překryv s novou funkcionalitou přicházející s rozšířeními ASP.NET AJAX a Web Parts. Například ovládací prvek Accordion ("harmonika", najdete ho v ASP.NET Control Toolkit) umožňuje minimalizovat a obnovovat do původní velikosti části webové stránky velmi podobně jako framework Web Parts. Také ovládací prvek DragPanel umožňuje přemisťovat obsahové regiony s myší, podobně jako když se jedná o "pravé" webové části. Vyvstává tedy otázka: kdy bychom měli použít tu a kdy onu funkcionalitu?

Odpověď je prostá a jasná: stránky budované s Web Parts nepředstavují pouhý fragment funkcionality, jakou například zastupují ovládací prvky Accordion nebo DragPanel. Web Parts je kompletní framework určený pro personalizaci. Potřebujete-li při své práci úplný framework, pak byste měli používat Web Parts. Tato funkcionalita zahrnuje per-sonalizaci vzhledu stránky pro skupiny uživatelů i pro jednotlivé uživatele, personalizaci s vlastními nastaveními pro každý modul zapojený do webové aplikace, dynamickou roz-šiřitelnost s možností přidávat do webu nové moduly za běhu bez toho, aby byla nutná rekompilace a tak dále.

Pokračování na následující stránce...

480 Kapitola 31 – Portály s webovými částmi

... pokračování z předcházející stránky.

Potřebujete-li dohromady tohle všechno, webové části jsou pro vás tou správnou cestou. Potřebujete-li jen nějaký fragment funkcionality, třeba minimalizovat a obnovovat do původní velikosti části stránky nebo jen přetahovat obsah po ploše webové stránky, pak by mohl být framework Web Parts pro vaši aplikaci trochu kanónem na vrab-ce. V takovém případě bude možná lepší spokojit se s patřičným ovládacím prvkem ASP.NET AJAX. Obě technolo-gie ale můžete také zkombinovat, potřebujete-li je najednou. ASP.NET AJAX jsme probrali v kapitole 30.

Typické portálové stránkyJak jste se mohli dozvědět už dříve v kapitole 24, v personalizovaném prostředí uživatelé chtějí, aby v jejich profilu byly uloženy specifické informace. Dále chtějí mít možnost si individuálně přizpůsobit vzhled webu a většinu informací, které se v něm zobrazují.

Dobrým příkladem personalizovaného webu je MSN společnosti Microsoft. Jakmile se přihlásíte do MSN, můžete si nakonfigurovat informace, které se budou zobrazovat na vaší osobní domácí stránce. MSN vám například umožňuje zvolit typ informačních položek, které chcete vidět, přičemž tyto informace pak bude zobrazovat na stránce, jež je určena pouze vám, jak to ostatně vidíte na obrázku 31-1.

Obrázek 31-1. Web MSN – dobrý příklad personalizované domovské stránky.

Některé informační položky, ze kterých si můžete vybírat, jsou docela jednoduché, jako například položka Search (Hledat), jež je na obrázku 31-1 uvedena v pravém horním rohu. Další položky jsou už složitější, jako například ceny akcií, které jsou uvedeny v pravém dolním rohu. Zajímavé je, že máte k dispozici mnohem více možností než jen vybírat informační položky, které chcete zobrazovat. Můžete totiž rovněž určit, kde


na stránce budou požadované informace zobrazeny. To uděláte tak, že přímo ve webové stránce tyto infor-mační položky přetáhnete na požadovanou pozici. Když se odhlásíte a později opět přihlásíte, všechny změny, které jste provedli, zůstanou zachovány. Řečeno jinými slovy, vaše personalizovaná stránka bude vypadat přesně tak, jak jste ji opustili.

Tento typ stránek má předem určené obsahové oblasti, kde uživatel může přidávat nebo odebírat informační položky. Uživatel může vybírat tyto informační položky ze seznamu dostupných položek, což není nic více než opětovně použitelné prvky uživatelského rozhraní (neboli ovládací prvky v ASP.NET), které se přidávají do předem určených obsahových oblastí webové stránky. Portálová stránka má obvykle nadefinováno několik obsahových oblastí: hlavní oblast uprostřed stránky, která je určena pro zobrazování nejdůležitějších informa-cí, navigační oblast v levé (nebo pravé) sekci stránky a podle potřeby ještě další oblast (umístěna buď na levé, nebo pravé straně stránky), jež je vyhrazena drobným položkám (jako je například položka s počasím nebo nějaký seznam s důležitými odkazy). Většina webových stránek samozřejmě obsahuje záhlaví a zápatí, která můžete snadno vytvořit prostřednictvím vzoru stránek (master page).

Ve frameworku pro webové části ASP.NET (ASP.NET Web Parts Framework) si můžete snadno sami vytvořit individuálně přizpůsobitelné webové stránky. Tento framework se skládá z ovládacích prvků a komponent, které pro vás vykonávají následující činnosti:

• Definice individuálně přizpůsobitelných sekcí. Framework vám umožňuje strukturovat stránku a specifikovat její individuálně přizpůsobitelné sekce prostřednictvím zón (web part zones).

• Nabídka komponent pro výběr položek. Kromě individuálně přizpůsobitelných sekcí obsahuje framework i speciální sekce, které umožňují editovat vlastnosti informačních položek zobrazených na stránce nebo přidávat informační položky na stránku a odstraňovat je z ní.

• Přizpůsobení webové stránky. Jakmile je uživatel přihlášen do dané aplikace, může si individuálně přizpůsobit webovou stránku tak, že přetahuje položky zobrazené na stránce a upouští je do přizpů-sobitelných sekcí. Uživatel může dokonce obsah zavřít nebo minimalizovat, aby měl k dispozici více místa pro nějaký jiný (zajímavější) obsah.

• Uložení přizpůsobeného vzhledu. ASP.NET automaticky ukládá uživatelem personalizovaný vzhled webové stránky prostřednictvím své personalizační infrastruktury.

Stránka, která tento framework používá, se nazývá stránka s webovými částmi (web part page). Informačním položkám, které mohou být na takové stránce zobrazeny, se říká webové části (web parts). Tyto webové části nejsou v podstatě ničím jiným než ovládacími prvky. Pokud tedy chcete s frameworkem Web Parts vytvářet individuálně přizpůsobitelné stránky, musíte vědět, jakým způsobem propojit vaše vlastní ovládací prvky s dostupnými zabudovanými ovládacími prvky. Vše potřebné naleznete v této kapitole.

Základy stránek budovaných s Web PartsZe všeho nejdřív potřebujete vědět, jak vytvořit základ stránky s webovými částmi. V příštích oddílech zvlád-nete hlavní kroky potřebné pro vytvoření takové stránky. Pak se dozvíte, jak se vytvoří jednotlivé webové části, tedy informační položky, které mají přijít na stránku portálu.

Stránku portálu vytvářeného s Web Parts je potřeba zahájit těmito kroky: 1. Vytvořte návrh stránky. Vytvořte s Visual Studiem .NET jednoduchou ASP.NET stránku. Nepotře-

bujete žádný speciální typ stránky – pouze běžnou .aspx stránku. Než budete pokračovat, vytvoř-te layout stránky prostřednictvím HTML tabulek tak, aby stránka obsahovala například navigační

Kapitola 31 – Portály s webovými částmi482

oblast, hlavní oblast a nějaký postranní panel pro dodatečné informace (aby se alespoň trochu podo-bala stránce MSN zobrazené na obrázku 31-1). Tato stránka může posloužit jako vzor stránek, který bude zajišťovat, aby všechny ostatní stránky měly stejný vzhled.

2. Přidejte ovládací prvek WebPartManager. Do stránky přidejte ovládací prvek WebPartManager. Je k dispozici v toolboxu na záložce Web Parts Visual Studia, jakmile otevřete vizuálního návrháře webo-vých stránek ASP.NET. Je to neviditelný ovládací prvek, který ví všechno o dostupných webových čás-tech na stránce a spravuje personalizaci. Prvek WebPartManager musí být prvním ovládacím prvkem vytvořeným na stránce s webovými částmi, protože na něm závisejí všechny ostatní ovládací prvky, které jsou asociovány s webovými částmi.

3. Přidejte ovládací prvky WebPartZone. Každá sekce stránky, která by měla zobrazovat vaše vlastní webové části, musí být zapouzdřena do instance ovládacího prvku WebPartZone. Přidejte proto ovlá-dací prvek WebPartZone do každé sekce webové stránky, která by měla obsahovat webové části a jež by měla být individuálně přizpůsobitelná.

4. Přidejte webové části. Můžete použít jednoduché uživatelské ovládací prvky, již hotové uživatelské ovládací prvky, vlastní serverové ovládací prvky nebo ovládací prvky, které jsou přímo zděděny ze zá-kladní třídy WebPart. Všechny tyto ovládací prvky můžete umístit do zóny webové části prostřednic-tvím návrháře Visual Studia nebo ručním napsáním kódu. Zbytek už zařídí automaticky infrastruktura ASP.NET.

5. Přidejte zabudované zóny a části. Jestliže chce uživatel při běhu stránky přidávat či odstraňovat we-bové části nebo editovat jejich vlastnosti, musíte do webové stránky přidat zabudované zóny, jako je například CatalogZone, která uživateli povoluje přidávat na stránku webové části.

Jakmile dokončíte všechny tyto kroky, bude stránka s webovými částmi připravena k použití. Nesmíte za-pomenout vložit do vaší aplikace nějaké ověřování identity ( ověřování systému Windows nebo ověřování založené na formulářích), aby framework mohl uchovávat personalizované informace jednotlivých uživatelů. Tyto informace se standardně ukládají do databázového souboru ASPNETDB.MDF, který se vytvoří automa-ticky v adresáři App_Data (za předpokladu, že máte nainstalován SQL Server Express). V opačném případě musíte vytvořit databázi v plné verzi SQL Serveru prostřednictvím utility aspnet_regsql.exe, jak se po-pisuje v kapitole 21 (personalizační informace jsou uloženy ve stejné databázi jako uživatelské informace). A samozřejmě, jako u libovolné jiné části frameworku (včetně API členství a API rolí) i zde může váš vlastní zprostředkovatel nahradit personalizační infrastrukturu za jinou, aniž by jakkoliv ovlivnil samotnou aplikaci.

Vytvoření návrhu stránkyPrvním krokem při vytváření stránky s webovými částmi je vytvořit ve vašem řešení novou .aspx stránku. Nemusíte přidávat žádnou speciální položku – do projektu jednoduše přidejte webový formulář. Poté můžete libovolně strukturovat základní layout stránky.

V následujícím příkladu se prostřednictvím HTML tabulky rozdělí stránka na hlavní centrální oblast, konfi-gurační oblast vlevo a jednoduchou informační oblast vpravo:

<form id="form1" runat="server">

<div>

<table style="width: 100%">

<tr valign="middle" style="background: #00ccff">

<td colspan="2">


<span style="font-size: 16pt; font-family: Verdana">

<strong>Vítejte na stránkách s webovými částmi!</strong>

</span>

</td>

<td style="height: 22px">

Menu

</td>

</tr>

<tr valign="top">

<td style="width: 20%"></td>



</tr>

</table>

</div>

</form>

První řádek tabulky slouží jako záhlaví aplikace. Druhý řádek tabulky se dělí na tři sloupce. Levý bude použit jako sloupec pro konfigurační ovládací prvky (jako je například ovládací prvek pro výběr dostupných we-bových částí), střední sloupec bude použit pro zobrazení hlavních informací a konečně pravý sloupec bude použit pro malé webové části s dodatečnými informacemi. Povšimněte si, že první řádek současně obsahuje druhý sloupec, který je určen pro menu. Toto menu později použijete pro přepínání mezi jednotlivými režimy stránky (například mezi režimem procházení, Browse, jenž pouze zobrazuje informace, a režimem Design, který uživateli umožňuje přesouvat webové části z jedné zóny do jiné).

Layout této stránky vidíte na obrázku 31-2.

Obrázek 31-2. Základní layout stránky.


WebPartManager a WebPartZoneJakmile máte vytvořený layout webové stránky, můžete pokračovat přidáním prvních ovládacích prvků fra-meworku Web Parts na stránku. Tyto ovládací prvky jsou soustředěny v sekci WebParts toolboxu Visual Studia. V našem příkladu bude prvním ovládacím prvkem, který společně přidáme do horní části stránky, ovládací prvek WebPartManager. Tento prvek pracuje se všemi zónami přidanými do webové stránky a ví o všech webových částech, které jsou na stránce k dispozici. Kromě toho řídí personalizaci a zajišťuje, aby se webová stránka individuálně přizpůsobila aktuálně přihlášenému uživateli. Následující fragment kódu před-stavuje modifikovanou část kódu stránky:


<div>

<asp:WebPartManager runat="server" ID="MyPartManager" /><asp:WebPartManager runat="server" ID="MyPartManager" />


...

</table>

</div>

</form>

Prvek WebPartManager rovněž generuje události, které můžete zachytit v aplikaci, abyste vykonali patřičné akce, pokud uživatel přidá (nebo odstraní) nějakou webovou část nebo pokud webová část komunikuje s ji-nou webovou částí. O vzájemné komunikaci mezi webovými částmi se dozvíte později v sekci "Propojování webových částí" v této kapitole.

Poté, co jste na stránku přidali WebPartManager, můžete do webové stránky přidat individuálně přizpůso-bitelné sekce, kterým se říká zóny webové části (web part zones). Každá taková zóna může obsahovat tolik webových částí, kolik uživatel potřebuje. Po přidání zón webových částí vypadá kód stránky následovně:


<div>

<asp:WebPartManager runat="server" ID="MyPartManager" />



<td colspan="2">



</span>

</td>

<td style="height: 22px">Menu</td>

</tr>

<tr valign="top">

<td style="width: 20%">

<asp:CatalogZone ID="SimpleCatalog" runat="server"> <asp:CatalogZone ID="SimpleCatalog" runat="server">

</asp:CatalogZone> </asp:CatalogZone>

</td>


<asp:WebPartZone ID="MainZone" runat="server"> <asp:WebPartZone ID="MainZone" runat="server">

</asp:WebPartZone> </asp:WebPartZone>


</td>


<asp:WebPartZone ID="HelpZone" runat="server"> <asp:WebPartZone ID="HelpZone" runat="server">

</asp:WebPartZone> </asp:WebPartZone>

</td>

</tr>

</table>

</div>

</form>

Jak můžete nyní vidět, stránka obsahuje celkem tři zóny: dvě pro přidávání webových částí do stránky a jednu speciální zónu. Touto speciální zónou je CatalogZone, která zobrazí každou webovou část, jež je pro aktu-ální stránku k dispozici. Jinak řečeno – zobrazí seznam všech dostupných webových částí, přičemž umožňuje uživateli, aby si mohl vybrat požadované webové části z tohoto seznamu a přidat je na stránku. Efekt výše uvedeného kódu v návrháři je demonstrován na obrázku 31-3.

Obrázek 31-3. Stránka s ovládacími prvky webových částí v návrháři Visual Studia.

Přidávání webových částí na stránkuNyní můžete začít přidávat webové části na stránku. Webovou částí se v tomto kontextu myslí jakýkoliv ovlá-dací prvek ASP.NET. Můžete použít libovolný typ ovládacího prvku včetně existujících serverových ovlá-dacích prvků, existujících uživatelských ovládacích prvků a vlastních serverových ovládacích prvků, které jste vytvořili sami. Nemusíte implementovat žádná speciální rozhraní, pokud nepotřebujete interakci s in-frastrukturou webové části nebo s jinými webovými částmi na stránce. Do stránky budované s Web Parts se ovládací prvky přidávají stejně jednoduše jako na obyčejnou stránku. Jediný rozdíl je v tom, že ovládací prvky nepřidáváte přímo do stránky, ale do některé z předem přidaných zón. Pro tento účel používají zóny šablony. Koncepce šablon je stejná jako u ovládacích prvků s charakterem mřížky, kde můžete specifikovat šablonu, která je vytvořena pro každý řádek mřížky. Šablona definuje pouze vzhled webové části.


Existující serverové ovládací prvky se do zóny přidávají takto:

<asp:WebPartZone runat="server" ID="HelpZone">

<ZoneTemplate>

<asp:Calendar runat="server" ID="MyCalendar" />

<asp:FileUpload ID="FileUpload1" runat="server" />

</ZoneTemplate>

</asp:WebPartZone>

Předchozí výpis ukazuje zónu, kterou jste dříve v této kapitole vložili do pravé sekce stránky. Tato zóna nyní obsahuje dva ovládací prvky: standardní ovládací prvek Calendar a ovládací prvek FileUpload. Obrázek 31-4 zobrazuje tuto stránku v návrháři Visual Studia poté, co jste přidali šablonu této zóny.

Obrázek 31-4. Zóna webové části s přidanými ovládacími prvky.

Je samozřejmě možné vytvořit jeden nebo více uživatelských ovládacích prvků a přidat je do některé ze zón portálové stránky. Vytvořte například databázové tabulky, které jsou zobrazeny na obrázku 30-5, a přidejte do nich několik vyplněných testovacích záznamů tak, abyste mohli později tento testovací vzorek rozšiřo-vat. Tuto databázi si můžete v případě potřeby stáhnout, jedná se o databázový soubor pro SQL Server Ex-press, který je součástí příkladů Web Parts ASP.NET popisovaných v této kapitole. Naleznete ho v adresáři App_Data. Tento soubor můžete použít buď jako tréninkovou databázi nebo jej připojit k vaší instanci SQL Serveru. Možné jsou oba přístupy.

S využitím tabulky Customer (zákazník) si nyní ukážeme, jak vytvořit první webovou část. Do vašeho řešení přidejte nový uživatelský ovládací prvek (user control), otevřete databázi v okně průzkumníka serveru, pře-táhněte tabulku Customer z okna průzkumníka serveru a upusťte ji na vašem uživatelském ovládacím prvku ASP.NET. Návrhář automaticky vytvoří nejenom zdroj dat, ale také prvek GridView, který bude zobrazovat data. (Nenastavujte pro GridView automatický formát, protože i k tomuto dojde později zcela automaticky, na základě ovládacích prvků WebPartZone.)


Obrázek 31-5. Databázové tabulky použité pro naše ukázkové řešení.

Nyní můžete přidat nově vytvořený uživatelský ovládací prvek do hlavní zóny vaší webové stránky. To uděláte tak, že jej jednoduše přetáhnete z průzkumníka řešení do patřičné zóny. Návrhář nejprve vytvoří položky potřebné pro registraci ovládacího prvku ve stránce. Teprve pak přidá prvek do zóny (včetně značek <Zone-Template>, které budou obsahovat váš obsah pro zónu), jak vidíte zde:

<asp:WebPartZone runat="server" ID="MainZone">

<ZoneTemplate>

<uc1:Customers ID="MyCustomers" runat="server" />

</ZoneTemplate>

</asp:WebPartZone>

Nakonec můžete k již přidanému ovládacímu prvku CatalogZone přidat speciální webovou část. Protože tato zóna je určena pro zobrazování katalogů webových částí, můžete do ní přidávat pouze speciální ovládací prvky, jako je například prvek PageCatalogPart. Tyto speciální ovládací prvky přidáváte stejným způso-bem jako běžné ovládací prvky WebPartZone – tj. prostřednictvím ZoneTemplate.

<asp:CatalogZone runat="server" ID="SimpleCatalog">

<ZoneTemplate>

<asp:PageCatalogPart runat="server" ID="MyCatalog" />

</ZoneTemplate>

</asp:CatalogZone>

Než nastartujete vaši webovou aplikaci, můžete upřesnit automatický formát ovládacích prvků WebPartZo-ne, když otevřete inteligentní značku odpovídající zóny. Připomínáme, že v návrháři Visual Studia se tlačítka pro otevření inteligentní značky občas trochu překrývají. Proto postupujte opatrně, abyste opravdu vybrali inteligentní značky samotné zóny, nikoliv webové části, ve které je zóna obsažena. Nepochybně zjistíte, že for-mátování se automaticky uplatňuje na každý ovládací prvek, který je umístěn přímo do zóny. Dále si povšim-něte, že každá formátovací akce, kterou provedete na nějaké konkrétní webové části, překryje formátování, jež bylo nastaveno v zóně webové části. Aplikaci teď otestujte tak, že spustíte vytvořenou stránku s webovými částmi. Pak ji můžete začít ladit. Když spustíte stránku v řešení, měli byste vidět okno jako na obrázku 31-6 (v závislosti na tom, jaké jste specifikovali volby pro automatické formátování).


Obrázek 31-6. Stránka s webovými částmi v prohlížeči.

Povšimněte si, že každá webová část zobrazuje nejenom svůj titulek, ale také malou šipku pro minimalizaci, obnovu do původní velikosti a uzavření dané webové části. Webové části standardně zobrazují své výchozí titulky. Později v sekci "Přizpůsobení stránky" v této kapitole vám ukážeme, jak tyto titulky přizpůsobit.

Protože jste doposud nenastavili žádnou techniku pro ověřování identity, aplikace standardně používá ověřo-vání systému Windows. Proto si už nyní můžete tuto stránku s webovými částmi přizpůsobit (alespoň pokud jde o minimalizaci jednotlivých částí a jejich zavírání). Bez jakéhokoliv dalšího úsilí tohle platí i pro případ, budete-li ověřovat uživatele prostřednictvím ověřování založeného na formulářích (ať už s využitím API člen-ství, s nímž jste se seznámili v kapitole 21, nebo bez něj). Pořád ještě ovšem nemůžete jednotlivé webové části přesouvat z jedné zóny do jiné. Abyste tohle mohli dělat, budete se muset přepnout do speciálního režimu stránky, s nímž se seznámíte v příští sekci. Když zavřete okno prohlížeče a spustíte další relaci prohlížeče, bude mít stránka stejný layout, jako když jste ji naposled opustili. Je to proto, že prvek WebPartManager automa-ticky ukládá provedené změny do personalizačního úložiště.

Pokud jste nezměnili žádná konfigurační nastavení, provedené změny se standardně ukládají do databáze ASPNETDB.MDF na SQL Serveru Express, která je uložena v adresáři App_Data. Toto výchozí chování může-te změnit, když si databázi vytvoříte na nějakém jiném serveru prostřednictvím nástroje aspnet_regsql.exe. Tento nástroj ovšem funguje pouze s SQL Serverem, takže v případě jiných databází si musíte vytvořit nějakého vlastního zprostředkovatele. Zprostředkovatele této databáze můžete nakonfigurovat prostřednic-tvím souboru web.config následovně:

<webParts>

<personalization defaultProvider="MyProvider">

<providers>

<add name="MyProvider"

type="System.Web.UI.WebControls.WebParts.SqlPersonalizationProvider"

connectionStringName="CustomSqlConnection" />

</providers>

</personalization>

</webParts>


Do sekce <connectionStrings> konfiguračního souboru musíte přidat připojovací řetězec (v tomto přípa-dě CustomSqlConnection), který musí ukazovat na databázi vytvořenou s aspnet_regsql.exe.

Přizpůsobení stránkyV našem příkladu už můžeme jistým způsobem přizpůsobovat některé části stránky s webovými částmi. Můžete například minimalizovat a obnovovat webové části. Můžete je také zavírat. Ovšem jednou již zavřené webové části není možné opětovně přidat na stránku, protože prvky CatalogZone a PageCatalogPart nejsou automaticky zobrazovány. Dále nemáte možnost změnit pozici webových částí jejich jednoduchým přetažením z jedné zóny do jiné.

Tak je tomu z toho důvodu, že naše ukázková stránka s webovými částmi podporuje několik zobrazovacích režimů. Jinak řečeno – abyste mohli změnit pozici webové části výše popsaným způsobem, musíte se nacházet v patřičném režimu, který vám to umožní. Zobrazovací režimy můžete konfigurovat prostřednictvím vlast-nosti DisplayMode ovládacího prvku WebPartManager. Zobrazovací režimy, které jsou k dispozici jakožto statické vlastnosti třídy WebPartManager, jsou uvedeny v tabulce 31-1.

Tabulka 31-1. Zobrazovací režimy pro stránku s webovými částmi.

Režim Popis

BrowseDisplayMode Toto je výchozí režim, který se používá pro zobrazení obsahu stránky s webo-vými částmi.

DesignDisplayMode Tento režim umožňuje uživateli měnit pozice webových částí přetahováním.

CatalogDisplayMode Je-li aktivní, zobrazí WebPartManager katalog s webovými částmi, takže uži-vatel z nich může vybírat a přidávat je na stránku.

ConnectDisplayMode Je-li aktivní, uživatel může konfigurovat připojení mezi webovými částmi, které lze propojovat (více se o nich dozvíte později v tomto oddílu).

EditDisplayMode Umožňuje uživateli editovat vlastnosti webové části. Tento režim zobrazí editor webových částí. Ovládací prvek EditorZone je jednou ze zabudovaných zón webové části, která umožňuje zobrazit ovládací prvky editoru webové části, takže uživatel může modifikovat nastavení webové části).

Do druhé buňky prvního řádku tabulky, která vytváří základní layout naší stránky, přidejte nyní ovládací prvek Menu, jak to vidíte zde:



<td colspan="2">



</span>

</td>

<td style="height: 22px">

<asp:Menu ID="PartsMenu" runat="server" <asp:Menu ID="PartsMenu" runat="server"

OnMenuItemClick="PartsMenu_MenuItemClick"> OnMenuItemClick="PartsMenu_MenuItemClick">

</asp:Menu> </asp:Menu>

TVORBA DYNAMICKÝCH STRÁNEK PROFESIONÁLN

KNIHA

2

TVOR

BA DYN

AMICKÝ

CH STR

ÁNEK PROFESION

ÁLN

ASP.NET 4 a C# 2010

ASP.NET 4 a C# 2010

M a t t h e w M a c D o n a l d A d a m F r e e m a n

M a r i o S z p u s z t a9 7 8 8 0 7 4 1 3 1 4 5 5

ISBN 978-80-7413-145-5KATALOGOVÉ ČÍSLO: ZR1004DOPORUČENÁ CENA: 699 KČ

ASP.NET 4 a C# 2010 TVORBA DYNAMICKÝCH STRÁNEK PROFESIONÁLNĚ

Matthew MacDonald, Adam Freeman, Mario Szpuszta

E N C Y K L O P E D I E Z O N E R P R E S S

Pod tímto logem vycházejí publikace určené pro každého vážného zájemce o prá-ci s počítačem. Od ryze praktických příruček a průvodců až po komplexní publi-kace o všem, co potřebuje grafi k, webdesignér, vývojář či programátor při každo-denní práci. Na slevy, které můžete získat, a vydavatelský plán, v němž vedle knih domácích odborníků najdete celou řadu titulů světově uznávaných autorů, se informujte na adrese vydavatelství.

ASP.NET je výkonná technologie Microsoftu určená pro vytváření webových apli-kací běžících na straně serveru. Prostřednictvím této rozsáhlé publikace, která byla z praktických důvodů rozdělena do dvou samostatných knih, se můžete naučit všechno, co potřebujete ke zvládnutí ASP.NET 4 a C# 2010. Pokud jste již někdy předtím programovali v předchozí verzi ASP.NET, můžete se zaměřit pou-ze na některé (pro vás důležité) části nebo na nové funkce, například ASP.NET MVC, Silverlight či ASP.NET Dynamic Data, které jsou obsahem KNIHY 2. Pokud jste nikdy v ASP.NET neprogramovali, KNIHA 1 vám nabízí vhodné tempo výuky umožňující v krátkém čase projít všechny základní věci, které potřebujete znát v každodenní vývojářské praxi. Publikace, na které se podíleli tři zkušení autoři (Matthew MacDonald, Adam Freeman a Mario Szpuszta), obsahuje spoustu prak-tických příkladů a technik z reálného světa.

ASP.NET 4 a C# 2010, kniha 1 zahrnuje následující témata: Základy ASP.NET (úvod do ASP.NET, Visual Studio, webové formuláře, servero-

vé ovládací prvky, aplikace ASP.NET, správa stavu). Přístup k datům (základy ADO.NET, datové komponenty a sada dat, vázání dat,

bohatě vybavené datové ovládací prvky, cachování a asynchronní stránky, soubory a proudy, LINQ, XML).

Budování webů ASP.NET (uživatelské ovládací prvky, motivy a vzory stránek, navigace po webu, nasazování webů).

ASP.NET 4 a C# 2010, kniha 2 těsně navazuje na knihu 1 a popisuje: Bezpečnost (bezpečnostní model ASP.NET, ověřování založené na formulářích,

členství, ověřování systému Windows, autorizace a role, profi ly, kryptografi e, vlastní zprostředkovatelé členství).

Pokročilé uživatelské rozhraní (vlastní serverové ovládací prvky, grafi ky, GDI+ a grafy, JavaScript a techniky Ajaxu, portály s webovými částmi, ASP.NET AJAX).

Nové směry (MCV, systém dynamických dat ASP.NET, Silverlight).

© F

oto:

Len

ka K

řížov

á

www.zoner.cz

ZONER software, a.s. významný producent softwaru v oblasti digitální fotogra e,

po íta ové gra ky a multimédií, poskytovatel internetových

služeb, souvisejících s prezentací na internetu a e-komercí,

a nakladatelství odborné literatury.

Bonusové kapitoly ke stažení:http://www.zonerpress.cz/download/bonusove-kapitoly-aspnet.zip

Zdrojové soubory ke stažení:http://zonerpress.cz/download/aspnet4-a-c2010.zip

ZONER software, a.s., Nové sady 18, 602 00 Brno

Zoner Presstel.: 532 190 883e-mail: [email protected]

KNIHA 2 KNIHA 2

ASP.NET 4 a C# 2010 - tvorba dynamických stránek profesionálně - KNIHA 2

Documents

Transcript of ASP.NET 4 a C# 2010 - tvorba dynamických stránek profesionálně - KNIHA 2