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

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

KNIHA 2

Matthew MacDonald Adam Freeman Mario Szpuszta

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

Matthew MacDonald, Adam Freeman, Mario Szpuszta

Pro ASP.NET in C# 2010, Fourth Edition Matthew 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 2 Autor: Matthew MacDonald, Adam Freeman, Mario Szpuszta Copyright © ZONER software, a.s. Vydání první v roce 2011. Všechna práva vyhrazena.

Zoner Press Katalogové čí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án DTP: 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 distribuová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 software, a.s Nové sady 18, 602 00 Brno tel.: 532 190 883 e-mail: knihy@zoner.cz 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

Profily

173

Kapitola 25

Kryptografie

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

Grafiky, 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

4

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

23

Bezpečnostní model ASP.NET

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

Certifikáty

31

Co je SSL

32

Konfigurace SSL na IIS 7.x

33

Shrnutí

Kapitola 20

36

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

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

37 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 Konfigurace ověřování založeného na formulářích

43 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

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

67

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

68

Konfigurace připojovacího řetězce a zprostředkovatele členství

74

Vytváření a ověřování uživatelů Práce s ovládacími prvky pro bezpečnost Ovládací prvek Login

77 79 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

Konfigurace členství v IIS 7.x

104

Konfigurace 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í

Kapitola 22

114

Ověřování systému Windows

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

115 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 Konfigurace IIS 7.x

123 124

Konfigurace 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

Konfigurované zosobnění

138

Programátorské zosobnění

138

Shrnutí

Kapitola 23

142

Autorizace a role

Autorizace URL

143 143

Autorizační pravidla

144

Souborová autorizace

150

Autorizační kontroly v kódu

151

Metoda IsInRole() Třída PrincipalPermission Autorizace založená na rolích s API rolí

151 152 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 Autorizace s ASP.NET Roles v IIS 7.x Správa ASP.NET Roles s IIS 7.x Shrnutí

Kapitola 24

166 168 171 172

Profily

Co je profil

173 173

Představení profilů

174

Jak profily ukládají data

175

8 Profily a ověřování

176

Profily versus vlastní datové komponenty

176

Zprostředkovatel SqlProfileProvider

177

Vytvoření tabulek pro profily

177

Konfigurace zprostředkovatele

179

Definování vlastností profilu

180

Použití vlastností profilu

181

Serializace profilu

183

Skupiny profilu

185

Profily a vlastní datové typy

186

API pro profily

189

Anonymní profily

192

Vlastní zprostředkovatelé profilu

195

Třídy vlastního zprostředkovatele profilu

195

Návrh zprostředkovatele FactoredProfileProvider

197

Naprogramování FactoredProfileProvider

198

Testování FactoredProfileProvider

203

Shrnutí

Kapitola 25

206

Kryptografie

Šifrování dat: diskrétnost

207 207

Jmenný prostor .NET pro kryptografii

208

Úvod do kryptografický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í Kapitola 27

Vlastní serverové ovládací prvky

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

277 279 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 Rozšiřování existujících webových ovládacích prvků

304 306

Složené ovládací prvky

306

Odvozené ovládací prvky

309

Shrnutí

Kapitola 28

312

Grafiky, GDI+ a grafy

Ovládací prvek ImageMap

313 313

10 Vytváření aktivních oblastí

314

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

315

Vlastní aktivní oblast Kreslení s GDI+

317 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é grafiky 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í

Kapitola 29

354

JavaScript a techniky Ajax

Základy JavaScriptu

355 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 Vytvoření stránkového procesoru v JavaScriptu

365 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ů Vložené rámce Úvod do technologie Ajax

389 391 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 Shrnutí

Kapitola 30

407 412

ASP.NET AJAX

Úvod do ASP.NET AJAX

413 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 Hlubší pohled na klientské knihovny

446 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í

Kapitola 31

477

Portály s webovými částmi

Typické portálové stránky

479 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 Kapitola 32

539

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

Modifikace souboru Site.Master

550

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

550

Konfigurace 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

Modifikace zobrazení

559

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

561

13 Přidávání do modelu, modifikace 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í

Kapitola 33

578

Dynamická data

Vytvoření aplikace dynamických dat

579 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í Shrnutí

Kapitola 34

611 616

Silverlight

Co je Silverlight

617 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

Definice 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

Konfigurace URL webové služby

666

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

666

Shrnutí

Rejstřík

668

669

15

O autorech MATTHEW MACDONALD je autor, pedagog a Microsoft MVP. Přispívá do časopisů o programování a je autorem více než tuctu knih o programování .NET, napří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.

MARIO SZPUSZTA pracuje jako architekt ve skupině Developer and Platform Group společnosti Microsoft v Rakousku a pomáhá softwarovým architektům největších podniků a webovým zákazníkům se zaváděním nových technologií Microsoftu. 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 technického obsahu TechEd Europe Developers.

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 (chief operating officer) v jisté bankovní společnosti s celosvětovou působností.

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

O odborných korektorech Fabio 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 Developer) 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 vydá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

Úvod Když 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é formulář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 souvisejí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 nejkompletnější platformou pro vývoj webu, která kdy byla sestavena. Převyšuje svého předchůdce ASP, které 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 webový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ředchozí 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í knihy Vydavatelství 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 zakoupení 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, konfiguraci 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 architekturu 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 softwaru, 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ě inovativní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 podí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 formuláří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živatele 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 adresy. 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 budeme 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). Nakonec 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 webové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 skuteč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 webový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 objektově 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, napří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ázor Jako č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 publikovat, 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: miroslav.kucera@zoner.cz nebo knihy@zoner.cz.

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

Zdrojové kódy Zdrojové 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é kapitoly K 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 kapitol 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 lokalizace 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.

20

21

ČÁST IV Bezpečnost 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ávají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čnostní 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živatele 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ýkonné, 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 zabezpeč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žňujícího nedovolenou manipulaci.

22

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žena 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í implementovat 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 softwaru I 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í architektuře a návrhu – je pak vůbec možné korektně (a v pravý čas) používat všechny zabezpeč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.

24

Kapitola 19 – Bezpečnostní model ASP.NET

Potenciální hrozby Př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ávné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řazuje 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í technologií. 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 kontrole 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čujeme, 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 Howarda 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, testová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, Second 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 Michaela 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ý webový 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 interní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 zobrazení (popsali jsme je v kapitole 6) pomůže ochránit jen takové informace, které jsou cenné jen nedlouhou 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é aplikace 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í

26

Kapitola 19 – Bezpečnostní model ASP.NET

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 zpracovatelské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, pokud 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šlenku. Tímto způsobem lze zabezpečit i obchodní vrstvu. Tento mechanismus rovněž používá aplikační infrastruktura ASP.NET. ASP.NET obsahuje několik strážných, kteří jsou použiti pro vynucování několika bezpeč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čnosti Pro 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 citlivý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ěřovací 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 skupiná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 definová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 Windows Ověř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řihlaš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živateli 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.

116

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

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. Nejvě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 nastavení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.

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

117

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ěřujete, nemají platné účty Windows. U veřejně přístupných webů tuto překážku prakticky nelze odstranit. I kdyby 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živatelů, 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 kontrolu nad ověřovacím procesem. Nelze tedy jednoduše programově přidávat, odstraňovat a spravovat informace 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 Windows Pokud implementujete ověřování systému Windows, IIS použije jednu ze tří ověřovacích strategií, s jejíž pomocí 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é funguje 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.

118

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

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č zobrazí 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řihlaš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 Digest Tento typ ověřování (stejně jako základní ověření) vyžaduje od uživatele, aby zadal informace do přihlašovací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á).

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

119

3. Klient pro vytvoření haše použije toto příležitostné slovo, heslo, uživatelské jméno a některé další hodnoty. 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áhodné 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 Windows Tato 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 stejné lokální síti nebo intranetu, neboť tato metoda de facto nepřenáší údaje obsahující uživatelská jména a hesla. 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 NTLM Ověř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č-

120

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

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 komunikovat. 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živatelský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živatele nebo doménového uživatele, se validace uskutečňuje buď místně, nebo vzdáleně na doménovém kontrolé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šifrovanou 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 26 Vlastní 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 implementovat 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 kapitolá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 nahradit 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í vlastní 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ěřová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 zprostředkovatelů byste vždy měli mít před očima jejich architekturu, která je znázorněna

240

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

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ší rozhraní 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-

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

241

bízí přístup ke klíči, který jednoznačně identifikuje uživatele v úložišti, doporučujeme, abyste přidali do databá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 členství. 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 ProviderUserKey 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 musíte implementovat poměrně dost metod a vlastností. V příštích oddílech vytvoříte vlastního zprostředkovatele č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 rysech Než 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); }

242

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

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 System.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 aplikaci, 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 implementace 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 XmlMembershipProvider 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 {

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

243

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 databázové tabulce). Pro každého uživatele budete ukládat uživatelské jméno, hašované heslo, e-mailovou adresu, 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ředkovatele, 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 XmlSerializer 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řistupovat? Pro každé úložiště stačí mít v paměti pouze jednu instanci každé úložné třídy (UserStore a RoleStore), 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 automaticky 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 simultá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

244

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

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) { _FileName = fileName; _Users = new List<SimpleUser>(); _Serializer = new XmlSerializer(typeof(List<SimpleUser>));

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

245

LoadStore(_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 XmlSerializer 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 instance 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 stejné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 souboru 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)) { using (XmlTextReader reader = new XmlTextReader(fileName)) { _Users = (List<SimpleUser>)_Serializer.Deserialize(reader); } }

246

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

} catch (Exception ex) { throw new Exception(string.Format("Nelze načíst soubor {0}", fileName), ex); } } private void SaveStore(string fileName) { try { if (System.IO.File.Exists(fileName)) 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) {

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

247

return string.Equals(name, user.UserName); }); } public SimpleUser GetUserByEmail(string email) { return _Users.Find(delegate(SimpleUser user) { return string.Equals(email, user.Email); }); } public SimpleUser GetUserByKey(Guid key) { return _Users.Find(delegate(SimpleUser user) { 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 _Users.Find(delegate(SimpleUser user) { 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ředaný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 implementaci 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í zahrnuty 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 {

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

248

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. if (System.IO.File.Exists(fileName)) { using (XmlTextReader reader = new XmlTextReader(fileName)) { _Roles = (List<SimpleRole>)_Serializer.Deserialize(reader); }

479

KAPITOLA 31 Portá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 personalizace 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ůsobit 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 funkcionalit 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 personalizaci 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 vrabce. V takovém případě bude možná lepší spokojit se s patřičným ovládacím prvkem ASP.NET AJAX. Obě technologie ale můžete také zkombinovat, potřebujete-li je najednou. ASP.NET AJAX jsme probrali v kapitole 30.

Typické portálové stránky Jak 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

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

481

na stránce budou požadované informace zobrazeny. To uděláte tak, že přímo ve webové stránce tyto informač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 informací, 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 Parts Ze 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ádnete 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řebujete žá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 částmi

482

oblast, hlavní oblast a nějaký postranní panel pro dodatečné informace (aby se alespoň trochu podobala 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 webových stránek ASP.NET. Je to neviditelný ovládací prvek, který ví všechno o dostupných webových částech 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řednictví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 webové čá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 zapomenout 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ří automaticky 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 popisuje 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ánky První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, konfigurač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">

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

483

<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> <td style="width: 60%"></td> <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 webový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.

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

484

WebPartManager a WebPartZone Jakmile máte vytvořený layout webové stránky, můžete pokračovat přidáním prvních ovládacích prvků frameworku 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ředstavuje modifikovanou část kódu stránky: <form id="form1" runat="server"> <div> <asp:WebPartManager runat="server" ID="MyPartManager" /> <table style="width: 100%"> ... </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 jinou 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ůsobitelné 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ě: <form id="form1" runat="server"> <div> <asp:WebPartManager runat="server" ID="MyPartManager" /> <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%"> <asp:CatalogZone ID="SimpleCatalog" runat="server"> </asp:CatalogZone> </td> <td style="width: 60%"> <asp:WebPartZone ID="MainZone" runat="server"> </asp:WebPartZone>

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

485

</td> <td style="width: 20%"> <asp:WebPartZone ID="HelpZone" runat="server"> </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ánku Nyní 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 infrastrukturou 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.

486

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

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řovat. Tuto databázi si můžete v případě potřeby stáhnout, jedná se o databázový soubor pro SQL Server Express, 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řetá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.)

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

487

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 <ZoneTemplate>, 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ůsobem 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ů WebPartZone, 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 formá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šimně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í).

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

488

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ěřová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 členství, 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 automaticky 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ůžete 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řednictví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>

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

489

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

Přizpůsobení stránky V 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 vlastnosti 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 webový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živatel 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: <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"> <asp:Menu ID="PartsMenu" runat="server" OnMenuItemClick="PartsMenu_MenuItemClick"> </asp:Menu>

Matthew MacDonald, Adam Freeman, Mario Szpuszta

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

KNIHA 2

ASP.NET je výkonná technologie Microsoftu určená pro vytváření webových aplikací 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 pouze 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 praktických příkladů a technik z reálného světa.

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.

ASP.NET 4 a C# 2010, kniha 1 zahrnuje následující témata: x Základy ASP.NET (úvod do ASP.NET, Visual Studio, webové formuláře, serverové ovládací prvky, aplikace ASP.NET, správa stavu). x 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). x 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: x 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, profily, kryptografie, vlastní zprostředkovatelé členství). x Pokročilé uživatelské rozhraní (vlastní serverové ovládací prvky, grafiky, GDI+ a grafy, JavaScript a techniky Ajaxu, portály s webovými částmi, ASP.NET AJAX). x Nové směry (MCV, systém dynamických dat ASP.NET, Silverlight).

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

www.zoner.cz

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

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í publikace o všem, co potřebuje grafik, webdesignér, vývojář či programátor při každodenní 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í.

Zoner Press tel.: 532 190 883 e-mail: knihy@zoner.cz www.zonerpress.cz ZONER software, a.s., Nové sady 18, 602 00 Brno

© Foto: Lenka Křížová

E N C Y K L O P E D I E

DOPORUČENÁ CENA: 699 KČ KATALOGOVÉ ČÍSLO: ZR1004

ISBN 978-80-7413-145-5

9 7 8 8 0 7 4 1 3 1 4 5 5