Eastgroup.pl

Tak jak wczoraj pisaliśmy, dzisiaj publikujemy dwadzieścia pytań związanych z egzaminami, do których w ciągu ostatnich trzech miesięcy publikowaliśmy artykuły przygotowujące. Pytania są zamknięte i pierwsza osoba, która w komentarzu (przypominamy o poprawnym podaniu adresu email, na który wyślemy vouchery) poda poprawną odpowiedz na wszystkie pytania otrzyma nagrodę voucher na egzamin oraz voucher na kurs e-learningowy ASP.NET 3.5. Poniżej lista pytań:

70-562 – ASP:

1. Masz DataSet zawierającego Customer DataTable oraz Order DataTable. Chcesz łatwo przechodzić z Order DataRow do Customer, który jest autorem zamówienia. Który obiekt umożliwi Ci łatwe przechodzenie z obiektów Order do obiektów Customer?
   

   A. DataColumn

   B. DataTable

   C. DataRow

   D. DataRelation

2. Która z poniższych metod klasy HttpServerUtility może zostać użyta to przejścia na inną stronę aplikacji bez przesyłania o tym informacji do klienta:
   

   A. Redirect

   B. MapPath

   C. Transfer

   D. UrlDecode

3. Potrzebujesz przechowywać dane, które są dostępne dla każdego użytkownika, który odwiedza Twoją stronę. Jakiej kolekcji powinieneś użyć w tym celu?
   

   A. Session

   B. Application

   C. Cookies

   D. ViewState

4. Co musisz dodać do connection stringa, aby umożliwić dostęp do danych asynchroniczny?
   

   A. BeginExecute=true

   B. MultiThreaded=true

   C. MultipleActiveResultSets=true

   D. Asynchronous Processing=true

5. Potrzebujesz generować dynamicznie dokumenty Worda, kiedy po aplikacji przychodzi żądanie pobrania pliku, którego rozszerzeniem jest .docx. Jak możesz to zrobić?
   

   A. Zaimplementować interfejs IPartitionResolver

   B. Zaimplementować interfejs IHttpModule

   C. Zaimplementować interfejs IHttpHandler

   D. Zaimplementować interfejs IHttpHandlerFactory

6. Której klasy użyjesz podczas konwersji między typami danych .NET Framework a typami XML?
   

   A. XmlType

   B. XmlCast

   C. XmlConvert

   D. XmlSettings

7. Tworzysz aplikację webową w ASP.NET w dziesiątkami stron wchodzących w jej skład. Chcesz zapisać preferencje użytkownika, tak aby można było się do tych informacji dostać z każdej strony. Dodatkowo chcesz, aby te ustawienia były zapamiętywany między kolejnymi wizytami użytkownika, nawet jak zamknie przeglądarkę. Który mechanizm zapamiętywania stanu po stronie klienta użyjesz?
   

   A. View state

   B. Control state

   C. Hidden fields

   D. Cookies

   E. Query strings

8. Jaki tym uwierzytelniania na poziomie aplikacji musicie skonfigurować, aby móc skorzystać z domyślnego membership providera – AspNetSqlMembershipProvider?
   

   A. Windows

   B. Forms

   C. Passport

   D. None

9. Potrzebujesz dynamicznie zmienić master page dla strony. W którym zdarzeniu strony to zrobisz?
   

   A. Page_Load

   B. Page_Render

   C. Page_PreRender

   D. Page_PreInit

10. Chcesz napisać serwis WCF, który będzie hostowany przez IIS. Który typ projektu powinieneś użyć?
    

    A. WCF Service library

    B. WCF Service application

    C. ASP.NET Web Service application

    D. Windows Service

70-503 – WCF:

1. Mamy klasę: 
   

   [ServiceBehavior()]

   public class ServiceImplementation : IServiceInterface

   {

       private int hitCounter;

       public void Increment()

       {

           hitCounter++;

       }

   }

   Jak należy udekorować klasę ServiceImplementation aby problemy współbieżności zostały wyeliminowane bez dodawania kodu w klasie? (Wybierz wszystkie poprawne odpowiedzi)

   A. ConcurrencyMode=Multiple i InstanceContextMode=Single

   B. ConcurrencyMode=Single i InstanceContextMode=PerSession

   C. ConcurrencyMode=Multiple i InstanceContextMode=PerSession

   D. ConcurrencyMode=Single i InstanceContextMode=Single

2. Który z poniższych punktów rozszerzenia (po stronie serwisu) musi być też zaimplementowany po stronie klienta?
   

   A. Message Inspection

   B. Message Formatting

   C. Parameter Inspection

   D. Operation Invoker

3. W obiekcie wiadomości właściwość MessageState jest ustawiona na Written. Które z poniższych zdarzeń zaszło?
   

   A. Metoda GetReaderAtBodyContents została wywołana.

   B. Metoda WriteBodyContents została wywołana.

   C. Metoda CreateBufferedCopy została wywołana.

   D. Metoda CreateMessage została wywołana.

4. Właśnie definiujesz nowy kontrakt serwisu. Które z poniższych reprezentują atrybuty z przestrzeni System.ServiceModel, które na pewno będą potrzebne?
   

   A. ServiceContractAttribute i FaultContractAttribute

   B. OperationContractAttribute i FaultContractAttribute

   C. ServiceContractAttribute i OperationContractAttribute

   D. OperationContractAttribute i MessageParameterAttribute

5. Będziesz obsługiwać serwis napisany w javie. Które z poniższych są poprawnymi metodami utworzenia proxy WCF do obsługi serwisu? (Wybierz wszystkie poprawne)
   

   A. Użyj klasy ChannelFactory class do utworzenia obiektu proxy dynamicznie.

   B. Użyj polecenia svcutil do utworzenia obieku proxy na podstawie definicji WSDL

   C. Ręcznie utwórz klasę proxy dziedziczącą po ClientBase.

   D. Dodaj referencję serwisu w Visual Studio (dodając referencję WSDL serwisu do projektu).

6. Potrzebujesz uruchomić serwis na serwerze IIS. Która wersja IIS obsługuje protokoły nie-HTTP?
   

   A. IIS 5.1

   B. IIS 6.0

   C. IIS 7.0

   D. Żadna z wersji IIS

7. Utworzyłeś aplikację kliencką WCF, która musi obsługiwać wywołanie zwrotne z serwisu. Który z bindingów użyjesz aby spełnić to wymaganie?
   

   A. basicHttpBinding

   B. wsHttpBinding

   C. wsHttpContextBinding

   D. wsDualHttpBinding

8. Utworzyłeś aplikację kliencką WCF, która musi obsługiwać wywołanie zwrotne z serwisu. Który z poniższych bindingów NIE wspiera tego wymagania?
   

   A. netTcpBinding

   B. netNamedPipeBinding

   C. netMsmqBinding

   D. netTcpContextBinding

9. Jaki będzie rezultat poniższego kodu?
   

   using (TransactionScope ts1 = new TransactionScope(

       TransactionScopeOption.Required, 

       new Timespan(0, 0, 30)))

   {

       using (TransactionScope ts2 = new TransactionScope(

           TransactionScopeOption.Required, 

           new Timespan(0, 0, 40)))

       {

           // Update database

           // Sleep for 35 seconds

           ts2.Complete();

       }

       ts1.Complete();

   }

   A. Obie transakcje zostaną zatwierdzone.

   B. Obie transakcje zostaną wycofane.

   C. Transakcja ts2 zostanie zatwierdzona a ts1 wycofana.

   D. Transakcja ts1 zostanie zatwierdzona, a ts2 wycofana.

10. Masz aplikację Windows Forms. W pojedynczej transakcji Twoja aplikacja musi zaktualizować dwie bazy Microsoft SQL Server. Który koordynator transakcji zarządza tymi transakcjami?
    

    A. Lightweight Transaction Manager

    B. Microsoft Distributed Transaction Controller

    C. Kernel Transaction Manager

    D. Web Services Transaction Manager

Powodzenia!

Tak jak zapowiadaliśmy wcześniej, mamy dla Was niespodziankę!

Mamy do rozdania kilka nagród:

• 2 vouchery na dowolny egzamin (ważne do 30 lipca 2010)
• 2 vouchery na kurs e-learningowy 6364: Visual Studio 2008 ASP.Net 3.5 (ważne do 30 czerwca 2010)

Chcieliśmy podziękować Olsztyńskiej Grupie IT za vouchery. Dzięki!!!

Konkurs na najlepszą “zajawkę”

Waszym zadaniem jest napisanie notki z linkami (70-536, 70-562, 70-503) do naszych kursów w jakimś blogu/serwisie. Najlepsza “zajawka” będzie nagrodzona: voucherem na egzamin, a kolejna voucherem na kurs e-learningowy.

Termin zgłaszania “zajawek” (termin wpisania linku do nich w komentarzach) godz. 12.00, poniedziałek 14 czerwca 2010 r!

Konkurs na najszybszego czytelnika

Jutro (piątek 11 czerwca 2010) o godzinie 12.00 pojawią się 20 pytania z zakresu przedstawianych przez nas kursów (dziesięć z WCF, dziesięć z ASP.NET).

Najszybsza osoba, która wpisze w komentarzu poprawne odpowiedzi na wszystkie pytania otrzyma voucher na egzamin i voucher na kurs e-learningowy.

Skrócony regulamin:

• nagrody nie podlegają wymianie na ich wartość pieniężną
• wszelkie konflikty rozwiązuje oraz “zajawki” ocenia komisja w składzie: Daniel Plawgo, Dawid Cieszyński, Kamil Lemański, Daniel Jarzynka, Dawid Tulski
• członkowie komisji nie mogą brać udziału w konkursach
• do komunikacji z zwycięzcami będzie użyty adres email pozostawiony w komentarzu

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

Często buforujemy dane na stronie bądź cała stronę co pozwala na szybszy dostęp do informacji niż z pliku czy bazy danych. Poprawia to oczywiście wydajność i skalowalność jeśli chodzi o liczbę użytkowników obsługiwanych na WWW. Nasz wspaniałomyślny ASP.NET bez większego nakładu pracy (czyt. pisania kodu) pozwala obsłużyć pamięć podręczną.  Wyróżniamy dwa rodzaje takiej pamięci:

Application caching- kolekcja ta może przechowywać dowolny obiekt, automatycznie zarządza pamięcią, limitami czasu przechowywania obiektu oraz innymi zależnościami.

Page output caching- pozwala przechowywać stronę, jej część lub wersje w pamięci co pozwala skrócić czas dostępu do niej.

Application Caching

Jest to proces przechowywania danych w którym mamy dostępny obiekt Cache który jest właściwością obiektu Page. Stanowi on zbiór klasy typu System.Web.Caching.Cache. Obiekt ten wykorzystuje całą pamięć podręczną co oznacza, że jest on jeden na cała aplikacje a nie na stronę. Poniższy rysunek pokazuje nam ten obiekt:

Praca z obiektem Cache jest bardzo podobna do pracy z sesją. Można przypisać element bezpośrednio nadając mu klucz i wartość. Przy pobieraniu wartość z pamięci podręcznej pamiętajmy aby sprawdzić czy nie jest ona null (mógł np. upłynąć czas przechowywania wartości). Poniższy przykład demonstruje jak pobrać obiekty string z pamięci:

   1: //C#

   2: Cache["Greeting"] = "Hello, world!";

   3:     if (Cache["Greeting"] != null)

   4:         value = (string)Cache["Greeting"];

   5:     else

   6:         value = "Hello, world!";

Oczywiście to jest najprostszy sposób i wydaje się mało rzeczywisty ale równie dobrze możemy przechowywać tam pliki, wyniki zapytań czy własne obiekty. Musimy tylko pamiętać aby zrzutować pobieraną wartość na odpowiedni typ.  W TK są opisane właściwości którymi możemy rozszerzyć o pewne właściwości nasze przechowywane dane i przykłady. Ja chciałbym przytoczyć jeden w którym jest ustawiany czas “trzymania” wartości ;)

   1: //C#

   2: Cache.Insert("FileCache", "CacheContents", null, DateTime.Now.AddMinutes(10),

   3: Cache.NoSlidingExpiration);

Page Output Caching

Często jest tak, że przeglądarka pobiera stronę, zapisuje ją na dysku i przy żądaniu sprawdza czy jest nowa wersja i jeżeli nie to ją wczytuje. Taki rozwiązanie m.in powoduje mniejsze obciążenie serwera. Aby zwiększyć wydajność i zmniejszyć czas renderowania, ASP.NET obsługuje tytułowy page output caching. Powoduje to, że np. serwer może trzymać w swojej pamięci zażądaną stronę i nawet kiedy inny użytkownik będzie chciał ją wczytać otrzyma ją w bardzo szybkim tempie. Jest to przydatne kiedy dana strona jest “ciężka”. Nie ma również problemu ze stornami tworzonymi dynamicznie wg. indywidualnych potrzeb użytkownika.

Możemy każdej ze stron ustawić buforowanie. Robimy to dodając do dyrektywy @ OutputCach. W TK są właściwości jakie możemy ustawić czyli np. czas, lokalizacje przechowywania oraz których nie możemy używać do kontrolek. Poniższy przykład pokazuje, jak ustawić “cachowanie” strony przez 15 minut, niezależnie od parametry przekazane do strony:

   1: <%@ OutputCache Duration="15" VaryByParam="location;count" %>

Nic nie stoi na przeszkodzie aby ustawić buforowanie dla całej aplikacji. Robimy sobie profile które potem możemy użyć na poszczególnych stronach. Oczywiście musimy umieścić odpowiednią sekcje w naszym web.config :

   1: <caching>

   2:     <outputCacheSettings>

   3:         <outputCacheProfiles>

   4:             <add name="OneMinuteProfile" enabled="true" duration="60"/>

   5:         </outputCacheProfiles>

   6:     </outputCacheSettings>

   7: </caching>

I aby nasza strona stosowała się do tego musimy przypisać jej ten profil:

   1: <%@ OutputCache CacheProfile="OneMinuteProfile" VaryByParam="none" %>

Na tym zakończę ten wpis. Wybaczcie, że jest on taki ogólnikowy ale jestem po nocnej podróży z Imagine Cup ;) W TK możecie doczytać sobie różne właściwości i np. jak sprawdzić czy skorzystać z zapisanej lokalnie strony czy nie ;) Jest to również ostatni wpis z serii przygotowań do egzaminu 70-562 ASP.NET. Wszystkim wiernym czytelnikom dziękuje w imieniu chłopaków jak i swoim :) Pamiętajcie, że artykuły nakreślają tematy zawarte w TK i mają tylko pomóc w zrozumieniu pewnych zagadnień a nie są kompendium wiedzy dotyczącej samego egzaminu i jego zawartości. Trzymajcie się, miłego weekendu! :D

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

W dzisiejszej lekcji powiemy sobie o wdrażaniu aplikacji internetowych w ASP.NET.

Tworzenie projektu Web Setup

Web setup jest narzędziem, które wspomaga wdrażanie naszej aplikacji internetowej. Projekt Web Setup jest bardzo podobny do standardowego projektu Setup, który mamy w aplikacjach Windows Forms, lecz dostarcza specjalnych właściwości wymaganych przez aplikację Web. Aby stworzyć nowy projekt typu Web Setup musimy podczas tworzenia projektu wybrać zakładkę Other Project Types –> Setup  and Deployment –> Web Setup Project.

Po stworzeniu nowego projektu, Visual dołączy projekt do solution oraz wyświetli edytor “File System”. Następnie musimy dodać do nowo utworzonego projektu nowy element. Ustawiamy się na projekcie i wybieramy Add-> Project Output. W oknie tworzenia Project Output wybieramy Content i configuration ustawiamy na Active. W tym momencie zapewniliśmy sobie dostęp do naszego projektu, który chcemy wdrażać.

Tworzenie warunków uruchomienia

Dzięki warunkom uruchomienia możemy sobie sprawdzać np. czy na serwerze znajdują się Service Packi albo inne komponenty, które są wymagane do wdrożenia naszej aplikacji. Do tworzenia i zarządzania warunkami uruchomienia używa się edytora Launch Condition. Aby z niego skorzystać klikamy prawym przyciskiem na projekcie, następnie wybieramy View-> Launch Condition. Teraz aby dodać nowy warunek klikamy prawym przyciskiem na folderze Launch Condition i wybieramy Add Launch Condition:

Istnieją dwie główne gałęzie w edytorze: Search Target Machine oraz Launch Condition:
Search Target Machine – pozwala na zdefiniowanie kryteriów wyszukiwania przed instalacją. Domyślnie zawiera wyszukiwanie dla IIS ale możemy dodać do niego pliki rejestru, Windows Installer Search Condition itp.
Launch Condition – pozwala na tworzenie nowych warunków, które muszą być spełnione przed instalacją. Mogą być one oparte o warunki wyszukiwania lub inne kryteria (np. wersja systemu operacyjnego).

Po stworzeniu nowego warunku, możemy we właściwości Condition ustawić nasz warunek. Np. sprawdzanie wersji IIS może odbyć się w taki sposób:

   1: IISVERSION = "#6" 

Sprawdzamy tu, czy wersja IIS jest równa 6. Oczywiście możemy używać operatorów > < >= <=. Aby sprawdzić czy dyskiem domowym jest C:

   1: %HOMEDRIVE = "C:"

Dodawanie własnej strony setup’u

Możemy dodać własne strony do naszego instalatora. Można w nich pobierać jakieś informacje a następnie przekazywać je jako parametry do własnych akcji. Działania jakie możemy wykonywać podczas instalacji:
Wyświetlanie licencji – projekt Web Setup dostarcza szablon do potwierdzania licencji
Modyfikowanie ustawień w Web.Config – zmienianie ustawień Web.Config na podstawie danych przekazanych przez użytkownika
Wykonywanie niestandardowej konfiguracji – możemy za pomocą własnej konfiguracji zapytać użytkownika o jakieś informację i przechowywać je np. w rejestrze.
Aktywacja bądź rejestracja aplikacji – możemy wymagać od użytkownika podanie klucza bądź rejestracji

Aby dodać własną stronę, wchodzimy w User Interface(prawym przyskiem myszy na projekcie –> View –> User Interface). Edytor ten wyświetla różne etapy konfiguracji itp:

Teraz wystarczy PPM na etapie, w którym chcemy dodać stronę i wybieramy Add Dialog. Widzimy opcję, które możemy dodać do projektu. Proponuję pobawić się nimi i zobaczyć jak działają bądź doczytać o nich na msdnie.

Wdrażanie aplikacji

Po skonfigurowaniu naszego projektu i zbudowaniu jesteśmy gotowi wdrożyć go na serwerze :) Aby to zrobić, należy użyć plików wygenerowanych podczas buildu:
Setup.exe – plik, który instaluje pliki i wprowadza ustawienia, które dodaliśmy w naszym projekcie. Podczas instalacji zostaniemy zapytani o wszystkie dodatkowe ustawienia.
<NazwaProjektu>.msi – plik instalatora Windows zawierający wszystkie pliki dodane do projektu. Uruchomienie tego pliku jest równoważne uruchomieniu Setup.exe. Ten typ pliku jest mniejszy i bardziej uniwersalny.
Bardziej polecany jest plik msi, chociaż ma jedną wadę: serwer, na którym chcemy instalować aplikację musi mieć Windows Installer.

To wszystko z mojej strony :) Dziękuję za wytrwanie w tej serii wpisów :)

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

W dzisiejszej lekcji będzie na temat budowania, uruchamiania oraz testowania mobilnych wersji aplikacji webowych stworzonych w technologii ASP.NET.

Tworzenie aplikacji mobilnych mocno nie różni się od tworzenia zwykłych aplikacji webowych. Trzeba tylko pamiętać, że w większości urządzenia mobilne mają większe ograniczenia w stosunku do normalnych komputerów. Dlatego wersje mobilne aplikacji powinny być jak najmniej skomplikowane oraz zawierać jak najmniej elementów, aby urządzenie poradziło sobie z jej wyświetleniem.

Dodanie mobilnej strony do aplikacji

Aplikacja ASP.NET może zawierać jednocześnie strony w wersji normalnej oraz wersje mobilne. Nie ma oddzielnego projektu w Visual Studio dla mobilnych aplikacji ASP.NET. Nie ma również szablonu dla strony mobilnej, który można by wykorzystać dodając taką stronę do projektu. W celu dodania mobilnej strony, programista musi dodać normalną stronę, a następnie zmienić trzy elementy na niej:

• w kodzie behind danej strony zmieniamy klasę, z której dziedziczy klasa strony z System.Web.UI.Page na System.Web.UI.MobileControls.MobilePage
• w kodzie aspx po dyrektywie page dodajemy dyrektywę, która załaduje przestrzeń nazw System.Web.UI.MobileControls, z której będą pochodzi kontrolki na stronie

     1: <%@ Register TagPrefix="mobile" Namespace="System.Web.UI.MobileControls" %>

• zamieniamy wygenerowany przez Visual Studio formularz, który korzysta z wcześniej dodanej przestrzeni nazw:

   1: <mobile:Form id="form1" runat="server">

   2: </mobile:Form>

Mobilne kontrolki

Przestrzeń nazw System.Web.UI.MobileControls udostępnia programiście szereg kontrolek, które może wykorzystać tworząc mobilne wersje aplikacji ASP.NET, które są przystosowane do pracy z urządzeniami mobilnymi. Tymi kontrolkami są między innymi (większość kontrolek jest bardzo podobna do normalnych kontrolek ASP.NET):

• Label – za jej pomocą programista może z poziomu kodu behind wyświetlić tekst na stronie. Gdy ma zostać wyświetlona większa ilość tekstu, lepiej skorzystać z kontrolki TextView
• TextBox – służy do pobierania danych tekstowych od użytkownika
• TextView – służy do wyświetlenia większej ilości tekstu. Umożliwia użycia prostego formatowania HTML (np. a (link), b (pogrubienie), br (znak nowej lini), i (kursywa), p (akapit))
• Command – przycisk, który może kliknąć użytkownik. Wywoływane jest zdarzenie OnClick, gdy użytkownik kliknie w przycisk
• Image – kontrolka służy do wyświetlenie obrazka, w przypadku, gdy format obrazka nie jest obsługiwany, wyświetlany jest tekst z właściwości AlternateText
• List – kontrolka służy do wyświetlenie elementów w formie listy
• SelectionList – jest podobna do kontrolki List, dodatkowo umożliwia wielokrotny elementów z listy
• ObjectList – jest to odpowiednik GridView z normalnego ASP.NET, czyli umożliwia wyświetlenie danych w postaci tabelki
• Calendar – kontrolka kalendarza umożliwiająca wybranie daty przez użytkownika. Kontrolka może wyglądać różnie w zależności od urządzenia (patrz opis niżej)
• Kontrolki walidujące – dostępne są wszystkie kontrolki walidujące dostępne w normalnym ASP.NET

Brak obsługi cookie

Większość urządzeń mobilnych niestety nie obsługuje plików cookie przez co mogą wystąpić problemy między innymi z sesją oraz uwierzytelnianiem, gdzie domyślnie te mechanizmy korzystają z plików cookie (np. do przechowywania ID sesji). Dlatego w przypadku sesji należy ustawić właściwość cookieless na true, dzięki czemu ID sesji będzie przekazywany w adresie url. Aby to zrobić trzeba w web.configu (dla system.web) dodać:

   1: <sessionState cookieless="true" />

Adaptacyjny rendering

Na rynku istnieją różnego rodzaju urządzenia mobilne, które czasami mają bardzo ograniczone możliwości wyświetlania strony. Dlatego kontrolki mobilne ASP.NET umożliwiają renderowanie strony w zależności od przeglądarki, z której jest wysłane żądanie do serwera. I tak na SmartPhonie kontrolka kalendarza może być wyświetlona w sposób identyczny, jak w normalnej wersji strony w przeglądarce na komputerze, co widać na rysunku niżej:

Natomiast w prostym telefonie wybór daty z kalendarza może przebiegać w kilku etapach, co widać na poniższym rysunku:

Gdzie wybór daty może przebiegać w trzech krokach:

• wybór miesiąca np. wrzesień 2006
• wybór tygodniach np. 10 – 16 września
• wybór dnia tygodnia środa 12 września

W każdym żądaniu HTTP jest przekazywany nagłówek User-Agent, w którym znajduje się ciąg znaków identyfikujący przeglądarkę z jakiej korzysta użytkownik. ASP.NET przechowuje w plikach o rozszerzeniu browser konfigurację sposobu wyświetlania strony w zależności od przeglądarki. Globalnie pliki te przechowywane są w katalogu c:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers\. Właśnie na podstawie tych plików ASP.NET decyduje w jaki sposób ma zostać wyświetlona strona, czy to kontrolki (np. Calendar pokazany wyżej).

Dodatkowo programista z poziomu kodu behind może sprawdzić, czy żądanie przyszło z urządzenia mobilnego, czy nie. Na podstawie tej informacji może wykonać odpowiedni kod. Aby to sprawdzić, wystarczy sprawdzić wartość właściwości Request.Browser.IsMobileDevice.

   1: if(Request.Browser.IsMobileDevice)

   2: {

   3:     //kod dla mobilnej wersji   

   4: }else

   5: {

   6:     //kod dla wersji normalnej

   7: }

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

Do tej pory powiedzieliśmy sobie o profilach użytkowników, narzędziu WSAT, kontrolce Login czy też o podstawach membershipa. ASP.NET wspiera co najmniej 4 rodzaje uwierzytelniania są to:

• Windows authentication
• Forms authentication (which ASP.NET membership uses)
• Passport authentication
• Anonymous access

Dzisiaj porozmawiamy w sposób ogólny jak można wykorzystać każdy z tych sposobów.

Konfiguracja aplikacji webowej która wymaga uwierzytelnienia poprzez Windows authentication

Jeśli aplikacja będzie wykorzystywana typowo wewnątrz firmy w której użytkownicy mają swoją konta które są w bazie lub jest cały Active Direcotry to wskazane jest korzystanie właśnie z Windows authentication. Możesz skonfigurować uwierzytelnianie Windows na dwa sposoby: w IIS oraz w aplikacji ASP.NET. Jeśli chcemy się ekstra zabezpieczyć to korzystamy z dwóch na raz. Kiedy aplikacja internetowa wymaga uwierzytelniania systemu Windows, aplikacja odrzuca wniosek, który nie zawiera prawidłowej nazwy użytkownika i hasła w nagłówku żądania. Niektóre przeglądarki np. IE ;) automatycznie dostarczają aktualną nazwę oraz hasło użytkownika który jest obecnie w intranecie. Nie trzeba chyba mówić, że to usprawnia prace i pozwala się płynnie uwierzytelniać użytkownikowi podczas każdych odwiedzin.

Dodatkowo, ponieważ użytkownicy są uwierzytelniani przez serwer w lokalnej bazie danych użytkownika lub
Domeny Active Directory, przy użyciu uwierzytelniania systemu Windows pozwala to uniknąć tworzenia bazy danych do przechowywania poświadczenia użytkownika. Także można stwierdzić, że Windows authentication jest najprostszym ze sposobów uwierzytelniania.

Aby dodać w prosty sposób Windows authentication do naszej aplikacji webowe w pliku web.config musimy umieścić sekcje <authentication> :

   1: <configuration>

   2: <system.web>

   3:     <authentication mode="Windows" />

   4:         <authorization>

   5:                 <deny users="?" />

   6:        </authorization>

   7: </system.web>

   8: </configuration>

Jeśli mamy jakiś formularz w który mielibyśmy możliwość wpisania loginu i hasła. Powiedzmy, że zrobiliśmy taki formularz i jest on na stornie Login.aspx. Musimy tam odesłać każdego niezalogowanego użytkownika ze storn do których nie ma dostępu. Aby to zrobić umieszczamy sekcje w web.config:

   1: <configuration>

   2:     <system.web>

   3:             <authentication mode="Forms">

   4:                 <forms loginURL="Login.aspx" />

   5:             </authentication>

   6:            <authorization>

   7:                <deny users="?" />

   8:            </authentication>

   9:     </system.web>

  10: </configuration>

Na stornie Login.aspx oczywiście musimy sprawdzić poprawność wprowadzonych danych. Aby to zrobić wystarczy prosty kod:

   1: if (FormsAuthentication.Authenticate(username.Text,

   2: password.Text))

   3: {

   4: //user is authenticated. Redirect user to the page requested.

   5: FormsAuthentication.RedirectFromLoginPage(usernameTextBox.Text, false);

   6: }

False oznacza, że dane nie będą pamiętane w ciasteczku stąd po wyłączeniu przeglądarki na nowo będziemy musieli się zalogować.

Jest możliwość skonfigurowania konta użytkownika wewnątrz web.config jeśli nie chcemy trzymać tych danych np. w bazie. Są trzy możliwości przechowywania hasła takiego użytkownika: jawny tekst, MD5 lub SHA1. Pozwala to uniknąć kradzieży konta przez użytkownika który ma dostęp do naszego pliku web.config. Spójrzmy jak przykładowo wygląda to właśnie w pliku web.config :

   1: <authentication mode="Forms">

   2:     <forms loginUrl="login.aspx" protection="Encryption" timeout="30" >

   3:         <credentials passwordFormat="SHA1" >

   4:             <user name="Eric" password="07B7F3EE06F278DB966BE960E7CBBD103DF30CA6"/>

   5:             <user name="Sam" password="5753A498F025464D72E088A9D5D6E872592D5F91"/>

   6:         </credentials>

   7:     </forms>

   8: </authentication>

Jednak aby pozwolić nam na korzystanie z takich zakodowanych haseł musimy mieć możliwość ich stworzenia. Przydałaby się program który by kodował hasło które później moglibyśmy używać w web.configu . Do tego celu możemy wykorzystać przestrzeń nazw System.Security.Cryptography. Spójrzmy na przykładowy kod generowania hash’a.

   1: namespace HashExample

   2: {

   3: class Program

   4: {

   5: static void Main(string[] args)

   6: {

   7: SHA1CryptoServiceProvider myHash=new SHA1CryptoServiceProvider();

   8: byte[] password = Encoding.ASCII.GetBytes(args[0]);

   9: myHash.ComputeHash(password);

  10: foreach (byte thisByte in myHash.Hash)

  11: Console.Write(thisByte.ToString("X2"));

  12: Console.WriteLine();

  13: }

  14: }

  15: }

Uwierzytelnianie za pomocą Paszportów

Można korzystać z usługi paszportów oferowaną przez Microsoft. Paszport pozwala odpłatnie korzystać z zcentralizowanej bazy danych. Przechowywanie danych o użytkownikach w ramach tej usługi uwalnia ich od tworzenia nowych profili, pamiętania kolejnego hasła do kolejnej witryny itd. Jest to również zaoszczędzenie czasu i co tu ukrywać przyjemne dla naszego odbiorcy.

Konfigurowanie aplikacji dla anonimowych użytkowników

Możemy wyraźniej wyłączyć autoryzowanie użytkowników w naszej aplikacji. Jednak zaleca się aby wtedy korzystać z IIS. Aby to zrobić wystarczy następująca sekcja w web.config:

   1: <configuration>

   2:     <system.web>

   3:         <authentication mode="None" />

   4:     </system.web>

   5: </configuration>

Możemy ograniczyć dostęp do poszczególnych folderów, plików naszej aplikacji na podstawie np. grupy czy konkretnych użytkowników. Domyślnie machine.config zawiera:

   1: <authorization>

   2: <allow users="*"/>

   3: </authorization>

Sekcja ta pozwala na dostęp wszystkim użytkownikom. Jeśli chcielibyśmy ograniczyć dostęp do poszczególnych użytkowników należałoby zastosować tą przykładowa sekcje:

   1: <authorization>

   2:     <allow users="Eric, Sam"/>

   3:     <deny users="*"/>

   4: </authorization>

Sekcja ta jednak ogranicza nam dostęp dla całej aplikacji. Jeśli chcielibyśmy użyć ograniczeń do konkretnej strony wyglądałoby to następująco:

   1: <location path="ListUsers.aspx">

   2:     <system.web>

   3:         <authentication mode="forms">

   4:             <forms loginUrl="AdminLogin.aspx" protection="All"/>

   5:         </authentication>

   6: <authorization>

   7:     <allow users="admin"/>

   8:         <deny users="*"/>

   9: </authorization>

  10: </system.web>

  11: </location>

To tyle na dzisiaj. Miłej zabawy na Kortowiadzie ;)

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

W dzisiejszym artykule powiemy sobie o używaniu kontrolki logowania, zarządzaniu użytkownikami, informacjami na ich temat oraz o rolach. To wszystko zrealizujemy używając mechanizmu Membership.

Użycie WSAT do konfigurowania zabezpieczeń

Do zarządzania użytkownikami, rolami oraz zabezpieczeniami na naszej stronie możemy użyć wbudowanego narzędzia Web Site Administration Tool (WSAT).

Tworzenie użytkowników

Aby uruchomić WSAT należy wybrać z menu ASP.NET Configuration. Konfiguracje użytkowników znajdziecie w zakładce Security. Najpierw musimy skonfigurować uwierzytelnianie. Mamy do wyboru uwierzytelnianie Windows, Lokalne Active Directory oraz uwierzytelnianie za pomocą formularza. Po wybraniu interesującego nas uwierzytelniania możemy stworzyć użytkownika, zarządzać nim, nadać mu role itp. Poniżej przykład tworzenia nowego usera:

Jeśli wybraliśmy uwierzytelnianie oparte o formularze (Web-based), WSAT automatycznie stworzy lokalną baze i umieści ją w katalogu App_Data (no chyba że chcemy podczepić inną baze np. wygenerowaną tak jak w poprzednim wpisie). Doda również wpis do pliku Web.config, który włącza nasze uwierzytelnianie:

   1: <configuration>

   2:  <system.web>

   3:   <authentication mode="Forms" />

   4:  </system.web>

   5: </configuration>

Tworzenie ról

Aby włączyć role wystarczy odpalić WSAT i kliknąć w link, który je włącza :) Po włączeniu ról, WSAT doda do Web.Config taki kod:

   1: <configuration>

   2:  <system.web>

   3:   <roleManager enabled="true" />

   4:  </system.web>

   5: </configuration>

Teraz możemy już tworzyć własne role i przypisywać do nich użytkowników. Robi się to podczas tworzenia nowego użytkownika ew. podczas jego edycji :)

Podobnie działa mechanizm “Acces Rules”, dzięki któremu możemy określić kto ma dostęp do folderu czy pliku. Również wszystko robimy z poziomu WSAT.

Kontrolka Login

Istnieje kilka kontrolek, wbudowanych w ASP .NET, dzięki którym możemy zarządzać logowaniem i informacjami na temat logowania. Dostarczają one interfejs użytkownika i szereg metod pomagających w zarządzaniu informacjami. Poniżej hierarchia:

CreateUserWizard – jest to “kreator”, dzięki któremu stworzymy nowego użytkownika.
Login – kontrolka, dzięki której dajemy użytkownikowi możliwość zalogowania się .
LoginView – kontrolki tej możemy użyć np. do udostępnienia linka, dostępnego dla zalogowanych użytkowików
LoginName – wyświetla bieżącego użytkownika (jeśli jest zalogowany)
PasswordRecovery – pozwala na zresetowanie hasła użytkownika poprzez wysłanie maila bądź odpowiedź na pytanie
ChangePassword – pozwala zmienić bieżące hasło.

Wszystkie kontrolki są bardzo proste w użyciu, więc nie będę opisywał po kolei (tak jak jest to opisane w TK), jak przeciągnąć na formatkę itp :) Myślę że każdy sobie z tym poradzi.

Klasa Membership

Poniżej najważniejsze statyczne metody klasy Membership, dzięki którym możemy ręcznie stworzyć użytkownika, usunąć itp:
CreateUser – dodaje nowego użytkownika do bazy danych.
DeleteUser – usuwa użytkownika z bazy
FindUsersByEmail – metoda wyszukuje użytkownika (z kolekcji użytkowników), do którego pasuje podany mail
FindUsersByName – tak jak wyżej tylko szukanie odbywa się po nazwie.
GeneratePassword – metoda ta tworzy losowe hasło o podanej długości
GetAllUsers – zwraca kolekcję wszystkich użytkowników znajdujących się w bazie
GetNumberOfUsersOnline – metoda zwraca ilość zalogowanych osób
GetUser – zwraca aktualnie zalogowanego użytkownika
GetUserNameByEmail – pobiera nazwę użytkownika na podstawie maila
UpdateUser – aktualizuje informacje o użytkowniku

Klasa Roles

Klasa Roles dostarcza wielu statycznych metod, dzięki którym możemy operować, zarządzać rolami.

AddUserToRole, AddUsersToRole i AddUsersToRoles – dodają użytkownika (użytkowników) do roli (ról)
CreateRole – tworzy nową role
DeleteRole – kasuje role
FindUsersInRole – znajduje użytkowników w podanej roli
GetAllRoles – zwraca wszystkie istniejące role
GetRolesForUser – zwraca role przypisane do podanego użytkownika
IsUserInRole – zwraca true, jeśli użytkownik należy do podanej roli
RemoveUserFromRole, RemoveUsersFromRole, RemoveUserFromRoles, i RemoveUsersFromRoles – usuwa użytkownika z roli

Jeśli np. chcemy przypisać użytkownika do roli, możemy napisać tak: (w tym przykładzie nazwa użytkownika brana jest z kontrolki CreateUserWizard):

   1: Roles.AddUserToRole(CreateUserWizard1.UserName, "Users");

To tyle na dziś. W następnym artykule będziecie mogli przeczytać o zabezpieczaniu strony. Zapraszam w imieniu Dawida :)