Browsed by
Month: March 2016

Mocking EntityFramework context – Code First

Mocking EntityFramework context – Code First

mocking_ef
Source

When I first try to write test for class that use directly, I found that I can’t mock database context directly using for example Moq library. That’s because this class properties isn’t virtual. After some research I found that EF6 could be set up to enable mocking [1,2]. However that is not quite what I need. I had some specific requirements:

  1. I want to trace operations into database tables
  2. It must work for Code First EF6 configuration
  3. It should be generic solution for each database table

Let’s try to satisfy first requirement. We need some method to store all data our mocked object. I decided to write in-memory DbSet object like in [2] link.

public class FakeDbSetKeyed<T, TKey> : DbSet<T>, IQueryable, IEnumerable<T>
    where T : class, IKey<TKey>
{
    Dictionary<TKey, T> _data;
    IQueryable _query;
    public FakeDbSetKeyed()
    {
        _data = new Dictionary<TKey, T>();
        _query = _data.Values.AsQueryable();
    }

    public override T Find(params object[] keyValues)
    {
        return _data[(TKey)keyValues.First()];
    }

    public override T Add(T item)
    {
        _data.Add(item.Id, item);
        return item;
    }

    public override T Remove(T item)
    {
        _data.Remove(item.Id);
        return item;
    }

    public override T Attach(T item)
    {
        if (_data.ContainsKey(item.Id))
        {
            _data[item.Id] = item;
        }
        else
        {
            _data.Add(item.Id, item);
        }
        return item;
    }

    public T Detach(T item)
    {
        _data.Remove(item.Id);
        return item;
    }

    public override T Create()
    {
        return Activator.CreateInstance<T>();
    }

    public override TDerivedEntity Create<TDerivedEntity>()// where TDerivedEntity : class, T
    {
        return Activator.CreateInstance<TDerivedEntity>();
    }

    public override ObservableCollection<T> Local
    {
        get { return new ObservableCollection<T>(_data.Values); }
    }

    Type IQueryable.ElementType
    {
        get { return _query.ElementType; }
    }

    System.Linq.Expressions.Expression IQueryable.Expression
    {
        get { return _query.Expression; }
    }

    IQueryProvider IQueryable.Provider
    {
        get { return _query.Provider; }
    }

    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
    {
        return _data.GetEnumerator();
    }

    IEnumerator<T> IEnumerable<T>.GetEnumerator()
    {
        return _data.Values.GetEnumerator();
    }

    public void Clear()
    {
        _data.Clear();
    }
}

You can see two addition to original class definition from MSDN. I added also one additional method (Clear) for purpose of easier operate data sets during testing and also I added generic parameter TKey to specify key type. That enables me to write Find method.

Next, we consider second point of requirement – Code First compatibility. In mentioned MSDN articles we can set up mock for DbContext, but for Code First approach there isn’t work. That’s because during the creation of Mock parameterless constructor is executed. Thus the database could be created each time when we start single test and it is not acceptable and very time consuming. To solve it, I must create fake DbContext.

Let’s suppose that we have following DbContext

public class ItemsContext : DbContext
{
    public ItemsContext()
        : base("DatabaseName")
    {
    }

    public virtual DbSet<User> Users { get; set; }

    public virtual DbSet<Item> Items { get; set; }
}

This context isn’t ready to support its different implementation yet. So I defined interface IItemsContext with sets defined in main context class. I also implement IItemsContext in ItemsContext and change application to use interface beside of specific class.

public interface IItemsContext
{
    DbSet<User> Users { get; set; }
    DbSet<Item> Items { get; set; }
}

public class ItemsContext : DbContext, IItemsContext
{
    public ItemsContext()
        : base("DatabaseName")
    {
    }

    public virtual DbSet<User> Users { get; set; }
    public virtual DbSet<Item> Items { get; set; }
}

Thanks to this modifications in program structure I can write test initializations just like this:

[TestInitialize]
public virtual void TestInitialize()
{
    _dataSet = new FakeDbSetKeyed<TEntity, TKey>();
    var mockContext = new Mock<IBwEntities>(MockBehavior.Strict
    mockContext.Setup(c => c.Set<TEntity>()).Returns(_dataSet);
    _dataSet.Clear();
}

With this set up we fill _dataSet and operate on DbContext (ItemsContext for us) in tests in order to check _dataSet for the results of tested actions.

[1] https://msdn.microsoft.com/en-us/data/dn314429.aspx
[2] https://msdn.microsoft.com/en-us/data/dn314431.aspx

OWASP AppSensor .NET – architektura

OWASP AppSensor .NET – architektura

owasp-architektura
Źródło

Po dokładnym opisaniu mechanizmu czas na przedstawienie planowanego rozwiązania AppSensor.NET – architektura jest jedną z istotniejszych składowych projektu. Warto też zdefiniować jego cel oraz zestaw kroków, które zawiodą mnie do jego wykonania.

Założenia i funkcjonalności MVP

Zacznijmy więc od zdefiniowania funkcjonalności, które chcemy osiągnąć w projekcie. Oczywiście można założyć, że docelowo chcielibyśmy zaimplementować spójny mechanizm OWASP AppSensor w pełnym jego zakresie, z implementacją wszystkich zdefiniowanych punktów detekcji i integracji z innymi systemami. Jednak z doświadczenia wiem już, że ten sposób określania wymagań nie jest dobry, bo dość słabo motywuje do pracy i do skończenia projektu. Zamiast tego zdefiniujemy MVP naszego projektu.

MVP (Minimum Viable Product) jest to pojęcie zaczerpnięte z metodologii Lean Management (szczupłego zarządzania). Według tej koncepcji pierwsza wersja projektu powinna być jak najmniejsza i udostępniać tylko najważniejsze funkcjonalności. W szczególności jedną funkcjonalność. Dzięki temu można stosunkowo szybko stworzyć projekt, który będziemy dalej rozwijać. Możliwość szybkiego zbudowania czegoś działającego daje sporo motywacji i zapału do tworzenia. Dodatkowo po powstaniu MVP możemy zdecydować, w którą stronę chcemy rozwijać dalej nasz projekt.

Tak więc lista funkcjonalności MVP:

  • bazowy silnik do przechowywania logów (przechowywanie w bazie danych),
  • biblioteka do konfiguracji zasad wykrywania i progów (konfiguracja z kodu),
  • implementacja 3 najpopularniejszych puktów detekcji:
    • RE1: Unexpected HTTP Command
    • RE3: GET When Expecting POST
    • RE4: POST When Expecting GET
  • implementacja 3 metod reakcji:
    • logowanie informacji
    • wylogowanie
    • blokowanie użytkownika

Składowe systemu

Bazując na szczegółowym opisie technologii OWASP AppSensor można podzielić projekt na niżej wymienione moduły. Każdy z nich postaram się zaimplementować jako oddzielną bibliotekę.

  • Biblioteka do rejestrowania punktów wykrywania (z regułami – z możliwością wyniesienia konfiguracji poza aplikację):
    • definicje punktów detekcji
    • definicje sposobów reakcji
  • Biblioteka do automatycznego podpinania punktów wykrywania do WebAPI
  • Biblioteka rejestrująca zdarzenia podejrzane
  • Serwer logowania (własny i integracje z gotowymi w chmurze) [Kibana, Analogi, Loggly, Splunk]
  • Pulpit podsumowujący zagrożenia w czasie rzeczywistym
  • Aplikacja demonstracyjna
  • Testy dla aplikacji demonstracyjnej

Planowane zadania

Zadania, którymi się zajmuję będę na bieżąco rejestrował w odpowiedniej planszy Trello. Podzieliłem je na 5 grup:

  • Planned – pomysły
  • ToDo – do zrobienia w najbliższym czasie
  • In progress – w trakcie implementacji
  • Done – zrobione
  • Released – skończone i zamknięte w nowej wersji biblioteki

Implementację zacznę od warstwy testowania zagrożeń, przez aplikację demonstracyjną, aż do implementacji samych mechanizmów wewnętrznych. Nie będę tutaj wypisywał konkretnej listy zadań, bo jest ona dostępna publicznie i z natury dość dynamiczna.

Do dzieła 🙂

AppVeyor – Continues Integration for .NET/JavaScript – configuration

AppVeyor – Continues Integration for .NET/JavaScript – configuration

AppVeyor
Source

Some time ago I have been looking for some Continuous Integration engine for my Open Source project hosted on GitHub. I found a list of popular services https://github.com/ligurio/Continuous-Integration-services/blob/master/continuous-integration-services-list.md. My general requirement was support to JavaScript and .NET projects. Moreover it should be possible to run tests within this engine. I want to ensure the quality of my projects and I want to be able to detect failing test as quickly as possible after each commit. Also it would be nice to have a method to run deployment directly from this service.

After analysis of few different services I have chosen AppVeyor, because it meets all my expectations. This is a simple on-line service which is free for public projects hosted on GitHub, Bitbucket or VisualStudio Online.

Configuration for different project types

.NET

For .NET application the most important feature is just to build whole solution and run tests for specifics projects. That’s what we want to configure.

I will explain the configuration on example public GitHub project.

At first, we should add a project to our account.

Add project in AppVeyor

Then we can test, if build for this project succeed. Probably not, because we didn’t configure NuGet for our project. Generally NuGet should be configured to don’t store all packages on repository. Then it can be automatically downloaded by this package manager. That’s why we should tell AppVeyor to download this package before building the project. We should only add a special script to execute before build in Build tab in Configuration options.

nuget restore

Configure NuGet in AppVeyor .NET project

For test configuration it is enough to trust “Automatic discovery” option. It works well for NUnit tests and according to list https://www.appveyor.com/docs/running-tests it supports most of the popular test libraries.

Finally we can rerun build for our project to see that commit becomes green and all tests passes.

Green build and tests

JavaScript

Configuration for JavaScript project is a bit more difficult than for .NET. Because this CI server is based on Visual Studio, it is easier to configure it outside of web page. We should create a file named appveyor.yml in the main directory of our project. This is another method for configure the build process. You can find more information about this file in https://www.appveyor.com/docs/build-configuration.

In our case we want to run npm install phase and also run test from package.json configuration file. Of course, you can have different configuration of npm tasks, but the only one thing that you need to do is to modify this definition file to match your npm/gulp task names.

# Install scripts. (runs after repo cloning)
install:
  # Get the latest stable version of Node.js
  - ps: Install-Product node
  # install modules
  - npm install

# Post-install test scripts.
test_script:
  # Output useful info for debugging.
  - node --version
  - npm --version
  # run tests
  - npm test

# Don't actually build.
build: off

Before we run npm we have to be sure that we install it. It can be done with PowerShell command Install-Product node.

Notification

It is very useful to set up a notification system to inform you immediately about the build status. We can do this in project settings. We can configure it to send email or Slack message if the build fails.

AppVeyor Slack integration

Deployment

The last important part of Continues Integration process is deployment. We can configure AppVeyor, to give us a quick method to start project deployment. We can configure a deployment using WebDeploy, FTP server or even Azure Cloud.

Deployment to GitHub pages

I use a GitHub Pages mechanism as I described earlier http://www.diwebsity.com/2016/03/08/najtanszy-hosting-dla-projektow-webowych/ therefore I want to integrate it with AppVeyor. It is very easy, because the only one necessary part is to configure custom deployment script using:

gulp deploy

Deploy using GitHubPages

This is the basic type of CI environment and AppVeyor definitely match my requirements.



Aktywne zabezpieczenie aplikacji webowej – AppSensor

Aktywne zabezpieczenie aplikacji webowej – AppSensor

owas-zabezpieczenie aplikacji
Źródło

W poprzednim poście opisałem, czym jest mechanizm AppSensor. Chciałbym teraz przedstawić dokładniej jego sposób działania i w jaki sposób pozwala na zabezpieczenie aplikacji webowej.

Korzyści

Stosowanie tego mechanizmu umożliwia nam:

  • wykrywanie zagrożeń już w momencie próby ataku,
  • reagowanie na niebezpieczne zdarzenia w czasie rzeczywistym,
  • rozszerzenie spektrum wykrywania zagrożeń dzięki korzystaniu z kontekstu wykonywania akcji,
  • zabezpieczenie systemu przed nieznanymi jeszcze podatnościami programowymi.

Elementy składowe

Sama biblioteka składa się z następujących elementów:

  • punkty detekcji,
  • logowanie potencjalnych zagrożeń,
  • mechanizm analizy i rozpoznawania zagrożeń,
  • sposoby reakcji.

Elementy te, odpowiednio połączone, pozwalają na stworzenie spójnego mechanizmu przetwarzania wszelkich niestandardowych użyć systemu. Dzięki analityce jesteśmy w stanie zgrupować te anomalie i odpowiednio, proaktywnie na nie reagować.

Właśnie element analityczny jest jednym z najważniejszych mechanizmów w całej tej układance. To dzięki niemu możemy sprawić, że ataki będą blokowane, a błędy użytkownika nie spowodują blokowania jego pracy. Sposób wykrywania ataków zależy od tego, jak wygląda interfejs użytkownika systemu oraz jak dokładne walidacje są przeprowadzane w jego zakresie. Można to zaobserwować na poniższych rysunkach:

validation
validation_client_side

W przypadku, gdy nie wykorzystujemy walidacji po stronie klienta, otrzymanie numeru telefonu zawierającego myślnik nie jest niezykłe. Z kolei w przypadku, gdy odrzucamy tego typu znaki po stronie klienta, otrzymanie ich na wejściu metody API zdecydowanie świadczy o nieprawidłowym użyciu takiej metody.

Dodatkowo w niektórych elementach możemy zdecydować się na skorzystanie z usług zewnętrznego dostawcy rozwiązania. Tak jest w przypadku mechanizmu logowania potencjalnych zagrożeń. Przyjrzyjmy się bliżej wszystkim elementom biblioteki.

Rodzaje punktów detekcji

Zaczynamy od punktów detekcji. Są to reguły pozwalające na rozpoznanie specyficznych dla systemu sytuacji przekroczenia zasad przekazywania danych. Projekt AppSensor definiuje typowe punkty wykrywania. Dzielą się one na następujące grupy związane z:

  • zapytaniami do serwera,
  • autentykacją,
  • uprawnieniami,
  • walidacją danych,
  • zmianą trendów zachowania systemu.

Przykładami punktów detekcji mogą być:

  • próba ominięcia walidacji po stronie klienta,
  • próba operacji na zasobach, do których użytkownik nie ma uprawnień,
  • nadużycia przy próbach logowania,
  • próby przesłania niebezpiecznych znaków,
  • zbyt częste używanie funkcji niedostępnych z interfejsu użytkownika.

Logowanie

Ważnym elementem składowym biblioteki jest logowanie potencjalnych niebezpieczeństw. Można tu skorzystać z zewnętrznych usługodawców lub z własnego mechanizmu. W dużej mierze zależy to od tego, jakiego mechanizmu logowania używamy już w naszej aplikacji. Ze względu na potrzebę analizowania zagrożeń ważne jest umożliwienie odczytywania tych informacji z naszej aplikacji. Logowane informacje muszą posiadać kilka istotnych z punktu widzenia analizy właściwości:

  • datę i czas zdarzenia,
  • punkt styku, na którym wykryto naruszenie,
  • informację identyfikującą użytkownika,
  • wysłane informacje,
  • rodzaj wykrytego zagrożenia.

Rodzaje odpowiedzi

W odpowiedzi na rozpoznane zagrożenie możemy zastosować kilka rodzajów zachowań systemu, które mają na celu poinformowanie administratora i/lub utrudnienie dalszego ataku:

  • alerty bezpieczeństwa dla administratorów,
  • zwiększenie poziomu zabezpieczeń,
  • wylogowanie,
  • zablokowanie konta,
  • akcje w warstwie infrastruktury (np. blokowanie adresów IP),
  • dzielenie się danymi z innymi systemami.

Praca analityczna przy ustalaniu zagrożeń, reakcji i triggerów

Jak już wspomniałem, niezwykle istotne jest odpowiednie dopasowanie progów i zasad wykrywania, aby mechanizm ten nie był uciążliwy dla normalnych (popełniających błędy) użytkowników. Należy przeanalizować i dostosować ustawienia tak, aby pasowały do specyfiki aplikacji i firmy. Można przyjąć kilka różnych strategii działania:

  • nie zabraniaj niczego użytkownikom, lecz loguj ich działania i monituj administratorów,
  • informuj użytkowników o przekroczonych uprawnieniach i o monitorowaniu ich działań,
  • uzależniaj poziom zabezpieczeń od kraju pochodzenia użytkownika,
  • użytkownicy, którzy nie są zalogowani powinni mieć bardziej rygorystyczne ograniczenia,
  • wszelkie powtarzające się podejrzane zachowania o wysokim zagrożeniu powinny wylogowywać użytkownika i/lub blokować czasowo jego konto.

Integracje z innymi systemami

Implementacja może, a niekiedy nawet powinna obejmować integracje z innymi systemami. Powinna być ona rozpatrywana już podczas fazy analizy, ponieważ obejmuje zasady reakcji na zdarzenia. Przykładowo możemy rozpatrywać łączenie się z systemami:

  • w warstwie sieciowej infrastruktury (do blokowania adresów IP),
  • monitoringu,
  • wspomagającymi logowanie,
  • statystycznej analizy ruchu sieciowego.

Możliwości adaptacji

Do gotowego systemu zabezpieczeń możemy dodać różne modyfikacje, które usprawniają cały mechanizm, np.:

  • dynamiczne adaptacje progów wykrywania ataków (przy zwiększonej częstotliwości wykrywania niepoprawnych zachowań, możemy zaostrzyć kryteria akceptacji),
  • dynamiczne adaptacje zachowań w zależności od sposobów ataku.

W kolejnym poście opiszę architekturę rozwiązania, które chcę zbudować.

Znacznie szybsze debugowanie JS w VS Code

Znacznie szybsze debugowanie JS w VS Code

debugowanie_js

Ostatnio odkryłem nową funkcjonalność środowiska Visual Studio Code. Używając wtyczki VS Code – Debugger for Chrome można umożliwić debugowanie JS. Kod aplikacji uruchomiony w przeglądarce może być śledzony w edytorze. Visual Studio Code zawiera kilka wbudowanych debuggerów w tym np. dla Node.js. Aby doinstalować powyższy dodatek wystarczy nacisnąć F1 a następnie install extension. Gdy z otwartej listy wybierzemy pozycję Debugger for Chrome, będziemy mogli już przystąpić do konfiguracji naszego rozszerzenia.

Konfiguracja

Podstawową kwestią jest zmiana konfiguracji Chrome, aby upewnić się, że udostępnia on usługę zdalnego debugowania kodu na określonym porcie. Aby to zrobić wystarczy uruchomić przeglądarkę z parametrem

chrome.exe --remote-debugging-port=9222

W ten sposób Chrome udostępnia usługę do zdalnej inspekcji kodu stron otwieranych w przeglądarce. Można to przetestować wpisując adres:

http://localhost:9222

Następnie wystarczy skonfigurować taski debugujące w Visual Studio Code.

Jeżeli jeszcze nie posiadamy pliku launch.json wystarczy nacisnąć przycisk F5 odpowiadający za rozpoczęcie debugowania, aby plik został wygenerowany. Wewnątrz niego w sekcji configurations możemy dodać wiele rodzajów debuggerów począwszy od .NET do Node.js. Jednak my skupimy się jedynie na połączeniu z Chrome.

Interesują nas trzy konfiguracje dla debugowania:

  1. Debugowanie JS w lokalnym pliku
    {
        "name": "Launch index.html",
        "type": "chrome",
        "request": "launch",
        "file": "${workspaceRoot}/src/index.html"
    }
    
  2. Debug hostowanego projektu
    {
        "name": "Launch localhost with sourcemaps",
        "type": "chrome",
        "request": "launch",
        "url": "http://localhost/mypage.html",
        "sourceMaps": true,
        "webRoot": "wwwroot"
    }
    
  3. Podłączenie się do już uruchomionej strony
    {
        "name": "Attach",
        "type": "chrome",
        "request": "attach",
        "port": 9222,
            "sourceMaps": true
    }
    

Co to zmienia?

Jak dotąd istniał stały podział: backend debugowało się w konkretnych IDE, a frontend w narzędziach developerskich przeglądarki. Połączenie przeglądarki i edytora na czas debugowania aplikacji zbliża nas do połączenia tych dwóch ekosystemów i zwalnia z przełączania się pomiędzy środowiskami gdzie edytujemy kod i gdzie go testujemy. Według mnie to zwiększa komfort pracy i pozwala lepiej skoncentrować się na rozwiązywanym problemie, zamiast na próbach synchronizowania przeglądarki z kodem nad którym pracujemy.

Przykłady

Mechanizm ten jest skonfigurowany dla mojego projektu na GitHub – InvestDashboard. Można pobrać najnowszą wersję tego projektu i po odpaleniu go w Visual Studio Code nacisnąć przycisk F5 i debugowanie będzie już działało poprawnie. Trzeba jednak pamiętać o odpowiedniej konfiguracji Chrome

Chrome_debug2

OWASP AppSensor – opis mechanizmu

OWASP AppSensor – opis mechanizmu

owasp-opis
Źródło

OWASP

OWASP (Open Web Application Security Project) jest to organizacja non-profit mająca na celu analizę zagadnień związanych z bezpieczeństwem aplikacji i opracowywanie rozwiązań, które byłyby użyteczne zarówno dla organizacji jak i dla pojedynczych twórców oprogramowania. Organizacja ta działa otwarcie, a wszystkie materiały są darmowe i ogólnodostępne. Nie jest ona także związna z żadnym dostawcą oprogramowania i pozwala na niezależność w tym zakresie. Jej główną siłą napędową jest społeczność ludzi zainteresowanych tematem bezpieczeństwa. Tworzą oni narzędzia wspomagające zabezpieczanie i testowanie zabezpieczeń systemów komputerowych. Znane projekty to:

  • OWASP Zed Attack Proxy – narzędzie do automatycznego testowania bezpieczeństwa systemów
  • OWASP Top Ten – lista największych zagrożeń dla aplikacji webowych wraz z metodami zapobiegania im
  • OWASP OWTF – narzędzie do automatyzacji testów penetracyjnych

Wybór AppSensor

Od pewnego czasu interesuję się tematem bezpieczeństwa i dzięki temu trafiłem na ogranizację OWASP. Jest ona nastawiona w dość dużym stopniu na środowisko Java. Tak więc pisząc w .NET mogę korzystać z gotowych narzędzi OWASP, zaś korzystanie z bibliotek jest już dla mnie niemożliwe. Istnieją czasem porty bibliotek na platformę .NET, jednak nie są one dopasowane do tego środowiska. Projekt AppSensor zainteresował mnie swoją prostotą i możliwościami, które są z nim związane. Dlatego też postanowiłem zająć się jego implementacją dopasowaną dla webowych mechanizmów .NET w szczególności do WebAPI, ale z możliwością samodzielnego dostosowania do dowolnego frameworku np. Nancy czy ServiceStack.

AppSensor

Pomysł biblioteki AppSensor polega na tym, że w środowisku produkcyjnym aplikacja cały czas przetwarza różnego rodzaju informacje i akcje. Dzięki umieszczeniu wewnątrz kodu aplikacji odpowiednich punktów detekcji podejrzanych zachowań, jesteśmy w stanie na bieżąco, niemalże w czasie rzeczywistym, reagować na pojawiające się zagrożenia. W klasycznym podejściu ataki wykrywamy i blokujemy głównie na wejściu do aplikacji. Umożliwia nam to wykrycie podejrzanych zachowań takich jak wysłanie niepoprawnych ciągów znaków w requestach HTTP, co może sygnalizować próbę użycia np. SQL Injection. Nie biorą one jednak pod uwagę kontekstu w jakim wykonywane są te zapytania. System wykrywania, znając kontekst biznesowy konkretnego zapytania, jest w stanie wykryć więcej nadużyć, z większą trafnością. Jest na przykład w stanie wykryć zbyt częste próby logowania do aplikacji lub próby naruszenia uprawnień.

Podsumowując możemy powiedzieć, że AppSensor obejmuje wykrywanie nadużyć i reagowanie na zagrożenia:

  • zależne od kontekstu,
  • specyficzne dla danej aplikacji,
  • dynamicznie,
  • reagując w czasie rzeczywistym,
  • z możliwością adaptacji zasad reakcji.

Zasada działania

Cały mechanizm jest zasadniczo prosty w użyciu i składa się z trzech kroków:

  1. Detekcja – rozpoznanie nietypowego zachowania.
  2. Identyfikacja próby ataku – ocenienie czy wykryte zachowanie jest poza zakresem dopuszczalnych akcji użytkownika za pomocą interfejsu lub API.
  3. Reakcja – zastosowanie środka informującego lub zapobiegającego dalszym nadużyciom.

Identyfikacja ataku bazuje na prostym założeniu, że w większości aplikacji użytkowych, zbiór akcji dopuszczalnych jest rozłączny ze zbiorem akcji będących zagrożniem.

application_use

Kluczem jest więc odpowiednie odseparowanie tych 2 rodzajów zachowań. W podstawowej wersji tego mechanizmu można skorzystać z gotowego zbioru najpopularniejszych punktów detekcji zagrozeń https://www.owasp.org/index.php/AppSensor_DetectionPoints.

Bardzo dobrze przemówiło do mnie porównanie aplikacji z systemem wczesnego wykrywania zagrożeń i bez niego do banku zabezpieczonego i zarządzanego jak niektóre projekty informatyczne.

bank_safe
bank_unsafe

Źródło: https://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf

Konfiguracja TypeScript – kompilacja

Konfiguracja TypeScript – kompilacja

konfiguracja_typescript

Co to jest TypeScript?

TypeScript to język, który jest nakładką na JavaScript. Udostępnia on silne typowanie dla tego dynamicznego języka. Dodatkowo wprowadza on klasy, moduły i interfejsy, które pomagają w organizacji kodu aplikacji. Jest to szczególnie użyteczne w dużych projektach z wydzielonymi wieloma częściami aplikacji. Dzięki użyciu mechanizmów obiektowych możemy porządkować kod, a dzięki silnemu typowaniu każdy błąd składniowy zostanie wykryty już podczas kompilacji lub, w niektórych edytorach, nawet podczas pisania. Dobra konfiguracja TypeScript pozwoli nam w dużej mierze zautomatyzować ten proces.

Dużym plusem języka TypeScript jest jego pełna kompatybilność z JavaScript. Każdy plik napisany w JS po zmianie rozszerzenia na .ts jest od razu poprawnym plikiem TypeScriptowym. Pozwala to na stosunkowo łatwą migrację projektu napisanego w JS. Jednak warto też wspomnieć o minusach TypeScriptu. Kłopoty zaczynają się, gdy chcemy skorzystać z biblioteki, do której nie są dostępne pliki typowań (definicje typów dla mechanizmu silnego typowania). Typowania dla wielu bibliotek jesteśmy w stanie znaleźć na https://github.com/DefinitelyTyped/DefinitelyTyped. Niestety, gdy chcemy skorzystać z mniej popularnych bibliotek lub choćby z najnowszych wersji, możemy nie znaleźć odpowiednich definicji. Ponieważ typowania są nam potrzebne głównie do sprawdzania poprawności użytych typów danych, możemy skompilować nasze pliki do JS, licząc się z tym, że będą one generować błędy lub ostrzeżenia kompilacji.

Dalej pokażę jak skonfigurować kompilację TypeScript w różnych środowiskach.

Konsola

Podstawowym miejscem obsługi kompilatora TypeScript jest konsola. Zacznijmy od instalacji, którą najlepiej przeprowadzić za pomocą npm

npm install -g typescript

Następnie potrzebny jest plik konfigurujący dla kompilatora. Definiujemy w nim parametry, mówiące o dialekcie, do którego chcemy skompilować kod (ES4, ES5 lub ES6), kompilowanych plikach lub też generowaniu sourceMap. Dokładny opis parametrów znajduje się w dokumentacji https://github.com/Microsoft/TypeScript/wiki/tsconfig.json. Podstawowym ustawieniem może być:

{
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": true,
        "removeComments": true,
        "preserveConstEnums": true,
        "sourceMap": true
    },
    "exclude": [
        "node_modules",
        "dist"
    ]
}

Powoduje ono kompilacje wszystkich dostępnych plików .ts do plików .js oraz do sourceMap z katalogu bieżącego i katalogów w nim zawartych. Dodatkowo czyści wynikowe pliki z nadliczbowych komentarzy i definicji.

Teraz wystarczy wywołać komendę

tsc

Pozwala ona na kompilowanie wszystkich plików w naszym projekcie. Pliki .ts zostaną przetworzone do plików .js w tym samym folderze. Można skorzystać z ułatwienia kompilacji i założyć czujkę na plikach do kompilacji. To pozwoli na kompilowanie plików w tle przy każdym zapisie.

tsc -w

Gulp

Gdybyśmy chcieli włączyć proces kompilacji do procesu przetwarzania naszego projektu np. przy pomocy Gulp, musimy skorzystać z odpowiedniej biblioteki

npm install gulp-typescript --save-dev

następnie możemy dodać poniższe kroki budowania do naszego pliku konfiguracyjnego gulpfile.js

var gulp = require('gulp');
var ts = require('gulp-typescript');
var tsProject = ts.createProject('tsconfig.json');

gulp.task('scripts', function () {   
    var tsResult = tsProject.src().pipe(ts(tsProject));
    return tsResult.js.pipe(gulp.dest('.'));
});

Dokładniejszy opis można znaleźć w http://blah.winsmarts.com/2015-7-Setting_up_TypeScript_with_Visual_Studio_Code.aspx

VisualStudio Code

Używając Visual Studio Code do edycji projektów w TypeScript, można skonfigurować sposób budowania aplikacji, który wykorzystuje kompilator TypeScript. W tym celu wystarczy dodać w pliku tasks.json, znajdującym się w klatalogu .vscode, odpowiednią konfigurację dla kompilacji

{
    "version": "0.1.0",
    "command": "tsc",
    "isShellCommand": true,
    "showOutput": "silent",
    "problemMatcher": "$tsc"
}

https://code.visualstudio.com/Docs/languages/typescript
https://cmatskas.com/typescript-and-vs-code/

W codziennej pracy pomocne jest uporządkowanie naszego projektu tak, aby nie wyświetlał generowanych plików. Aby to zrobić, należy edytować ustawienia workspace (File | Preferences | Workspace Settings), a następnie dodać ukrycie plików sourcemap i warunkowe ukrycie plików js

"files.exclude": {
    ...
    "**/*.js": { "when": "$(basename).ts"},
    "**/*.js.map": true
} 

https://code.visualstudio.com/Docs/languages/typescript#_hiding-derived-javascript-files

Przykładowe kody źródłowe można znaleźć na GitHub:

https://github.com/suvroc/InvestDashboard/releases/tag/v0.0.1

Najtańszy hosting dla projektów webowych – GitHub Pages

Najtańszy hosting dla projektów webowych – GitHub Pages

najtanszy_hosting_github_pages

Ostatnio dość długo poszukiwałem dobrego miejsca do uruchamiania moich drobnych projektów. Myślałem o różnego rodzaju hostingach potrafiących udostępniać strony www. Rozważałem między innymi takie możliwości jak hosting dla .NET, chmura dla różnych technologii np. Node. Jednak najbardziej interesujące okazało się najprostsze rozwiązanie. Znalazłem możliwość, aby GitHub hostował moje pliki. Jest to usługa GitHubPages. Co więcej jest ona dostępna za darmo.

Co to jest GitHub Pages

GitHub Pages pozwala hostować statyczne pliki w dwóch opcjach: dla profilu użytkownika i dla konkretnego projektu. W założeniu GitHub Pages umożliwia tworzenia wizytówek projektów umieszczonych na platformie GitHub, jednak zakres tej funkcjonalności jest znacznie szerszy. Zakładając, że część serwerową aplikacji mamy osadzoną w innym miejscu (ponieważ często wymaga ona bazy danych lub infrastruktury aplikacyjnej), cały front-end możemy umieścić na GitHub Pages. Co więcej, jest to sposób na szybkie udostępnienie projektu i aktualizowania go. Dzięki temu możemy często prezentować zmiany docelowym użytkownikom. Dodatkowym plusem jest prostota i możliwość trzymania wszystkiego w jednym miejscu. Nie jest to rozwiązanie dobre dla dużych serwisów, dlatego też polecam je głównie do testowania swoich stron lub przechowywania małych aplikacji.

Rozwiązanie to nie jest niestety do końca darmowe. Możemy się zdecydować na płatną wersję GitHub pozwalającą na przechowywanie prywatnych repozytoriów lub otworzyć kod swojej aplikacji, by w ten sposób korzystać z tej funkcjonalności za darmo.

Jak to działa?

Zamieszenie swojej strony na GitHub Pages polega na stworzeniu brancha o nazwie gh-pages dla swojego repozytorium. Można to zrobić używając automatycznego generatora https://pages.github.com/, ale w naszym przypadku będziemy chcieli zamieścić swoje pliki. Pliki z tego brancha zostaną wyświetlone pod adresem http://username.github.io/repository_name

Kroki do zdeployowania projektu

  1. Przyjmijmy, że nasza gotowa strona znajduje się w katalogu dist
  2. Dodajemy nasz katalog do repozytorium
    git add dist && git commit -m "Initial dist subtree commit"
    
  3. Następnie pushujemy katalog do brancha gh-pages
    git subtree push --prefix dist origin gh-pages
    

Dokładniejszy opis kroków można znaleźć w https://gist.github.com/cobyism/4730490

Automatyzacja za pomocą gulp

Te operacje można bardzo łatwo włączyć na nasz workflow zarządzania projektem za pomocą gulp. Wystarczy jedynie skorzystać z gotowego komponentu https://github.com/shinnn/gulp-gh-pages

Można go skonfigurować używając następującego taska w gulp

var gulp        = require('gulp');
var deploy      = require('gulp-gh-pages');

/**
 * Push build to gh-pages
 */
gulp.task('deploy', function () {
  return gulp.src("./dist/**/*")
    .pipe(deploy())
});

W czasie uruchomienia tego zadania za pomocą komendy gulp deploy może się pojawić błąd autoryzacji. Jest on związany z problemem użycia SSL dla GitHub w Windows. Aby temu zaradzić musimy zainstalować aplikację Git Credential Manager for Windows, która umożliwia autoryzację w ten sposób.

Źródła:

http://charliegleason.com/articles/deploying-to-github-pages-with-gulp

Pomysły i zdolność ich wykonania

Pomysły i zdolność ich wykonania

pomysly2

W ostatnim poście pisałem o podjęciu wyzwania, które polega na realizacji otwartego projektu. Decyzję o udziale w tym przedsięwzięciu podjąłem szybko, ale największy problem miałem z pomysłem na ten projekt. Przy czym nie był to problem związany z wymyśleniem czegoś, ale z wyborem spośród tego, o czym myślę ostatnio. Dość często przychodzą mi do głowy różne idee np. na zautomatyzowanie lub ulepszenie jakiegoś procesu czy uwspólnienie czegoś dla kilku aplikacji. Podejrzewam, że wielu developerów ma podobnie. Wiadomo, że jedne pomysły są lepsze, a drugie gorsze. Właśnie dlatego ostatnio staram się jak najszybciej zapisywać swoje koncepcje, tak “na gorąco”. Dzięki temu, gdy mam ochotę i możliwości czasowe, by rozpocząć nowy projekt, nie tracę zapału na długim wymyślaniu, czym mógłbym się zająć. Tylko po prostu przeglądam listę i dokonuję wyboru jak z gotowego menu, którego jedyną wadą jest to, że bardzo wiele potraw wygląda apetycznie.

Zarządzanie pomysłami

Próbowałem już kilku różnych metod zarządania swoimi pomysłami i wypracowałem rozwiązanie, które sprawdza się najlepiej.

Najważniejszymi założeniami są dla mnie:

  • możliwość zapisywania pomysłów w dowolnym momencie
  • łatwa dostępność do listy pomysłów
  • możliwość dodawania komentarzy lub powiązanych informacji

Moja metoda jest prosta – polega na noszeniu przy sobie małego notesika, w którym mogę zapisać każdy pomysł. Dodatkowo co jakiś czas siadam z nim do komputera, by przepisać pomysły do Trello. Narzędzie to służy do tworzenia list zorganizowanych w tablicę podobną do tablicy Kanban. Dzięki temu mogę dowolnie kategoryzować pomysły, decydować się na ich rozpoczęcie oraz podpinać znalezione powiązane materiały. Tego typu rozwiązanie bardzo dobrze sprawuje się w moim przypadku. Na tę chwilę jedynym ulepszeniem, które mogłoby Wam przypaść do gustu, jest według mnie użycie aplikacji do tworzenia notatek w telefonie zamiast notesu.

Zdolność wykonania

Czasem żałuję, że nie jestem w stanie zrealizować wszystkich pomysłów i dlatego chcę być pewien, że przystępując do realizacji danej koncepcji, dokonuję dobrego wyboru. Muszę więc określić na czym mi w danej chwili zależy i jakie mam szanse na sfinalizowanie projektu, w tym celu oceniam swoją zdolność do wykonania projektu (project execution capability).

Jeżeli rozważany pomysł dotyczy dziedziny, na której się kompletnie nie znam i nie czuję potrzeby jej zgłębiania, to uznaję ten pomysł jako nieodpowiedni dla mnie ze względu na brak możliwości wykonawczych. Nie mówię tu o technicznych aspektach, bo wiele projektów jest dla mnie materiałem do nauczenia się lub przećwiczenia pewnych bibliotek lub technik. Mowa o tematykach biznesowych danych projektów. Jeżeli dla przykładu nie znam się na dietetyce, to wiem, że trudno mi będzie wykonać dobrze pomysł z tym związany. Oczywiście, mam też kilka innych kryteriów oceny moich idei, lecz ta jest najważniejsza i zawsze od niej zaczynam.

Dzielenie się pomysłami

Przy dość szybkim odrzucaniu niektórych pomysłów, czasem takich, które uważam za całkiem dobre, mam wrażenie, że pewne ulepszenia codzienności nie ujrzą światła dziennego. Dlatego przyszło mi do głowy, że być może dobrym nawykiem byłoby upublicznianie swoich pomysłów, którymi z różnych względów (np. brak wspomnianej wyżej zdolności do wykonania) postanowiłem się nie zajmować. Wówczas byłaby szansa, że ktoś je zrealizuje w wersji zaproponowanej przeze mnie lub po dokonaniu własnych modyfikacji, a może zainspirowany którąś z koncepcji wymyśli coś znacznie lepszego.

Co myślicie na ten temat? Czy Wy chcielibyście się podzielić swoimi koncepcjami lub poczytać nad czym myśleli inni?
Jak z kolei Wy dbacie o swoje pomysły?

Wyzwanie “Daj się poznać”

Wyzwanie “Daj się poznać”

daj-sie-poznac

Ostatnio znalazłem w sieci informację o konkursie “Daj się poznać” organizowanym przez Maćka Aniserowicza. Celem konkursu jest aktywizacja developerów w sieci. Wyzwanie polega na rozpoczęciu własnego projektu z otwartymi źródłami, który będzie publikowany na GitHub i opisywaniu różnych zagadnień z nim związanych na blogu. Wymogiem jest publikacja 2 postów tygodniowo.

Myślę, że to bardzo pozytywna idea. Nawet niezależnie od nagród i wygranej. Jest to dobra okazja do sprawdzenia się jako osoba pisząca teksty techniczne oraz możliwość dotarcia do wielu osób i otrzymania feedbacku o swoim projekcie. Jest to także, mam nadzieję, świetna motywacja do wcielenia w życie swojego pomysłu na projekt.

Po tym wstępie łatwo się domyślić, że postanowiłem wystartować w tym wyzwaniu. Zdecydowałem opisać realizację dwóch pomysłów, by w trakcie projektu wybrać ten, który da mi większą satysfakcję i będzie ciekawszy zarówno dla mnie jak i dla potencjalnych użytkowników. Wiąże się to również z faktem, że moje dotychczasowe doświadczenia nauczyły mnie dość częstego weryfikowania zasadności pracy nad danym projektem i nie mam skrupułów odnośnie szybkiego kończenia projektów na dowolnym ich etapie. Co jednak nie znaczy, że wykluczam możliwość zrealizowania obydwu koncepcji.

Wybrałem więc następujące projekty:

WebAPI OWASP App Sensor

Jest to implementacja mechanizmu wczesnego reagowania na ataki i podejrzane zachowania ze strony użytkowników. Projekt OWASP AppSensor definiuje różne zagrożenia, poziomy reakcji na wykrycie zagrożenia oraz możliwe zachowania niwelujące poziom ryzyka.

Moim zadaniem bedzie zaimplementowanie tych mechanizmów dla środowiska WebAPI jako konfigurowalnej biblioteki z możliwością prostego włączenia ich do dowolnego projektu. Planuję na poczatku zapoznać się z dokładnym opisem tego mechanizmu. Następnie stworzyć szkielet biblioteki służący do rejestrowania zagrożeń. Ostatnim i najdłuższym etapem będzie sukcesywne analizowanie punktów detekcji szkodliwych zachowań i dodawanie ich do bilbioteki.

Skąd pomysł?

  • nie ma biblioteki implementującej ten mechanizm dla .NET
  • chcę lepiej poznać WebAPI
  • chcę poszerzyć swoją wiedzę o zagrożeniach bezpieczenstwa dla API webowych i zbudować narzędzie pomocne w ich wykrywaniu
  • na tym przykładzie chcę nauczyć się tworzenia niezależnych bibliotek włączanych do projektów za pomocą NuGeta

Aplikacja do śledzenia notowań giełdowych i funduszy inwestycyjnych

Jak dotąd nie znalazłem żadnej aplikacji, która pozwalałaby prosto i szybko wyświetlać lub analizować inwestycje finansowe (dokonywane w różny sposób i w różnych miejscach) dostosowanej do polskiego rynku.

Pomysł jest w zasadzie bardzo prosty, ale taki właśnie ma być. Główny cel to stworzenie aplikacji, której sam chciałbym używać. Przy okazji poszerzę swoją wiedzę o budowie frameworków do tworzenia aplikacji webowych jako aplikacji mobilnych. Będę chciał wykorzystać następujące technologie: Ionic2, Angular2, TypeScript do frontendu oraz Node.js do backendu. Pierwszy raz użyję tego stacku technologicznego i to będzie dla mnie wyzwaniem.

Dodatkowo chciałbym stworzyć tę aplikację zaczynając od zaprojektowania warstwy UX, UI a dopiero później implementacji. Jest to swego rodzaju test tego sposobu pracy nad projektem.