ASP.NET MVC – okna modalne z wykorzystaniem Kendo UI

2012-02-042016-01-31 TPodolakASP.NET-MVC, ModalWindow, MVC5 Comments

Ostatnimi czasy w pracy eksperymentujemy z ASP.NET MVC. Jednym z problemów na jakie natknąłem się poznając tą technologię było utworzenie okien modalnych. Po niezbyt owocnej walce z kontrolkami ze stajni Devexpressa postanowiliśmy, że skorzystamy z darmowej biblioteki Kendo UI napisanej w jQuery. Wspomnianą wcześniej bibliotekę możemy znaleźć pod adresem http://www.kendoui.com/get-kendo-ui.aspx. Aby uzyskać dostęp do plików należy zarejestrować się w systemie – oczywiście rejestracja jest darmowa. Po zassaniu wszystkich plików kopiujemy zawartość katalogu “source” do naszego projektu MVC. W moim przypadku utworzyłem katalog Kendo w katalogu Content i tam umieściłem zawartość katalogu “source”.

Mając wszystkie pliki w komplecie musimy wskazać naszej aplikacji aby zaczęła z nich korzystać. Dodajmy zatem w pliku _Layout.cshtml następujące elementy

<script src="@Url.Content("~/Content/Kendo/js/jquery.min.js")" type="text/javascript"></script>
<link href="@Url.Content("~/Content/Site.css")" rel="stylesheet" type="text/css" />
<link href="@Url.Content("~/Content/Kendo/styles/kendo.common.css")" rel="stylesheet"/>
<link href="@Url.Content("~/Content/Kendo/styles/kendo.default.css")" rel="stylesheet"/>
<script src="@Url.Content("~/Scripts/jquery-1.5.1.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/jquery.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.core.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.data.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.pager.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.selectable.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.draganddrop.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.groupable.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.grid.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.fx.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.resizable.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.window.js")" type="text/javascript"></script>

Przejdźmy teraz do najważniejszej części, a mianowicie do tworzenia okna modalnego. Biblioteka Kendo UI udostępnia nam funkcję kendoWindow, dzięki której jesteśmy w stanie utworzyć okno modalne. Okno to jednak nie ma w sobie żadnej zawartości – nie posiada nawet przycisków typu “Zapisz” oraz “Anuluj”. Utworzenie i załadowanie zawartości okna oraz reakcja na kliknięcia w potencjalne przyciski musi zostać obsłużona przez nas. Zacznijmy zatem od utworzenia zawartości okna. Załóżmy, że okno, które za chwilę stworzymy będzie służyło do dodawania nowego produktu do bazy danych. Klasa produkt jest bardzo prostą klasą prezentującą się w następujący sposób:

public class Product
{
    public string Id { get; set; }
    public string Name { get; set; }
    public int Quantity { get; set; }
}

public class Product

{

public string Id { get; set; }

public string Name { get; set; }

public int Quantity { get; set; }

}

Stwórzmy zatem strongly-typed partial view, który będzie zawartością naszego okna modalnego. Widok ten będzie posiadał dwa textboxy do wypełniania propertisów obiektu, oraz przyciski “Zapisz” oraz “Anuluj”. Zacznijmy od dodania odpowiednich funkcji w kontrolerze. Pierwszą z nich będzie akcja AddProduct();

public PartialViewResult AddProduct()
{
    return PartialView("AddProduct", new Product());
}

public PartialViewResult AddProduct()

{

return PartialView("AddProduct", new Product());

}

W celu dodania widoku klikamy PPM na nazwę funkcji i wybieramy opcję “Add View”. W otwartym oknie zaznaczmy opcję “Create Strongly Typed View”, a w comboboxie wpisujemy “Product”. Ponadto zaznaczamy checkboxa “Create as a partial view”.

W katalogu Home pojawił się nowy plik AddProduct.cshtml. W pliku tym zdefiniujemy wygląd zawartości naszego okna modalnego. Jako, że nasze dane będą musiały zostać wysłane na serwer do zapisu, skorzystamy z funkcji pomocniczej Html.BeginForm, w której to umieścimy wszystkie potrzebne elementy do edycji produktu.

@model ModalDialogs.Models.Product
<div id="windowContent">
    @using (Html.BeginForm("AddProduct", "Home", FormMethod.Post, new { id = "fmAddProduct" }))
    {
        @Html.ValidationSummary(true)
        <div>
            @Html.Label("lblName", "Nazwa")
            @Html.TextBoxFor(val => val.Name)
            @Html.ValidationMessageFor(val => val.Name)
        </div>
        <div>
            @Html.Label("lblQuantity", "Ilość")
            @Html.TextBoxFor(val => val.Quantity)
            @Html.ValidationMessageFor(val => val.Quantity)
        </div>
        <input type="button" value="Zapisz" id="btnSave" />
        <input type="button" value="Anuluj" id="btnCancel" />
    }
</div>

@model ModalDialogs.Models.Product

@using (Html.BeginForm("AddProduct", "Home", FormMethod.Post, new { id = "fmAddProduct" }))

{

@Html.ValidationSummary(true)

<div>

@Html.Label("lblName", "Nazwa")

@Html.TextBoxFor(val => val.Name)

@Html.ValidationMessageFor(val => val.Name)

</div>

<div>

@Html.Label("lblQuantity", "Ilość")

@Html.TextBoxFor(val => val.Quantity)

@Html.ValidationMessageFor(val => val.Quantity)

</div>

}

</div>

Dodajmy teraz na naszej stronie głównej linka, który wywoła nasze okno modalne.

@Html.ActionLink("Dodaj produkt", "AddProduct", "Home", null, new { id = "addProduct" })

1	@Html.ActionLink("Dodaj produkt", "AddProduct", "Home", null, new { id = "addProduct" })

Przyszedł teraz czas na najważniejszą część wpisu, a mianowicie na wykorzystaniu jQuery oraz kendoWindow do pokazania okna edycji/dodawania produktu. Najpierw podpinamy się do zdarzenia(dodajemy handler) click utworzonego przed chwilą odnośnika. W funkcji obsługującej zdarzenie click musimy utworzyć okno,wypełnić jego zawartość oraz pokazać okno.

$(document).ready(function () {
        var $kendoWindow;
        $("#addProduct").click(function (event) {
            debugger;
            event.preventDefault(); // anulujemy domyślną akcję
            var $dialog = $('<div></div>');
            var $url = $(this).attr('href'); //wyciągamy  url-a
            $dialog.empty();
            $kendoWindow = $dialog.kendoWindow({ //tworzmy okno
                height: "200px", //o wysokosci 200px
                title: "Dodaj", // z tytulem "Dodaj"
                width: "200px", // o szerokosci 200px
                actions: ["Close"], // ktore mozna jedynie zamknac - nie mozna przesuwac, odswiezac itp
                content: $url // ktorego zawartosc pobieramy z urla przechwyconego z clica

            }).data("kendoWindow");
            $kendoWindow.center(); //centrujemy okno
            $kendoWindow.open(); // otwieramy
        });
...
...
...
}

$(document).ready(function () {

var $kendoWindow;

$("#addProduct").click(function (event) {

debugger;

event.preventDefault(); // anulujemy domyślną akcję

var $dialog = $('<div></div>');

var $url = $(this).attr('href'); //wyciągamy url-a

$dialog.empty();

$kendoWindow = $dialog.kendoWindow({ //tworzmy okno

height: "200px", //o wysokosci 200px

title: "Dodaj", // z tytulem "Dodaj"

width: "200px", // o szerokosci 200px

actions: ["Close"], // ktore mozna jedynie zamknac - nie mozna przesuwac, odswiezac itp

content: $url // ktorego zawartosc pobieramy z urla przechwyconego z clica

}).data("kendoWindow");

$kendoWindow.center(); //centrujemy okno

$kendoWindow.open(); // otwieramy

});

...

}

Korzystając z selektora jQuery znajdujemy link opisany id-kiem “addProduct”, a następnie podłączamy się do zdarzenia click. W funkcji obsługującej zdarzenie musimy najpierw zapobiec wywołaniu się domyślnej akcji wykonującej się po naciśnięciu na link. Robimy to przy pomocy funkcji prefentDefault(). W kolejnych krokach tworzymy okno modalne zgodnie ze wskazówkami znajdującymi się w dokumentacji Kendo UI http://demos.kendoui.com/web/window/index.html. Najważniejszym elementem przy tworzeniu okna jest dynamiczne załadowanie jego zawartości poprzez podanie linka do akcji w kontrolerze. Linka tego jesteśmy w stanie wyciągnąć wykorzystując kolejną użyteczną funkcję jQuery – attr(‘nazwaAtrybutu’).
Od tej chwili po naciśnięciu odnośnika “Dodaj produkt” zawsze będzie odpalane okno modalne dodawania nowego produktu. Teraz musimy jeszcze obsłużyć zdarzenia click na przyciskach “Zapisz” oraz “Anuluj”. Do funkcji przedstawionej powyżej dopisujemy następujące linijki

$("#btnSave").live("click", function (event) {
            event.preventDefault(); // anulujemy domyślną akcję
            var $url = $("#fmAddProduct").attr("action"); //wyciągamy  url-a
           // odpalamy ajaxa w celu wywołania akcji kontrolera
            $.ajax(
                {
                    url: $url,  // podajemy url z akcja kontrolera
                    type: "POST", // okreslamy metode 
                    data: $("#fmAddProduct").serialize(), // przekazujemy dane 
                    success: function (response) {       //w przypadku gdy wszystko OK
                        $("#btnSave").unbind(); // odpinamy zdarzenia
                        $("btnCancel").unbind();
                        $kendoWindow.close(); //zamykamy i 
                        $kendoWindow.destroy(); // niszczymy okno
                    },
                    error: function (response) {
                        $("#btnSave").unbind(); //odpinamy zarzenia
                        $("btnCancel").unbind();
                        $kendoWindow.content(response.responseText); //odswiezamy zawartosc okna
                    }
                });
        });

        $("#btnCancel").live("click", function (event) {
            event.preventDefault();// anulujemy domyślną akcję
            $("#btnSave").unbind(); //odpinamy zdarzenia
            $("btnCancel").unbind();
            $kendoWindow.close(); //zamykamy i
            $kendoWindow.destroy(); // niszczymy okno
        });

$("#btnSave").live("click", function (event) {

event.preventDefault(); // anulujemy domyślną akcję

var $url = $("#fmAddProduct").attr("action"); //wyciągamy url-a

// odpalamy ajaxa w celu wywołania akcji kontrolera

$.ajax(

{

url: $url, // podajemy url z akcja kontrolera

type: "POST", // okreslamy metode

data: $("#fmAddProduct").serialize(), // przekazujemy dane

success: function (response) { //w przypadku gdy wszystko OK

$("#btnSave").unbind(); // odpinamy zdarzenia

$("btnCancel").unbind();

$kendoWindow.close(); //zamykamy i

$kendoWindow.destroy(); // niszczymy okno

error: function (response) {

$("#btnSave").unbind(); //odpinamy zarzenia

$("btnCancel").unbind();

$kendoWindow.content(response.responseText); //odswiezamy zawartosc okna

}

});

$("#btnCancel").live("click", function (event) {

event.preventDefault();// anulujemy domyślną akcję

$("#btnSave").unbind(); //odpinamy zdarzenia

$("btnCancel").unbind();

$kendoWindow.close(); //zamykamy i

$kendoWindow.destroy(); // niszczymy okno

});

Tutaj sytuacja odrobinę się komplikuje gdyż musimy wysłać wprowadzone dane do kontrolera oraz obsłużyć ewentualne błędy walidacji. Zaczynamy od znalezienia przycisku opisanego id-kiem “btnSave” oraz podpięcia się do zdarzenia click. Ponownie anulujemy domyślną akcję wywołując funkcję preventDefault(). W kolejnym kroku wyciągamy url-a, który miał zostać wywołany po naciśnięciu przycisku. Robimy to, ponownie wykorzystując funkcję attr(‘nazwaAtrybutu’). Jednakże teraz wyszukujemy tego atrybutu na obiekcie o id =”fmAddProduct” (taki id nadaliśmy “formie” na której są pola edycyjne produktu).Ostatnim elementem jest wykonanie asynchronicznego zapytania AJAX. Do tego zapytania przekazujemy wcześniej uzyskany url,określamy typ zapytania jako “POST” oraz przesyłamy dane wykorzystując funkcję serialize z biblioteki jQuery. Na samym końcu musimy sprecyzować co ma się stać w przypadku gdy wszystko pójdzie ok – parametr success, a co w przypadku gdy coś będzie nie tak – parametr error. Musimy oczywiście dodać do kontrolera jeszcze jedną akcję. Tym razem będzie to również akcja AddProduct, jednakże będzie to akcja HttpPost posiadająca jeden parametr typu Product

[HttpPost]
public ActionResult AddProduct(Product product)
{
    if (ModelState.IsValid)
        return new EmptyResult();
    Response.StatusCode = (int)HttpStatusCode.BadRequest;
    return PartialView("AddProduct", product);
}

[HttpPost]

public ActionResult AddProduct(Product product)

{

if (ModelState.IsValid)

return new EmptyResult();

Response.StatusCode = (int)HttpStatusCode.BadRequest;

return PartialView("AddProduct", product);

}

Ostatnią rzeczą jaką musimy zrobić jest wyłączenie cachowania widoków, które są pokazywane w oknie modalnym – można to zrobić wykorzystując atrybut OutputCaching. W przypadku gdy nie wyłączymy cachowania, okna modalne, które raz nie przeszły walidacji nie będą mogły zostać zapisane. W celu wyłączenia cachowania dla poszczególnych widoków najpierw musimy stworzyć profil cachowania. Dodajemy taki oto wpis do pliku Web.config

<caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add name="DisableCaching"
               duration="0"
               varyByParam="None"
               location="None" />
        </outputCacheProfiles>
      </outputCacheSettings>
</caching>

<add name="DisableCaching"

duration="0"

varyByParam="None"

location="None" />

</outputCacheProfiles>

</outputCacheSettings>

</caching>

a następnie dekorujemy atrybutem

[OutputCache(CacheProfile = "DisableCaching")]

1	[OutputCache(CacheProfile = "DisableCaching")]

akcje AddProduct() oraz AddProduct(Product product)
To by było na tyle, projekt można zassać z tego linka http://www.4shared.com/rar/F4pNi3VH/ModalDialogs.html

Lokalizowanie aplikacji Silverlight i Windows Phone z wykorzystaniem Portable Shared Library

2012-01-212016-01-31 TPodolakLocalization, Silverlight, Windows Phone

Witam
W dzisiejszym wpisie postaram się przedstawić w jaki sposób lokalizować treści aplikacji typu Silverlight oraz WindowsPhone. Założenie jest takie, że chcemy zbudować multiplatformową aplikację, która będzie obsługiwała platformę Silverlight oraz Windows Phone. Rozsądnym zatem podejściem jest trzymanie wszystkich tłumaczeń w jednym miejscu – najlepiej aby mechanizm tłumaczenia był obsługiwany zarówno przez Windows Phona jak i Silverlighta.
W pierwszym kroku musimy doinstalować do środowiska Visual Studio projekt typu Portable Class Library. Referencje do tego typu projektów możemy dodawać zarówno do projektów Silverlightowych, WindowsPhonowych – zatem idealnie nadaje się na przetrzymywanie w nim mechanizmu tłumaczenia aplikacji. W celu zainstalowania wyżej wspomnianego typu projektu musimy odwiedzić następującą stronę
http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981, a następnie zassać plik instalacyjny. Mając już przygotowane środowisko, stwórzmy nową solucję i dodajmy do niej projekt typu Portable Class Library – nazwijmy go SharedPortableClasses.

Następnie dodajmy do tego projektu nowy folder “Localization”, w którym to umieścimy pliki typu *.resx. Pierwszy plik nazywamy po prostu Localization.resx natomiast następne nazywamy według wzorca Localization..resx, gdzie:
<culture> – oznacza kulturę/język komunikatów jaki dany plik będzie przechowywać
Dla przykładu aby mechanizm tłumaczący obsługiwał język polski oraz angielski, powinniśmy stworzyć następującą strukturę plików

Localization.resx
Localization.pl-PL.resx
Localization.en-US.resx

W kolejnym kroku musimy zmienić modyfikator dostępu do naszych plików zasobów na publiczny. W tym celu klikamy podwójnie na każdy plik *.resx i z comboboxa wybieramy public

Mając przygotowane pliki zasobów, możemy teraz umieszczać w nich tłumaczone elementy interfejsów oraz komunikatów. Robimy to w następujący sposób:

W pliku Localization.resx wypełniamy pole w kolumnie “Name” jakąś wartością(kluczem), która identyfikuje nasz tekst (w moim przypadku będzie to “Title”)
W plikach Localization.pl-PL.resx oraz Localization.en-US powtarzamy tę czynność (uzupełniamy pola w kolumnie “Name” tymi samymi wartościami co w pliku Localization.resx) oraz wypełniamy pole w kolumnie “Value” tekstem w odpowiednim języku.

Mając już prawie gotowy mechanizm tłumaczący stwórzmy teraz projekt typu “Silverlight Application” oraz dodajmy mu referencję do projektu SharedPortableClasses. Dodajmy teraz do zasobów naszej aplikacji obiekt typu Localization

<Application.Resources>
        <Localization:Localization x:Key="LocalizationProxy" />
</Application.Resources>

<Application.Resources>

<Localization:Localization x:Key="LocalizationProxy" />

</Application.Resources>

Niestety z powodu tego, że klasa Localization nie posiada publicznego konstruktora bezparametrowego, nie uda nam się odpalić naszej aplikacji. Resharper od razu wyrzuci ostrzeżenie następującej treści

Zatem w jaki sposób wykorzystać nasz mechanizm tłumaczący ? Rozwiązania są dwa

Zmodyfikować plik Localization.Designer.cs i ustawić konstruktor domyślny na publiczny. Takie rozwiązanie jednak nie jest eleganckie, gdyż za każdym razem gdy dodamy nowy wpis do pliku Localization.resx kod w pliku Localization.Designer.cs zostanie przegenerowany.
Drugim sposobem jest stworzenie klasy pośredniczącej, która będzie w sobie trzymała instancję obiektu Localization, oraz dodanie obiektu tej klasy pośredniczącej do zasobów aplikacji

Jako, że podejście drugi jest wg mnie dużo lepsze to postaram się je teraz przedstawić. Do projektu SharedPortableClasses dodajmy klasę LocalizationProxy.cs.

public class LocalizationProxy : INotifyPropertyChanged
{
    public Localization LocalizationManager { get; private set; }

    public LocalizationProxy()
    {
        LocalizationManager = new Localization();
    }

    public void ResetResources()
    {
        OnPropertyChanged("LocalizationManager");
    }

    #region INotifyPropertyChanged region
    public event PropertyChangedEventHandler PropertyChanged;

    public void OnPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
    #endregion
}

public class LocalizationProxy : INotifyPropertyChanged

{

public Localization LocalizationManager { get; private set; }

public LocalizationProxy()

{

LocalizationManager = new Localization();

}

public void ResetResources()

{

OnPropertyChanged("LocalizationManager");

}

#region INotifyPropertyChanged region

public event PropertyChangedEventHandler PropertyChanged;

public void OnPropertyChanged(string propertyName)

{

if (PropertyChanged != null)

{

PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

}

#endregion

}

Teraz stwórzmy instancję tej klasy w zasobach aplikacji

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:Localization="clr-namespace:SharedPortableLibrary.Localization;assembly=SharedPortableLibrary"
             x:Class="LocalizationSolution.App">
    <Application.Resources>
        <Localization:LocalizationProxy x:Key="LocalizationProxy" />
    </Application.Resources>
</Application>

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:Localization="clr-namespace:SharedPortableLibrary.Localization;assembly=SharedPortableLibrary"

x:Class="LocalizationSolution.App">

<Application.Resources>

<Localization:LocalizationProxy x:Key="LocalizationProxy" />

</Application.Resources>

</Application>

Zanim przystąpimy do tłumaczenia samego interfejsu musimy jeszcze zmodyfikować plik projekty *.csproj. Otwieramy nasz plik projektu w dowolnym edytorze tekstowym, a następnie w sekcji SupportedCultures dorzucamy kultury w jakich
nasza aplikacja ma pracować. W moim przypadku będzie to wyglądać w następujący sposób:

Jak widać moja aplikacja będzie wspierała język angielski oraz język polski. Mając już wszystko gotowe przystąpmy do tworzenia interfejsu. Zmodyfikujmy plik MainPage.xaml tak aby wyglądał w następujący sposób

<UserControl x:Class="LocalizationSolution.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <!--TitlePanel contains the name of the application and page title-->
        <StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">
            <TextBlock TextWrapping="Wrap" x:Name="PageTitle" Text="{Binding Source={StaticResource LocalizationProxy},Path=LocalizationManager.Title,Mode=TwoWay}" Margin="9,-7,0,0" />
            <Button Content="Polski" Command="{Binding PolisLanguageCommand}"  Height="72" HorizontalAlignment="Left"   VerticalAlignment="Top" Width="160"   />
            <Button Content="English" Command="{Binding EnglishLanguageCommand}" Height="72" HorizontalAlignment="Left"  VerticalAlignment="Top" Width="160"  />
        </StackPanel>
    </Grid>
</UserControl>

<UserControl x:Class="LocalizationSolution.MainPage"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

mc:Ignorable="d"

d:DesignHeight="300" d:DesignWidth="400">

</StackPanel>

</Grid>

</UserControl>

Widok ten jest bardzo prosty. Posada on dwa przyciski służące do zmiany aktualnego języka oraz labelkę, na której dany tekst będzie się pojawiać. Najciekawszą rzeczą w tym kodzie jest sposób wyświetlania tłumaczonego tekstu. Jak widać do właściwości Text elementu typu TextBlok nie jest przypisywana wartość stała, ale używany jest binding

Text="{Binding Source={StaticResource LocalizationProxy},Path=LocalizationManager.Title,Mode=TwoWay}"

1	Text="{Binding Source={StaticResource LocalizationProxy},Path=LocalizationManager.Title,Mode=TwoWay}"

To co wyświetli się w danym TextBloku zależne jest od tego co zwróci nam nasz mechanizm tłumaczący. Odnosimy się do niego poprzez wskazanie zasobu, który nazwaliśmy LocalizationProxy (taki klucz nadaliśmy mu w zasobach aplikacji). Następnie do konkretnego tekstu odnosimy się podając odpowiednią ścieżkę – w tym przypadku jest to LocalizationManager.Title. LocalizationManager jest to właściwość, którą stworzyliśmy w klasie LocalizationProxy, natoamist Title jest to klucz jaki wpisaliśmy w pliku zasobów Localization.resx. Przeglądając plik Localization.Designer.cs można zauważyć, że została tam wygenerowana właściwość Title.

public static string Title 
{
    get { return ResourceManager.GetString("Title", resourceCulture); }
}

public static string Title

{

get { return ResourceManager.GetString("Title", resourceCulture); }

}

Właściwość tak zwraca nam tekst w odpowiednim języku. Sam mechanizm zwracania tekstu dla wybranego przez nas języka jest już dostarczony z Frameworkiem. Tekst wyświetlany w aplikacji będzie w takim języku/kulturze jaka zostania przypisana do właściwości Thread.CurrentThread.CurrentUICulture. Możemy to w łatwy sposób sprawdzić zmieniając dynamicznie kulture wątku.
Stwórzmy nową klasę i nazwijmy ją MainPageViewModel. Wygląda ona w następujący sposób

public class MainPageViewModel
{
    public DelegateCommand PolisLanguageCommand { get; set; }
    public DelegateCommand EnglishLanguageCommand { get; set; }
    public MainPageViewModel()
    {
        PolisLanguageCommand = new DelegateCommand(() =>
        {
            Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("pl-PL");
            Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("pl-PL");
            ResetResources();

        });

        EnglishLanguageCommand = new DelegateCommand(() =>
        {
            Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");
            Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-US");
            ResetResources();
        });
    }

    private void ResetResources()
    {
        ((LocalizationProxy)Application.Current.Resources["LocalizationProxy"]).ResetResources();
    }
}

public class MainPageViewModel

{

public DelegateCommand PolisLanguageCommand { get; set; }

public DelegateCommand EnglishLanguageCommand { get; set; }

public MainPageViewModel()

{

PolisLanguageCommand = new DelegateCommand(() =>

{

Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("pl-PL");

Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("pl-PL");

ResetResources();

});

EnglishLanguageCommand = new DelegateCommand(() =>

{

Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");

Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-US");

ResetResources();

});

}

private void ResetResources()

{

((LocalizationProxy)Application.Current.Resources["LocalizationProxy"]).ResetResources();

}

Następnie stwórzmy obiekt tej klasy i przypiszmy go do DataContext-u okna MainPage.

public partial class MainPage : UserControl
{
    public MainPage()
    {
        InitializeComponent();
        DataContext = new MainPageViewModel();
    }         
}

public partial class MainPage : UserControl

{

public MainPage()

{

InitializeComponent();

DataContext = new MainPageViewModel();

}

Dzięki wykorzystaniu komend po naciśnięciu przycisku “Polski” zostanie odpalana komenda PolishLangugeCommand, która z kolei odpali anonimową funkcję do niej przypisaną. W funkcji tej zmienimy kulturę wątku na “pl-PL”. Ważnym elementem jest tutaj funkcja ResetResources(), która znajduje się w klasie LocalizationProxy. Funkcja ta informuje widok (poprzez zdarzenie NotifyPropertyChanged), że należy odświeżyć wszystkie elementy, które zostały zbindowane do właściwości LocalizationManager.

Postępując w analogiczny sposób możemy stworzyć aplikację WindowsPhone, która będzie wykorzystywałą nasz mechanizm tłumaczący. Co więcej dzięki temu, że dwie aplikacje będą korzystały z tego samego mechanizmu oraz z tych samych resourców, nie musimy podwójnie wpisywać tłumaczonych tekstów.

Projekt można znaleźć pod tym linkiem
http://www.4shared.com/rar/i9cd3EGD/LocalizationSolution.html

Lokalizowanie aplikacji WPF oraz Silverlight 5 przy użyciu MarkupExtension

2012-01-212016-01-31 TPodolakLocalization, MarkupExtension, Silverlight5, WPF

W poprzednim wpisie przedstawiłem w jaki sposób można lokalizować aplikację napisaną w Silverlight 4 oraz Windows Phone, wykorzystując do tego ten sam mechanizm. Tym razem zademonstruje w jaki sposób można nieco uprościć składnie tłumaczenia wykorzystując do tego MarkupExtension.
Jeżeli kiedykolwiek pisałeś coś w Silverlighcie, Windows Phonie lub WPF-ie istnieje duża szansa, że używałeś już MarkupExtension. Do najpopularniejszych MarkupExtensions należą takie słowa kluczowe (używane w XAML-u) jak:

Binding
StaticResource
DynamicResource
TemplateBinding

Na potrzeby mechanizmu lokalizowania aplikacji WPF (ewentualnie Silverlight 5) stworzymy customowe MarkupExtenssion, które będzie odpowiedzialne za tłumaczenie elementów UI naszej aplikacji.
Zacznijmy od przygotowania plików zasobów. Podobnie jak w poprzednim wpisie utwórzmy trzy pliki:

Localization.resx
Localization.pl-PL.resx
Localization.en-US.resx

W plikach tych będziemy przechowywać nasze tłumaczenia. Następnie stwórzmy klasę Translator, która będzie dziedziczyła po klasie MarkupExtension.Do klasy tej dodajmy właściwość

public string Key{ get; set; }

1	public string Key{ get; set; }

,która będzie przechowywać klucz dzięki któremu z pliku zasobów wyciągniemy tekst w odpowiednim języku. W kolejnym kroku musimy przeciążyć funkcję

public abstract object ProvideValue(IServiceProvider serviceProvider)

1	public abstract object ProvideValue(IServiceProvider serviceProvider)

tak aby dostarczyła nam ona przetłumaczony tekst.W moim pierwszym podejściu funkcja ta wyglądała w następujący sposób

public override object ProvideValue(IServiceProvider serviceProvider)
{
    Binding binding = new Binding(Key) { Source = new Localization(),Mode = BindingMode.OneWay};
    return binding.ProvideValue(serviceProvider);
}

public override object ProvideValue(IServiceProvider serviceProvider)

{

Binding binding = new Binding(Key) { Source = new Localization(),Mode = BindingMode.OneWay};

return binding.ProvideValue(serviceProvider);

}

Wadami takiego rozwiązania było:

duża liczba tworzonych obiektów – przy każdym tłumaczeniu tworzyłem nowy obiekt Localization(), który prawdopodobnie może być dość ciężkim obiektem (zwłaszcza gdy będzie przechowywał dużo tłumaczonego tekstu)
brak możliwości dynamicznej zmiany języka

Ostatecznie zatem zrezygnowałem z przedstawionej wyżej opcji i zdecydowałem się na metodę odrobinę bardziej zaawansowaną. Po pierwsze utworzyłem klasę TranslationManager

public class TranslationManager
{
    public event Action<CultureInfo> LanguageChanged = val => { };
    private static TranslationManager _instance;
    private static readonly object LockInstance = new object();
    public static TranslationManager Instance
    {
        get
        {
            lock (LockInstance)
            {
                return _instance = _instance ?? new TranslationManager();
            }
        }
    }
    
    private CultureInfo _currentCulture;
    public CultureInfo CurrentCulture
    {
        get { return _currentCulture ?? (CurrentCulture = Thread.CurrentThread.CurrentUICulture); }
        set
        {
            _currentCulture = value;
            OnLanguageChanged(CurrentCulture);
        }
    }
    
    protected void OnLanguageChanged(CultureInfo culture)
    {
        LanguageChanged(culture);
    }
    
    private TranslationManager()
    {
    }
    
    public string Translate(string key)
    {
        return Localization.ResourceManager.GetString(key, CurrentCulture);
    }
}

public class TranslationManager

{

public event Action<CultureInfo> LanguageChanged = val => { };

private static TranslationManager _instance;

private static readonly object LockInstance = new object();

public static TranslationManager Instance

{

get

{

lock (LockInstance)

{

return _instance = _instance ?? new TranslationManager();

}

private CultureInfo _currentCulture;

public CultureInfo CurrentCulture

{

get { return _currentCulture ?? (CurrentCulture = Thread.CurrentThread.CurrentUICulture); }

set

{

_currentCulture = value;

OnLanguageChanged(CurrentCulture);

}

protected void OnLanguageChanged(CultureInfo culture)

{

LanguageChanged(culture);

}

private TranslationManager()

{

}

public string Translate(string key)

{

return Localization.ResourceManager.GetString(key, CurrentCulture);

}

która będzie zarządzała tłumaczeniami. Najważniejszą metodą tej klasy jest oczywiście funkcja

public string Translate(string key)

1	public string Translate(string key)

która to zwraca tekst w odpowiednim języku – w zależności od kultury, która zostanie ustawiona w TranslationManagerze. Ponadto TranslationManager posiada jedno zdarzenie

public event Action<CultureInfo> LanguageChanged

1	public event Action<CultureInfo> LanguageChanged

które ma za zadanie poinformować UI o potrzebie odświeżenia zbindowanych elementów. W jaki sposób się to odbywa ? Wszystko zawdzięczamy interfejsowi INotifyPropertyChanged oraz bindingom. Funkcja ProvideValue została zmodyfikowana w następujący sposób

public override object ProvideValue(IServiceProvider serviceProvider)
{
    Binding binding = new Binding("Value") { Source = new TranslationItem(Key), Mode = BindingMode.OneWay };
    return binding.ProvideValue(serviceProvider);
}

public override object ProvideValue(IServiceProvider serviceProvider)

{

Binding binding = new Binding("Value") { Source = new TranslationItem(Key), Mode = BindingMode.OneWay };

return binding.ProvideValue(serviceProvider);

}

W funkcji tej tworze binding, który binduje się do właściwości Value obiektu TranslationItem. TranslationItem jest to prosty obiekt który udostępnia właściwość Value zwracającą przetłumaczony tekst. Dodatkowo obiekt ten podpina się do zdarzenia LanguageChanged z klasy TranslationManager. W przypadku gdy ktoś zmieni język aplikacji, odpalone zostanie zdarzenie NotifyPropertyChanged, które poinformuje widok o potrzebie odświeżenia odpowiednich elementów. Klasa TranslationItem wygląda zatem w następujący sposób

public sealed class TranslationItem : INotifyPropertyChanged, IDisposable
{
    public event PropertyChangedEventHandler PropertyChanged = delegate { };
    private readonly string _key;
    public TranslationItem(string key)
    {
        _key = key;
        TranslationManager.Instance.LanguageChanged += Instance_LanguageChanged;
    }

    ~TranslationItem()
    {
        Dispose();
    }

    void Instance_LanguageChanged(System.Globalization.CultureInfo obj)
    {
        PropertyChanged(this, new PropertyChangedEventArgs("Value"));
    }

    public string Value
    {
        get { return TranslationManager.Instance.Translate(_key); }
    }

    public  void Dispose()
    {
        TranslationManager.Instance.LanguageChanged -= Instance_LanguageChanged;
    }
}

public sealed class TranslationItem : INotifyPropertyChanged, IDisposable

{

public event PropertyChangedEventHandler PropertyChanged = delegate { };

private readonly string _key;

public TranslationItem(string key)

{

_key = key;

TranslationManager.Instance.LanguageChanged += Instance_LanguageChanged;

}

~TranslationItem()

{

Dispose();

}

void Instance_LanguageChanged(System.Globalization.CultureInfo obj)

{

PropertyChanged(this, new PropertyChangedEventArgs("Value"));

}

public string Value

{

get { return TranslationManager.Instance.Translate(_key); }

}

public void Dispose()

{

TranslationManager.Instance.LanguageChanged -= Instance_LanguageChanged;

}

Mając gotowy mechanizm tłumaczący możemy wykorzystać go w następujący sposób w XAML-u

<Label Content="{WPFMarkupExtension:Translator Key=Title}"/>

1	<Label Content="{WPFMarkupExtension:Translator Key=Title}"/>

Zauważmy, że tekst do labelki jest przypisywany z wykorzystywaniem naszego customoweog MarkupExtension – WPFMarkupExtension:Translator (WPFMarkupExtension – jest to alias na namespace, w którym znajduje się nasza klasa Translator). W składni przekazujemy do właściwości Key klucz do tekstu (znajdującego się w resourcach), który chcemy tłumaczyć. W celu zmiany języka wystarczy, że ustawimy interesującą nas kulturę w klasie TranslationManager

TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US")

1	TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US")

Przykładowy widok wykorzystujący napisany translator, oraz pokazujący dynamiczną zmianę języka może wyglądać w następujący sposób (dorzucamy następujące linijki do MainWindow.xaml)

<StackPanel>
    <Label Content="{WPFMarkupExtension:Translator Key=Key}"/>
    <Button Command="{Binding PolishCommand}">Polski</Button>
    <Button Command="{Binding EnglishCommand}">English</Button>
</StackPanel>

<Button Command="{Binding PolishCommand}">Polski</Button>

<Button Command="{Binding EnglishCommand}">English</Button>

</StackPanel>

Następnie tworzymy ViewModel do naszego okna

public class MainPageViewModel
{
        public DelegateCommand PolishCommand { get; set; }
        public DelegateCommand EnglishCommand { get; set; }
        
        public MainPageViewModel()
        {
            PolishCommand = new DelegateCommand(()=> TranslationManager.Instance.CurrentCulture = new CultureInfo("pl-PL"));
            EnglishCommand = new DelegateCommand(()=>TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US"));
        }
}

public class MainPageViewModel

{

public DelegateCommand PolishCommand { get; set; }

public DelegateCommand EnglishCommand { get; set; }

public MainPageViewModel()

{

PolishCommand = new DelegateCommand(()=> TranslationManager.Instance.CurrentCulture = new CultureInfo("pl-PL"));

EnglishCommand = new DelegateCommand(()=>TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US"));

}

Ostatecznie przypisujemy obiekt klasy MainPageViewModel do DataContextu MainWindow.xaml

public MainWindow()
{
    InitializeComponent();
    DataContext = new MainPageViewModel();
}

public MainWindow()

{

InitializeComponent();

DataContext = new MainPageViewModel();

}

Kod do projektu można znaleźć pod tym linkiem
http://www.4shared.com/rar/SwDXay7V/WPFMarkupExtension.html

Silverlight – koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.3 – Microsoft Enterprise Library Security Block

2012-01-062016-01-31 TPodolakAuthentication, Enterprise Library, Roles, Security Block, Silverlight, WCF

W tym wpisie postaram się krótko przedstawić blok bezpieczeństwa (Security Block) z biblioteki Microsoft Enterprise Library.
Biblioteki tej użyjemy do sprawdzania rol i reguł dostępu do funkcji serwisu WCF. Najpierw oczywiście musimy pobrać bibliotekę Microsoft Enterprise Library, znajduje się ona pod tym adresem.
http://www.microsoft.com/download/en/details.aspx?id=15104. Biblioteka ta jest również dostępna z poziomu NuGeta, jednakże instalacja poprzez ten plugin dorzuca do projektu tylko dll-ki. W pierwszym przypadku natomiast oprócz dll-ek zostaje również zainstalowane bardzo wygodne narzędzie ułatwiające konfigurację różnych modułów biblioteki.
Mając zainstalowane wszystkie potrzebne komponenty możemy przystąpić do działania. Zacznijmy od zmodyfikowania pliku Web.config, tak aby umożliwić naszemu systemowi korzystanie z ról – a tak właściwie aby umożliwić edycję, tworzenie, usuwanie oraz przypisywanie ról użytkownikom.W sekcji

<system.web>

1	<system.web>

dorzucamy następujące wpisy

<roleManager enabled="true" defaultProvider="SqlProvider">
      <providers>
        <clear />
        <add connectionStringName="aspnetdbConnectionString" name="SqlProvider"
          type="System.Web.Security.SqlRoleProvider" />
      </providers>
</roleManager>

<add connectionStringName="aspnetdbConnectionString" name="SqlProvider"

type="System.Web.Security.SqlRoleProvider" />

</providers>

</roleManager>

W tym momencie dodaliśmy do kolekcji menadżerów ról (Role managers) nowy provider -nie jest to jednak MembershipProvider lecz RoleProvider, a dokładniej dostarczony przez framework SqlRoleProvider. Provider ten jest przystosowany do działania na bazie danych o takiej strukturze, jak baza, którą stworzyliśmy w części pierwszej. Po konfiguracji providera przyszedł czas na dodanie przykładowego użytkownika oraz przypisanie mu jakiejś roli. Wybieramy opcję “ASP.NET Configuration” z menu “Project”, następnie na stronie na którą zostaniemy przeniesieni, przechodzimy na zakładkę “Security”

W kolejnym kroku dodajemy role – klikamy w “Create or Manage roles”,a w stronie, która się otworzy wpisujemy nazwę roli np.”Developer”. Postępując w podobny sposób dodajmy jeszcze role “Admin”. Następnie tworzymy użytkownika – klikamy w “Create user”, a następnie wypełniamy pola podobnie jak na załączonym poniżej screenie

Mając stworzonego przykładowego użytkownika możemy przystąpić do ograniczenia dostępu do niektórych funkcji naszego serwisu. W tym celu, po pierwsze modyfikujemy funkcję logowania.

 protected UserDTO ValidateCredentials(string name, string password, string customData, out string userData)
 {
     UserDTO user = null;
     userData = null;
     if (Membership.Providers[customData].ValidateUser(name, password))
     {
         userData = name;
         user = new UserDTO { DisplayName = name, Name = name, Email = name, Roles = Roles.GetRolesForUser(name) };
     }
     
     if (user != null) userData = name;
     
     return user;
 }

protected UserDTO ValidateCredentials(string name, string password, string customData, out string userData)

{

UserDTO user = null;

userData = null;

if (Membership.Providers[customData].ValidateUser(name, password))

{

userData = name;

user = new UserDTO { DisplayName = name, Name = name, Email = name, Roles = Roles.GetRolesForUser(name) };

}

if (user != null) userData = name;

return user;

}

Jak widać, przy tworzeniu użytkownika dodatkowo pobieramy z bazy danych jego wszystkie role. Statyczna funkcja GetRolesForUser pobiera role przy pomocy domyślnego RoleProvidera.
Dodajmy teraz do naszego DataAccesService-u dwie funkcje.

OnlyAdminCanDownloadThis
DevelopersCanDownloadThis

Dane pobierane przez pierwszą funkcję mogą być odczytane jedynie przez użytkowników, którzy są administratorami systemu. Natomiast dane z funkcji drugiej mogą być odczytane przez developerów (oczywiście admin również może pobrać te dane). Zastanówmy się teraz w jaki sposób sprawdzić czy dany użytkownik ma dostęp do danych. Możemy sprawdzać role ręcznie (niewygodne), użyć znanego z ASP.NET atrybutu PrincipalPermission (mało elastyczne) lub skorzystać z Microsoft Enterprise Library (całkiem dobra opcja). Security Block z biblioteki Microsoft Enterprise Library ma tę przewagę nad wcześniej wspomnianymi rozwiązaniami, że wprowadza on tzw. reguły(Rules). Dzięki nim możemy w łatwy sposób zdefiniować warunki jakie musi spełnić użytkownik aby zezwolić mu na dostęp w jakieś miejsce systemu. Skonfigurujmy zatem prostą regułę – regułą ta pozwoli na dostęp do danych jedynie tym użytkownikom,którzy mają prawo administratora. Klikamy PPM na plik Web.config i wybieramy z niego opcję “Edit Enterprise Library V5 Configuration” – opcja ta została dodana po instalacji biblioteki Microsoft Enterprise Library.

W oknie które się otworzy wybieramy “Add Security Settings” z menu “Blocks”.

W głównym oknie aplikacji pojawi się nowy element – “Security Settings”. Klikamy na znak “+” obok “Authorization Providers”, następnie z rozwiniętego menu przechodzimy na “Add Authorization Providers” i ostatecznie klikamy na “Add Authorization Rule Provider”

W ten sposób dodaliśmy domyślny “Rule Provider”, teraz możemy stworzyć reguły dostępu do naszej aplikacji. W tym celu musimy kliknąć w lewy dolny róg pola “Authorization Rule Provider”, a następnie z menu, które się pojawi wybrać “Add Authorization Rule”

W oknie aplikacji pojawi się nowy element – “Authorization Rule”, nadajmy mu nazwę “DevelopersOnly”, a następnie zdefiniujmy tzw. “Rule expression”. “Rule expression” jest warunek jaki musi zostać spełniony, aby użytkownik uzyskał dostęp do części aplikacji chronionej przez regułę “DevelopersOnly”. Wyrażenie to możemy wpisać ręcznie, lub poprzez prosty kreator – dostępny jest on pod przyciskiem “…”.
Stwórzmy więc regułę, która pozwoli tylko użytkownikom typu Developer oraz oczywiście adminowi mieć dostęp do jakieś części aplikacji. Otwórzmy zatem “Rule Expression Editor” (dostępny on jest pod przyciskiem “…”), kliknijmy na przycisk “Role”, wpiszmy “Developer”, następnie kliknijmy w przycisk “OR”, wpiszmy “Admin”.Możemy również wpisać następujące wyrażenie ręcznie

R:Developer OR R:Admin

1	R:Developer OR R:Admin

Stworzyliśmy zatem regułę pozwalającą na dostęp użytkownikom typu Developer (R:Developer) oraz administratorom (R:Admin). Aby zatwierdzić zmiany wybieramy “Save” z menu “File”. W pliku Web.config pojawiły się teraz następujące linijki

<securityConfiguration>
    <authorizationProviders>
      <add type="Microsoft.Practices.EnterpriseLibrary.Security.AuthorizationRuleProvider, Microsoft.Practices.EnterpriseLibrary.Security, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        name="Authorization Rule Provider">
        <rules>
          <add expression="R:Developer OR R:Admin" name="DevelopersOnly" />
        </rules>
      </add>
    </authorizationProviders>
</securityConfiguration>

<add type="Microsoft.Practices.EnterpriseLibrary.Security.AuthorizationRuleProvider, Microsoft.Practices.EnterpriseLibrary.Security, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

name="Authorization Rule Provider">

<rules>

</rules>

</add>

</authorizationProviders>

</securityConfiguration>

Do powyżej konfiguracji musimy jeszcze dorzucić wybór domyślnego providera – dodajmy zatem następujący wpis do linii

defaultAuthorizationInstance="Authorization Rule Provider"

1	defaultAuthorizationInstance="Authorization Rule Provider"

Wykorzystajmy teraz stworzoną właśnie regułę aby zabezpieczyć wspomnianą wcześniej funkcję “DevelopersCanDownloadThis”. Po pierwsze stwórzmy pomocniczą klasę pomocniczą SecurityHelper i dodajmy do niej metodę IsAuthorized, która wygląda w następujący sposób:

public static bool IsAuthorized(this IPrincipal principal, string rule)
{
    IAuthorizationProvider ruleProvider = EnterpriseLibraryContainer.Current.GetInstance<IAuthorizationProvider>();
    return ruleProvider.Authorize(principal, rule);
}

public static bool IsAuthorized(this IPrincipal principal, string rule)

{

IAuthorizationProvider ruleProvider = EnterpriseLibraryContainer.Current.GetInstance<IAuthorizationProvider>();

return ruleProvider.Authorize(principal, rule);

}

Następnie w funkcji “DevelopersCanDownloadThis” musimy sprawdzić czy użytkownik może wykorzystać tą funkcję – w tym celu wykorzystujemy funkcję IsAuthorized. Może wyglądać to w następujący sposób

public string DevelopersCanDownloadThis()
{
    if (ServiceContext.User.IsAuthorized("DevelopersOnly"))
        return "very secure data";
    throw new PermisionDeniedException("Brak dostępu");
}

public string DevelopersCanDownloadThis()

{

if (ServiceContext.User.IsAuthorized("DevelopersOnly"))

return "very secure data";

throw new PermisionDeniedException("Brak dostępu");

}

Logując się na użytkownika, który posiada prawo/rolę “Developer” będziemy mogli pobrać dane wykorzystując funkcję “DevelopersCanDownloadThis” w przeciwnym razie do klienta zostanie rzucony wyjątek z odpowiednim komunikatem. Niestety Security Block nie został jeszcze przeniesiony na platformę Silverlightową, zatem przedstawionych powyżej sposobów sprawdzania praw dostępu(np. do jakiejś funkcjonalności) nie możemy zastosować po stronie klienta.

Silverlight – koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.2

2011-12-252016-01-31 TPodolakAuthentication, Authorization, Silverlight, WPF

W poprzednim wpisie przedstawiłem w jaki sposób zaimplementować mechanizm logowania po stronie serwera. Wykorzystałem do tego celu WCF RIA oraz znane z ASP MembershipProvidery. Tym razem przedstawię jak wymusić logowanie po stronie klienta, oraz w jaki sposób można dynamicznie zmieniać providerów, którzy walidują usera.
Poprzednim razem stworzyliśmy już szkielet aplikacji, zatem mamy projekt klienta oraz projekt serwera. Zacznijmy od “włączenia” FormsAuthentication po stronie klienta. W pliku App.xaml.cs , w konstruktorze dorzućmy następujące linijki

WebContext context = new WebContext {Authentication = new FormsAuthentication()};
ApplicationLifetimeObjects.Add(context);

1 2	WebContext context = new WebContext {Authentication = new FormsAuthentication()}; ApplicationLifetimeObjects.Add(context);

Następnie zanim pokażemy treść naszej strony, musimy sprawdzić czy użytkownik jest zalogowany.Jeżeli nie, należy pokazać okno logowania. Możemy to zrobić w następujący sposób.

if (!WebContext.Current.User.IsAuthenticated)
{
    ModalDialogService.ShowDialog(_unityContainer.Resolve<IModalView<LoginViewModel>>(),
                                  val => { InitializeView();GetSecureData(); });
}
else
{
    InitializeView();
    GetSecureData();
}

if (!WebContext.Current.User.IsAuthenticated)

{

ModalDialogService.ShowDialog(_unityContainer.Resolve<IModalView<LoginViewModel>>(),

val => { InitializeView();GetSecureData(); });

}

else

{

InitializeView();

GetSecureData();

}

WebContext jest to klasa generowana automatycznie przy buildowaniu solucji.Jej kod powinniśmy odnaleźć w katalogu Generated_Code po stronie klienta. Klasa ta posiada właściwość Current, która zwraca obecny context zarejestrowany w kolekcji ApplicationLifetimeObjects.
Okno logowania zostało zaimplementowane jako ChildWindow. Jego kod może wyglądać w następujący sposób

<Grid x:Name="LayoutRoot" Margin="2">
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition Height="Auto" />
        </Grid.RowDefinitions>
        <StackPanel VerticalAlignment="Center">
            <sdk:Label Content="Login"></sdk:Label>
            <TextBox Text="{Binding Login,NotifyOnValidationError=True,Mode=TwoWay}" >
               
            </TextBox>
            <sdk:Label Content="Hasło"</sdk:Label>
            <PasswordBox  Password="{Binding Password,NotifyOnValidationError=True,Mode=TwoWay}" >
            </PasswordBox>
        </StackPanel>
        <Button x:Name="CancelButton" Content="Cancel" Click="CancelButton_Click"  Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,0,0" Grid.Row="1" />
        <Button x:Name="OKButton" Content="OK" Command="{Binding OkCommand}" Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,79,0" Grid.Row="1" />
</Grid>

<Grid.RowDefinitions>

</Grid.RowDefinitions>

<sdk:Label Content="Login"></sdk:Label>

</TextBox>

<sdk:Label Content="Hasło"</sdk:Label>

</PasswordBox>

</StackPanel>

</Grid>

Kontrolka logowania jest bardzo prosta, składa się ona z dwóch labelek, textboxa oraz passwordBoxa. Powyższy kod powinien wygenerować mniej więcej takie oto okno

Mechanizm wywoływania operacji logowania znajduje się natomiast w ViewModelu kontrolki logowania. Po naciśnięciu przycisku OK, dzięki zastosowaniu DelegateCommand uruchamiany następującą funkcję

private void OkCommandExecuted()
{
    if (Validate())
    {
        PerfomrLoginOperation();
    }
}

private void OkCommandExecuted()

{

if (Validate())

{

PerfomrLoginOperation();

}

W funkcji tej najpierw sprawdzamy, czy użytkownik podał dane do logowania, a następnie wywołujemy kolejną funkcję PerfomrLoginOperation. Przedstawia się w następujący sposób

private void PerfomrLoginOperation()
{      
    WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,string.Empty, CompleteLoginOperation, Guid);
}

private void PerfomrLoginOperation()

{

WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,string.Empty, CompleteLoginOperation, Guid);

}

Widzimy zatem, że wywołujemy funkcję logowania z serwisu WCF, w parametrach natomiast podajemy login oraz hasło przechwycone z okna. Dodatkowo w parametrze podajemy delegata do funkcji, która zostanie wykonana po zakończeniu operacji logowania.

private void CompleteLoginOperation(LoginOperation loginOperation)
{
    if (loginOperation.Error == null)
        OnOperationCompleted();
    else
    {
        if (loginOperation.Error is FormsAuthenticationLogonException)
            MessageBoxService.ShowMessageBox("Nieprawidłowy login lub hasło", MessageBoxButton.OK);
        else
            MessageBoxService.ShowMessageBox("Wystąpił problem podczas operacji logowania",
                                             MessageBoxButton.OK);
    }
}

private void CompleteLoginOperation(LoginOperation loginOperation)

{

if (loginOperation.Error == null)

OnOperationCompleted();

else

{

if (loginOperation.Error is FormsAuthenticationLogonException)

MessageBoxService.ShowMessageBox("Nieprawidłowy login lub hasło", MessageBoxButton.OK);

else

MessageBoxService.ShowMessageBox("Wystąpił problem podczas operacji logowania",

MessageBoxButton.OK);

}

Jeżeli odpowiedź z serwisu WCF zawiera błędy to wiemy, że operacja logowania się nie powiodła. Wyświetlamy zatem stosowny komunikat. Jeżeli natomiast wszystko jest Ok, pole loginOperation.Error będzie miało wartość null. Możemy wtedy pokazać naszą wiadomość dostępną jedynie dla zalogowanych użytkowników.
Mamy zatem ochronę przeciwko nieautoryzowanemu dostępowi do klienta. Jednak co w przypadku gdy nasz klient musi w calach np. zassania danych pobrać je przy wykorzystaniu jakiegoś WebServicu. Na ogól wystawiany jest wtedy drugi WebService do pobierania danych z jakiejś bazy. Do takiego WebServicu w teorii może dostać się każdy – my natomiast chcemy żeby dane można było pobierać jedynie po zalogowaniu się do aplikacji. Na szczęście nasz dodatkowy WebServise można w prosty sposób zabezpieczyć przed dostępem osób trzecich. Stwórzmy zatem sobie nowy WebService służący do pobierania danych. Do projektu Webowego dodajmy nową klasę typu “Domain Service” oraz dopiszmy do nie jedną metodę symulującą pobieranie danych.

[EnableClientAccess()]
public class DataAccesService : DomainService
{
    public string GetSecureData()
    {
        return "very secure data";
    }
}

[EnableClientAccess()]

public class DataAccesService : DomainService

{

public string GetSecureData()

{

return "very secure data";

}

Do takiego Servicu może dostać się każdy. Jeżeli natomiast naszą klasę udekorujemy atrybutem [RequiresAuthentication()] tylko użytkownicy, którzy pomyślnie przeszli autentykację przez nasz CustomAuthenticationService będą w stanie pobrać dane. W przeciwnym wypadku zostanie rzucony wyjątek.

Zastanówmy się teraz w jaki sposób można byłoby logować się do naszej aplikacji np. przy pomocy konta Google. Zacznijmy od tego, że musimy stworzyć własny MembershipProvider. W tym celu dodajmy do projektu Webowego nową klasę “GoogleMembershipProvider“, która będzie rozszerzać klasę MembershipProvider. Klasa MembershipProvider jest klasą abstrakcyjną zatem musimy zoverridować wszystkie jej funkcje (nie musimy wrzucać tam logiki, narazie po prostu wpiszmy tam cokolwiek aby przeszła kompilacja). Mając stworzony szkielet providera musimy go dorzucić do listy wszystkich providerów (tak jak to zrobiliśmy z SqlMembershipProvider-em). Modyfikujemy zatem sekcję podsekcję providers z sekcji membership na następującą.

<membership
            defaultProvider="PremiumHandsMembershipProvider"
            userIsOnlineTimeWindow="20">
      <providers>
        <clear/>
        <add name="PremiumHandsMembershipProvider"
             connectionStringName="aspnetdbConnectionString"
            type="System.Web.Security.SqlMembershipProvider"
            enablePasswordRetrieval="false"
            enablePasswordReset="false"
            requiresQuestionAndAnswer="true"
            passwordFormat="Hashed"
            applicationName="/" />
        <add name="GoogleMembershipProvider"
             type="MainModule.Web.Providers.GoogleMembershipProvider"
             enablePasswordRetrieval="false"
            enablePasswordReset="false"
            requiresQuestionAndAnswer="true"
            passwordFormat="Hashed"
            applicationName="/"
             />
      </providers>
</membership>

<membership

defaultProvider="PremiumHandsMembershipProvider"

userIsOnlineTimeWindow="20">

<add name="PremiumHandsMembershipProvider"

connectionStringName="aspnetdbConnectionString"

type="System.Web.Security.SqlMembershipProvider"

enablePasswordRetrieval="false"

enablePasswordReset="false"

requiresQuestionAndAnswer="true"

passwordFormat="Hashed"

applicationName="/" />

<add name="GoogleMembershipProvider"

type="MainModule.Web.Providers.GoogleMembershipProvider"

enablePasswordRetrieval="false"

enablePasswordReset="false"

requiresQuestionAndAnswer="true"

passwordFormat="Hashed"

applicationName="/"

</providers>

</membership>

Mając w kolekcji wszystkie nasze providery pozostaje nam się zastanowić, w jaki sposób raz używać GoogleMembershpProvidera, a innym razem SqlMembershipProvidera. Ja zrobiłem to w następujący sposób. Najpierw utworzyłem enuma, w którym przechowuje “nazwy” moich providerów

public enum AccountType
{
    PremiumHandsMembershipProvider,
    GoogleMembershipProvider,
    Facebook
}

public enum AccountType

{

PremiumHandsMembershipProvider,

GoogleMembershipProvider,

Facebook

}

Następnie wykorzystałem parametr customData interfejsu IAuthentication. Po stronie klienta w funkcji logowania po prostu przesyłam typ konta do którego się loguję. Wygląda to w ten sposób:

 WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,AccountType.GoogleMembershipProvider.ToString("g")), CompleteLoginOperation, Guid);

1	WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,AccountType.GoogleMembershipProvider.ToString("g")), CompleteLoginOperation, Guid);

Następnie po stronie serwera wybieram tego providera, przez którego loguje się użytkownik.

protected UserDTO ValidateCredentials(string name, string password, string customData, out string userData)
{
    UserDTO user = null;
    userData = null;
    if (Membership.Providers[customData].ValidateUser(name, password))
    //if (Membership.Provider.ValidateUser(name, password))
    {
        userData = name;
        user = new UserDTO { DisplayName = name, Name = name, Email = name};
    }
    if (user != null) userData = name;
    return user;
}

protected UserDTO ValidateCredentials(string name, string password, string customData, out string userData)

{

UserDTO user = null;

userData = null;

if (Membership.Providers[customData].ValidateUser(name, password))

//if (Membership.Provider.ValidateUser(name, password))

{

userData = name;

user = new UserDTO { DisplayName = name, Name = name, Email = name};

}

if (user != null) userData = name;

return user;

}

Zauważmy, że linijka

if (Membership.Provider.ValidateUser(name, password))

1	if (Membership.Provider.ValidateUser(name, password))

została zastąpiona przez

if (Membership.Providers[customData].ValidateUser(name, password))

1	if (Membership.Providers[customData].ValidateUser(name, password))

zatem teraz mamy wpływ na to, którego MembershipProvidera użyjemy. Jeżeli chodzi o samo sprawdzenie czy dany użytkownik podał poprawne dane do konta google, to sprawa jest trochę kłopotliwa(tak mi się wydaje :D). Nie udało mi się użyć biblioteki dotNetOpenAuth, gdyż z tego co widzę logowanie poprzez tą bibliotekę wymaga przekierowania na stronę Googla. Niestety taka operacja nie jest dozwolona w Silverlighcie (Silverlight nie wspiera cross-domain policy). Ponadto wykorzystanie tej biblioteki po stronie serwera również nie przyniosło oczekiwanych rezultatów. Ostatecznie zatem skorzystałem z opisu znajdującego się na stronie Googla http://code.google.com/intl/pl-PL/apis/accounts/docs/AuthForInstalledApps.html#Using. Czyli po prostu spreparowałem odpowiedni HTTPS Post Request. Funkcja ValidateUser z GoogleMembershipProvidera wygląda zatem następująco

public override bool ValidateUser(string username, string password)
{
    string requestUrl = string.Format("https://www.google.com/accounts/ClientLogin?service=mail&Email={0}&Passwd={1}", username, password);
    byte[] data = Encoding.ASCII.GetBytes(requestUrl);
    HttpWebRequest req = (HttpWebRequest)WebRequest.Create(requestUrl);
    req.ProtocolVersion = HttpVersion.Version10;
    req.ContentLength = data.Length;
    req.ContentType = "application/x-www-form-urlencoded";
    req.Method = "POST";
    var stream = req.GetRequestStream();
    stream.Write(data,0,data.Length);
    stream.Close();
    
    try
    {
        HttpWebResponse response = (HttpWebResponse)req.GetResponse();
        return response.StatusCode == HttpStatusCode.OK;
    }
    catch (WebException e)
    {
        return false;
    }
}

public override bool ValidateUser(string username, string password)

{

string requestUrl = string.Format("https://www.google.com/accounts/ClientLogin?service=mail&Email={0}&Passwd={1}", username, password);

byte[] data = Encoding.ASCII.GetBytes(requestUrl);

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(requestUrl);

req.ProtocolVersion = HttpVersion.Version10;

req.ContentLength = data.Length;

req.ContentType = "application/x-www-form-urlencoded";

req.Method = "POST";

var stream = req.GetRequestStream();

stream.Write(data,0,data.Length);

stream.Close();

try

{

HttpWebResponse response = (HttpWebResponse)req.GetResponse();

return response.StatusCode == HttpStatusCode.OK;

}

catch (WebException e)

{

return false;

}

Ciężko mi jednak stwierdzić czy takie logowanie jest bezpieczne. Co prawda nie udało mi się wyłapać nic konkretnego poprzez Wiresharka lub Fiddlera, jednakże ekspertem od zabezpieczeń niestety nie jestem.
W następnym wpisie postaram się króciutko przedstawić bibliotekę Microsoft Enterprise Library, a właściwie jeden z jej bloków – Security Block.Wykorzystam go do zezwalania użytkownikom do dostępu do funkcji serwisu, w zależności od ich roli w systemie.

.NET BLOG

.NET, C# blog

ASP.NET MVC – okna modalne z wykorzystaniem Kendo UI

Lokalizowanie aplikacji Silverlight i Windows Phone z wykorzystaniem Portable Shared Library

Lokalizowanie aplikacji WPF oraz Silverlight 5 przy użyciu MarkupExtension

Silverlight – koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.3 – Microsoft Enterprise Library Security Block

Silverlight – koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.2