Browsing Category

Daj Się Poznać 2017

community Daj Się Poznać 2017 dotnetcore steganography

StegoCore – wydana paczka NuGet (MyGet)

Cześć wszystkim,

Dawno nic nie pisałem, więc czas powrócić. Dzisiaj krótki wpis informujący o zmianach/postępach w projekcie StegoCore.

MyGet

Z racji tego, że posiadam już dwa zaimplementowane algorytmy (LSB i Zhao&Koch), zdecydowałem się na wydanie biblioteki w formie paczki. Jest ona w dosyć wczesnej fazie, dlatego umieściłem ją w repozytorium MyGethttps://www.myget.org/feed/stegocore/package/nuget/StegoCore. Gdy będę już zadowolony z jej formy, oraz gdy będzie zawierać więcej zaimplementowanych algorytmów, wrzucę ją do NuGet’a. Myślę, że napiszę również posta o tym jak pakować projekt do paczki nugetowej i wrzucać do repozytorium MyGet.

Zmiany, feature’y

Zmieniłem również referencję do StegoCore z aplikacji webowej. Od tego momentu będę korzystać z niej, jak z zewnętrznej biblioteki.

Dzięki temu, aplikacja ta będzie dobrym przykładem jak używać StegoCore.

W celu uzyskania continuous integration, dokonałem integracji z serwisem Travis CI. Teraz po każdym commicie uruchomiony zostanie build projektu oraz testy (to może też dobry pomysł na posta ? :))

Dodałem również Dockerfile. Możliwe jest więc zbudowanie i przetestowanie StegoCore w środowisku Linux w Dockerze.

Co dalej?

Po wydaniu paczki mam więcej motywacji, aby rozwijać StegoCore. Na pewno zajmę się rozwojem biblioteki, dodaniem lepszego interfejsu do jej obsługi oraz komentarzy opisujących metody.

Następnie, zajmę się zaimplementowaniem kolejnych algorytmów steganograficznych. Jest więc co robić, a przecież nie można zapominać o aplikacji webowej!

 

 

Daj Się Poznać 2017 dotnetcore steganography

StegoCore – zakończona implementacja algorytmu Zhao&Koch

Jak obiecałem, tak robię. Po zakończeniu konkursu Daj Się Poznać nie ustają prace nad projektem StegoCore. Już na początku czerwca udało mi się dokończyć i poprawić implementację algorytmu Zhao&Koch, ale jestem leniem i zebrałem się dopiero teraz za napisanie posta. 😀

Co zrobiłem?

  • Wczytałem się dokładnie w opis algorytmu wstawiania i odczytywania znaku. Okazało się, że miałem w swojej implementacji błąd, który uniemożliwiał wstawienie, a co za tym idzie, odczytanie wiadomości.
  • Poprawiłem implementację oraz doświadczalnie dostosowałem parametry wykorzystywane podczas umieszczania znaku.
  • Dokonałem kilka poprawek w aplikacji webowej, tak aby możliwe było wykorzystanie algorytmu Zhao&Koch. W wolnej chwili wdrożę nową wersję aplikacji pod adres pawelskaruz.pl:8080

Co dalej?

  • Po pierwsze chciałbym poprawić aplikację webową, tak aby była używalna 😀 przyda się więcej komunikatów odnośnie umieszczania, odczytywania danych.
  • Do algorytmu Zhao&Koch potrzebny jest parametr d, który może pochodzić od użytkownika, więc chciałbym dodać taką możliwość. Będzie to oczywiście wymagać zmian zarówno w StegoCore, jak i w aplikacji webowej
  • Jeśli już zabiorę się za parametry wejściowe, to chciałbym dodać możliwość umieszczania bitów nie w kolejnych, a losowych miejscach zdjęcia. Myślę, że dobrym pomysłem będzie możliwość podania przez użytkownika hasła, które będzie seed’em do jakiegoś generatora pseudolosowego.
  • Następnym większym krokiem będzie implementacja mojego algorytmu opartego na Web Paper Codes.

I to na tyle dzisiaj. A już niedługo kolejna, 3 część z serii o bezpiecznej aplikacji ASP.NET Core 🙂

community Daj Się Poznać 2017

Finał konkursu Daj Się Poznać 2017

Dzisiaj chciałbym się z wami podzielić kilkoma informacjami na temat konkursu Daj Się Poznać 2017, w którym to brałem udział 🙂

Koniec konkursu

Konkurs zakończył się dokładnie wczoraj (31.05.2017r.). Brało w nim udział 981 osób, a ukończyło 181. W tym gronie prawie 200 osób jestem również ja, z czego się bardzo ciesze.

Kto wygrał?

Jeszcze nikt 😀  ale jest to czas wyłonienie zwycięzcy! Do 7 czerwca w gronie osób, który ukończyły konkurs trwa wewnętrzne głosowanie. Po tym etapie zostanie wyłoniona grupa 20 osób.

Następnie 8 czerwca rozpocznie się głosowanie otwarte na wybraną dwudziestkę. Zwycięzca tego głosowania zostanie ogłoszony na Gali Finałowej, która odbędzie się w siedzibie Microsoftu 17 czerwca.

Oczywiście miło byłoby się znaleźć w gronie 20 osób, ale przecież nie o to chodzi w tym konkursie. Jeśli nawet nie uzyskam chociażby jednego głosu, to i tak będę dumny że założyłem bloga i prowadziłem go aktywnie przez 3 miesiące. I zamierzam robić to dalej! 🙂

Więcej informacji o zakończeniu konkursu na blogu Macieja Aniserowicza, autora Daj Się Poznać.

 

Daj Się Poznać 2017 dotnetcore imagesharp steganography

StegoCore – 10 tydzień. Koniec konkursu DSP i duże podsumowanie!

Minęło właśnie 10 tygodni prac nad projektem StegoCore w konkursie Daj Się Poznać. Jest to wiec ostatni tydzień i tym samym koniec konkursu. Ale zanim podsumuje cały projekt, czas na to co udało mi się zrobić w ostatnim tygodniu.

Co słychać?

  • Zaimplementowałem metodę odczytu ukrytej informacji w algorytmie Zhao&Koch
  • Napisałem testy sprawdzające możliwość odczytu ukrytej informacji – niestety wyniki nie są zadawalające; jest wiele przekłamań w odczytywanych bitach, co powoduje brak możliwości poprawnego odczytu danych. Wydaje mi się, że nie popełniłem żadnych błędów podczas implementacji, więc ciężko mi wywnioskować gdzie szukać błędu. Będę musiał dokładnie przeanalizować algorytm ukrywania i odczytu.
  • Zaktualizowałem aplikację webową dostępną pod adresem: http://pawelskaruz.pl:8080/

Co dalej?

  • Muszę przede wszystkich przetestować/przedebugować algorytm Zhao&Koch, aby dowiedzieć się dlaczego otrzymuje przekłamane bity podczas odczytywania.
  • Chciałbym poprawić aplikację webową StegoCoreWeb, wyłapać wyjątki z biblioteki StegoCore i przekazać odpowiednie komunikaty użytkownikowi

Podsumowanie konkursu

Przede wszystkim jestem zadowolony, że przez 10 tygodni udało mi się rozwijać projekt. Niestety wszystkie cele nie zostały osiągnięte. Na koniec konkursu chciałem zaimplementować 3 algorytmy i umieścić bibliotekę w menadżerze NuGet. Tak, jak wspominałem wcześniej, koniec konkursu nie oznacza końca prac nad projektem.

Gdy tylko uporam się z algorytmem Zhao&Koch, umieszczę bibliotekę StegoCore w NuGet. Dalej oczywiście będę rozwijał samą bibliotekę, jak i aplikację webową. Myślę tutaj o zaimplementowaniu własnego algorytmu ukrywania danych opartego na Wet Paper Codes.

Nie jestem za bardzo zadowolony z tylko 27 commitów, ale muszę wziąć pod uwagę fakt, iż mam tendencję to wrzucania wielu rzeczy na raz. Jest to jedna z kilku rzeczy, które muszę poprawić w swojej pracy. Commity nie powinny zawierać, aż tylu zmian w projekcie, a dotyczyć tylko jednej konkretnej zaimplementowanej/poprawionej rzeczy. Dzięki konkursowi nauczyłem się (a przynajmniej jestem świadomy, że muszę nad tym pracować 🙂 ) również innej, bardzo ważnej rzeczy – systematyczności. O wiele lepiej jest codziennie pracować nad projektem niż usiąść po kilku dniach przerwy i siedzieć wiele godzin przed komputerem.

Podczas prac nad StegoCore dosyć dobrze zapoznałem się z .NET Core. Jest to mój pierwszy projekt z użyciem tego frameworka, ale myślę że jak na pierwszy raz nie było tak źle. Do przeprowadzania operacji na zdjęciach użyłem biblioteki ImageSharp. Pomimo tego, że jest ona wciąż w fazie alpha, korzystało się z niej wygodnie i bez większych problemów.

W ramach Daj Się Poznać pisałem cotygodniowe podsumowania projektu, ale również inne posty związane z tematyką IT. TOP 5 najczęściej odwiedzanych to:

  1. Bezpieczna aplikacja ASP.NET Core (cz. I) – atak CSRF
  2. Kompresja JPEG oraz jej wykorzystanie w steganografii
  3. Alternatywa dla Visual Studio? Rider od JetBrains
  4. StegoCore – 3 tydzień, edycja zdjęć w .NET Core
  5. Klucz U2F jako metoda logowania do OS X

Reszta znajduje się pod adresem konkursowym. Serdecznie zachęcam do odwiedzania i czytania 🙂

Sukces!

Udało mi się wytrwać do samego końca konkursu Daj Się Poznać 2017! Yeah!! Sprostałem z wymogami i napisałem 20 postów konkursowych 🙂

Projekt będę dalej rozwijał, więc bardzo zachęcam do śledzenia bloga oraz dotnetomaniaka, na którego wrzucam swoje posty.

Na koniec chciałbym podziękować kilku osobom, które wspierały mnie podczas konkursu. Miewałem momenty zwątpienia i zniechęcenia, ale dzięki Wam nie poddałem się! Nie będę wymieniał z imienia i nazwiska, ale myślę, że te osoby będą wiedzieć, że chodzi o nie. Dzięki! 🙂

ASP.NET Core Security Daj Się Poznać 2017 dotnetcore security

Bezpieczna aplikacja ASP.NET Core (cz. II) – atak XSS

Pora na już drugą cześć cyklu o projektowaniu bezpiecznych aplikacji ASP.NET Core. Dzisiaj opowiem o ataku XSS, czym jest i co zrobić żeby nasza witryna była na niego odporna.

Atak XSS

Czym jest XSS? Najkrócej mówiąc jest atakiem na webaplikacje, polegającym na wstrzyknięciu do przeglądarki złośliwego kodu, najczęściej javascript. Celem atakującego jest inna osoba korzystająca z aplikacji.

Na przykład weźmy prostą aplikację np. bloga. Atakujący umieszcza w komentarzu do artykułu kod javascript:

Następnie taki kod może zostać uruchomiony w przeglądarkach innych osób odwiedzających naszego bloga.

Atak XSS możemy podzielić na dwie grupy:

  • Persistent – złośliwy kod umieszczony zostaje po stronie serwerowej aplikacji (najczęściej w bazie danych); podany wyżej przykład ataku na bloga jest właśnie atakiem persistent xss
  • Reflected – kod javascriptowy umieszczony zostaje w linku, a link następnie jest przesyłany do ofiary; efektem końcowym jest wykonaniu wstrzykniętego kodu w przeglądarce osoby atakowanej

Jakie mogą być skutki ataku?

Atakujący może próbować na przykład

  • uruchomić keylogger w przeglądarce
  • dynamicznie podmienić treść na stronie (tylko front-end)
  • wykraść ciasteczka sesyjne

Jak bronić naszą aplikację?

Jeśli chodzi o kradzież ciasteczek sesyjnych, sprawa jest bardzo prosta i nie wymaga dużo pracy. Wystarczy zastosować parametr HttpOnly w cookiesach. Spowoduje to, że nie będzie możliwy ich odczyt dla skryptów JS.

Jeśli chodzi zaś o samo blokowanie umieszczania złośliwego kodu przez atakującego, to cała rzecz polega na odpowiednim filtrowaniu tego co wysyła użytkownik. Atakujący będzie chciał umieścić kod w znacznikach w jakimś tagu html np. <script> . Musimy więc dane pochodzące od użytkownika odpowiednio enkodować przed umieszczeniem na stronie.

Encodowanie danych w ASP.NET Core

Razor, który jest chyba najczęściej wykorzystywanym enginem w MVC przychodzi z automatycznym enkodowaniem danych. Czyli w standardzie mamy to co w .NET oferowała biblioteka AntiXSS.  O ile używamy znacznika @, to nie musimy się martwić o dane które przesłał nam użytkownik.

Dla przykładu:

Spowoduje wygenerowanie:

Enkodery mogą być również dostępne z poziomu kontrolera poprzez wstrzyknięcie ich przez DI:

Każdy z enkoderów posiada metodę Encode. Jeśli np. chcemy zbudować URL z parametrem pochodzącym od użytkownika powinniśmy użyć UrlEncoder’a.

Widać więc, że w bardzo łatwy i szybki sposób możemy się ochronić przed atakami typu XSS. ASP.NET Core dostarcza nam w standardzie enkoder, więc dopóki używamy @ jesteśmy bezpieczni 🙂

 

Daj Się Poznać 2017 dotnetcore steganography

StegoCore – podsumowanie po 9 tygodniach

Pora na podsumowanie po 9 tygodniach pracy nad projektem StegoCore.

Co słychać?

  • Zaktualizowałem wersję dotnetcore do 1.0.4 with SDK 1.0.1; wcześniej używana przeze mnie wersja była RC, wiec stwierdziłem, że warto spróbować przejść do nowszej. Nie spowodowało to żadnych dziwnych zachowań aplikacji, więc upgrade się udał.

    Krótka informacja jak wskazać aplikacji, aby korzystała z nowej wersji dotnet core.

    Po pierwsze należy zainstalować pożądaną wersję dotnet core np. podaną powyżej. Następnym i ostatnim krokiem jest zmienić numer wersji na nowo zainstalowany w pliku global.json, . W moim przypadku plik ten wygląda tak:

  • Dokonałem małego refactoringu w kilku miejscach biblioteki, a także aplikacji webowej: między innymi w kontrolerze bazowym
  • Napisałem testy sprawdzające poprawność metod kwantyzacji i obliczania dyskretnej transformaty kosinusowej; ku mojej uciesze przeszły pomyślnie 🙂
  • Skończyłem implementację metody ukrywania danych z algorytmu Zhao & Koch

Co dalej?

  • Z algorytmu Zhao & Koch została implementacja metody odczytu ukrytej informacji
  • Przetestowanie całego algorytmu Zhao & Koch
  • Niestety nie wystarczy mi już czasu, aby zająć się kolejnym algorytmem ukrywania danych. Dlatego do końca maja chciałbym popracować nad aplikacją webową; tak, aby była bardziej user friendly 🙂

Powoli zbliża się koniec konkursu „Daj się poznać”. Nie chcę kończyć jednak prac nad StegoCore i na pewno dalej będę rozwijał ten projekt. Wiem, że kilka osób go śledzi, więc daje mi to sporą motywację do działania! 🙂

 

ASP.NET Core Security Daj Się Poznać 2017 dotnetcore security

Bezpieczna aplikacja ASP.NET Core (cz. I) – atak CSRF

Gdy zaczynałem przygodę z aplikacjami webowymi, nie sądziłem, że istnieje aż tyle zagrożeń, na które trzeba zwrócić uwagę. Współczesne frameworki dają same w sobie wiele zabezpieczeń i o niektóre rzeczy nie musimy się już troszczyć. Jestem jednak pewny, że bardzo ważna jest świadomość niebezpieczeństwa na jakie są wystawione nasze aplikacje, a co dalej idzie nasi klienci.

Tutaj narodził się pomysł serii „Bezpieczna aplikacja ASP.NET Core”. W każdej z części chciałbym opisać zagrożenie oraz sposób w jaki się przed nim bronić. Bez owijania w bawełnę czas na pierwsze z nich – atak CSRF.

Czym jest CSRF?

Cross-site request forgery (CSRF lub XSRF) – jest to metoda ataku na serwis internetowy. Ofiarami tego ataku stają się często użytkownicy, którzy nieświadomie przesyłają do serwera żądania spreparowane przez inne osoby. Zazwyczaj celem ataku jest wykorzystanie uprawnień ofiary do wykonania operacji w systemie.

Cechy, które charakteryzują ten atak to:

  • Zazwyczaj dotyczą serwisów, które wymagają zalogowania się
  • Niewidoczne zmuszenie użytkownika (jego przeglądarki) do wykonania żądania HTTP
  • Żądanie polega na wykonaniu w jego imieniu jakiejś operacji zmieniającej stan systemu

Przykład ataku:

ASP.NET Antiforgery, czyli obrona

ASP.NET Core zawiera pakiet pod nazwą Antiforgery, który zapewnia ochronę przed atakami CSRF. Pakiet ten implementuje rozwiązanie oparte na tokenach, zalecane przez organizację OWASP. Specyfikacja tego zalecenia znajduje się tutaj.

W skrócie polega ono na mechanizmie wykorzystującym token set (2 tokeny). Powinny się one znaleźć w każdym zapytaniu trafiającym do walidatora Antiforgery. Set składa się z:

  • Tokenu przechowywanego w formie ciasteczka; jest on pseudolosowy i zaszyfrowany przy użyciu Data Protection API
  • Drugiego tokenu, który powinien znaleźć się w polu formularza, nagłówku żądania lub w innym ciasteczku

Tokeny generowane są po stronie serwera i zwracane do przeglądarki podczas odpowiedzi HTTP.

Walidator Antiforgery odrzuci request jeśli:

  • wygenerowane wartości tokenów się nie zgadzają
  • którykolwiek z tokenów nie został przesłany w odpowiedzi

Jak korzystać z pakietu Antiforgery?

Pakiet Microsoft.AspNetCore.Antiforgery jest dostępny jako zależność pakietu Microsoft.AspNetCore.Mvc. Otrzymujemy go w standardzie tworząc aplikację ASP.NET MVC. Serwisy Antiforgery są automatycznie rejestrowane wraz z serwisami MVC, czyli podczas wywołania  services.addMvc() w metodzie  Startup.ConfigureServices() .

Zacznijmy od początku, czyli generowania tokenów. Dobra wiadomość, ponieważ tokeny generują się automatycznie, o ile korzystamy z tag helperów do utworzenia formularza. Dla przykładu, formularz:

oraz

Spowoduje wygenerowanie:

Jeśli natomiast nie korzystamy z wyżej wymienionych helperów do tworzenia formularzy, możemy skorzystać z tag helpera  @Html.AntiForgeryToken() , który wygeneruje ukryte pole tokenu.

Zapytania AJAX’owe

W przypadku aplikacji SPA często wykonujemy zapytania AJAX’owe. Wtedy nie wysyłamy formularza, ale np. pojedynczą wartość. Istnieje również możliwość zabezpieczenia tych zapytań przed atakami CSRF. Wystarczy, aby token umieścić w nagłówku zapytania. Przykład:

A co z ciasteczkami?

Pakiet Antiforgery traktuje oba tokeny jako set, więc „ciasteczkowy” token generowany jest automatycznie wraz z polami w formularzu. Następnie jest on wysyłany do przeglądarki. Warto wspomnieć o kilku ważnych rzeczach:

  • Ciasteczko antiforgery jest oznaczone jako http only, więc nie jest dostępne z poziomu JavaScriptu
  • W przypadku kilku formularzy na stronie, ciasteczko generowane jest tylko raz i jest zgodne dla wszystkich tokenów w formularzach
  • Nazwa ciasteczka to „.AspNetCore.AntiForgery.#„, gdzie # to hash nazwy aplikacji. Nazwa ta może zostać zmieniona w konfiguracji
  • Jeśli chcemy zapewnić wymóg SSL, wystarczy ustawić RequireSsl na true. Ustawi to flagę secure ciasteczka

Walidacja tokenów

Do walidacji poprawności tokenów dostarczone zostały dwa filtry: ValidateAntiForgeryToken, AutoValidateAntiforgeryToken. Filtry te sprawdzają tokeny, a następnie przepuszczają zapytanie do serwera lub je odrzucają.

ValidateAntiForgeryToken

Jest to filtr, który możemy wykorzystać w akcji kontrolera, całym kontrolerze lub globalnie w aplikacji. Jego użycie np. w kontrolerze spowoduje walidację wszystkich akcji (również GET).

Jeśli chcemy zignorować walidację dla pojedynczej akcji, możemy ją oznaczyć filtrem IgnoreAntiforgeryToken.

AutoValidateAntiforgeryToken

Działa podobnie jak ValidateAntiForgeryToken, ale nie powoduje walidacji requestów następujących typów:

  • GET
  • HEAD
  • OPTIONS
  • TRACE

Użycie dla kontrolera:

Możemy również dodać ten filtr globalnie dla aplikacji

Zalecane jest używanie globalnie AutoValidateAntiforgeryToken, lub ValidateAntiForgeryToken dla konkretnych akcji kontrolora.

Konfiguracja Antyforgery

Konfiguracji możemy dokonać podczas rejestrowania serwisu. Do ustawienia jest wiele opcji bardzo dobrze opisanych w dokumentacji. Przykład konfiguracji:

Podsumowanie

Mam nadzieje, że w przystępny sposób przedstawiłem czym jest atak CSRF, oraz jak się przed nim bronić. Wiele rzeczy mamy dostępnych od razu podczas projektowania aplikacji. Wystarczy więc kilka linijek kodu, aby nasza aplikacja była bezpieczniejsza.

A na koniec serdecznie zapraszam do odwiedzania bloga. Będą pojawiać się kolejne części serii „Bezpieczna aplikacja ASP.NET Core” oraz inne wskazówki jak uczynić nasze aplikacje .NET’owe bardziej bezpiecznymi. 🙂

Daj Się Poznać 2017 imagesharp steganography

StegoCore – powrót po przerwie, podsumowanie 8 tygodnia

Cześć wszystkim. Weekend majowy spowodował kolejną przerwę w pracach nad projektem. Nie jestem z tego dumny, ale nie ma co się zamartwiać, tylko brać do roboty. Na szczęście w maju nie ma chyba żadnych długich weekendów i przerw. Jestem więc dobrej myśli, jeśli chodzi o postępy w projekcie StegoCore.

Tuż przed majówką kończyłem powoli implementację algorytmu Zhao & Koch. Jednak tak strasznie namieszałem, że nawet ja nie byłem w stanie odnaleźć się w kodzie. Postanowiłem, więc zacząć od początku. Czas na podsumowanie tego, co udało mi się zrobić.

Co słychać?

W implementacji algorytmu Zhao & Koch pojawiły się:

  • Dyskretna transformata kosinusowa, metoda kwantyzacji oraz ich odwrotności
  • Zamiana bloku 8×8 pikseli na macierz luminancji
  • Wstawianie jednego bitu danych do bloku 8×8

Dodatkowo w bibliotece do obsługi plików graficznych ImageSharp zmieniła się struktura bibliotek. W związku z tym musiałem zaktualizować zależności w projekcie. Postanowiłem, że raz na dwa tygodnie będę sprawdzał te zależności, tak aby było to na bieżąco aktualne. Jest to niestety konieczne, ponieważ biblioteka ImageSharp jest wciąż w fazie alpha.

Pracowałem nad projektem na laptopie z Windowsem i byłem bardzo mile zaskoczony, gdy wszystko działało jak należy. Tak więc trzy platformy przetestowane (aplikacja demowa postawiona jest na serwerze z linuxem).

Przypominam, że wszystkie zmiany w projekcie na bieżąco wrzucam na githuba.

Co dalej?

  • Kontynuacja implementacji algorytmu Zhao & Koch
  • Przetestowanie metod liczenia transformaty i kwantyzacji
  • Aktualizacja dema aplikacji webowej

A przede wszystkim lepiej organizować czas i poświęcać go na projekt każdego dnia.

Daj Się Poznać 2017 jetbrains steganography

StegoCore – podsumowanie po 7 tygodniach

Kolejne, szybkie podsumowanie tego, co słychać w projekcie.

Co słychać?

  • Implementacja algorytmu Zhao & Koch trwa dłużej niż się spodziewałem. Aktualnie kończę algorytm umieszczania znaku w pliku graficznym. Myślę więc, że do końca tygodnia uporam się z całym tematem. Wtedy też implementacja pojawi się na githubie. A po przejściu testów, wypuszczę kolejną wersję demo aplikacji.
  • Na jakiś czas zmieniłem IDE na Rider. Sprawuje się zaskakująco dobrze, więc warto sprawdzić. Jeśli ktoś nie słyszał, to zapraszam na moją recenzję.
  • I to w sumie tyle 😀 a z takich mniej technicznych informacji – w trakcie ostatnich świat wielkanocnych nie dałem rady zająć się aplikacją, więc chcąc nie chcąc zrobiłem sobie tygodniową przerwę.

Co dalej?

Dokończenie implementacji algorytmu Zhao & Koch. To główny cel na najbliższy tydzień. Dalsze plany zależą od otrzymanych wyników. Jeśli będą one zadawalające (czyli gdy ukryty sekret w pliku graficznym będzie odporny na kompresję JPEG), zajmę się kolejnym algorytmem. Jeśli nie – optymalizacja algorytmu Zhao & Koch.

Daj Się Poznać 2017 dotnetcore jetbrains os x

Alternatywa dla Visual Studio? Rider od JetBrains

Kiedy programujemy w C#, w większości przypadków jesteśmy skazani na Visual Studio. Czy słyszał ktoś kiedy o alternatywie? Jakiś czas temu, całkiem przypadkiem, natrafiłem na Rider – nowe IDE dla .NET od JetBrains. Jest on wciąż w trakcie powstawania, jednak stwierdziłem, że warto sprawdzić czy jest na co czekać. Testowany przeze mnie build to:  EAP build 20. Narzędzie jest multiplatformowe, więc testowałem na Windowsie i macOS.

Firmę JetBrains programiści .NET mogą kojarzyć z rozszerzenia do Visual Studio – Resharper. Jedni uważają, że jest świetne, bo pomaga programiście pisać szybciej kod i utrzymać w nim porządek. Inni nie przepadają za nim, w sumie nie wiem dlaczego. Być może dlatego, że szczególnie młodzi programiści mogą ślepo ufać Resharperowi i korzystać ze wszystkich jego podpowiedzi. Może to spowodować, że taki kod będzie mniej czytelny. Moim zdaniem Resharper jest świetnym narzędziem, ale trzeba wiedzieć kiedy i jak z niego korzystać.

Programiści Java mogą kojarzyć JetBrains z IntelliJ – IDE do Javy właśnie. Nigdy z niego nie korzystałem, ale słyszę że wśród kolegów z pracy zbiera dobre recenzje.

Dochodzimy tutaj do Rider’a, który jest połączeniem IntelliJ i Resharpera. Jak on się prezentuje? Sprawdźmy! 🙂

Instalacja

Ze strony JetBrains należy pobrać odpowiednią dla naszego systemu paczkę. Paczka ma około 300mb. Czas instalacji to kilka minut. Każdy kto instalował Visual Studio, wie że ten proces może potrwać kilkadziesiąt minut, więc tutaj duży plus dla Rider’a.

Po instalacji kreator przeprowadzi nas przez wstępną konfigurację, wybór kolorystyki, klawiszologii. Możemy również zainstalować opcjonalne rozszerzenia. Po tym możemy przystąpić do pracy. Do wyboru mamy otwarcie gotowego projektu lub stworzenie nowego.

Nowy projekt

Do wyboru mamy kilka szablonów dla .NET, Xamarin i .NET Core:

Do testów zdecydowałem się na MVC ASP.NEt Core Web App. Otrzymujemy gotowy szablon do pracy. Edytor prezentuje się następująco:

Edytor Rider

Zarówno na macOS i Windows buildowanie oraz uruchomienie aplikacji przebiegło bez żadnych problemów. Pozytywnie zaskoczyło mnie buildowanie na Windows dużej solucji z aplikacją w .NET. Wszystko działa jak należy. Jedyny problem jaki napotkałem to brak możliwości debugowania aplikacji w .NET Core. Nie jest to winą Rider’a, a postanowień licencyjnych. Wykorzystanie pakietu umożliwiającego debugowanie aplikacji .NET Core możliwe jest tylko w Visual Studio, Visual Studio Code i Xamarin Studio.

Pomyślałem, że jednak najlepiej będzie jak przetestuję Rider’a w praktyce. Uruchomiłem więc projekt StegoCore i przystąpiłem do pracy. Poniżej moje uwagi podzielone na plusy i minusy.

Plusy

  • Wspiera większość projektów .NET, .NET Core i opartych na Mono
  • Multiplatformowy – działa na Windows, macOS i Linux
  • Działa bardzo płynnie, nie zauważyłem żadnych przycięć itp; zdarzają się czasami jakieś błędy, ale nie powodują wyłączania aplikacji
  • Wbudowany Resharper – refaktoryzacja kodu, analiza kodu
  • W pełni sprawny menadżer pakietów NuGet

    Rider NuGet

  • Unit test runner – pozwala uruchamiać i debugować testy NUnit i xUnit.net

    Rider Unit Test Runner

  • Wbudowane wsparcie dla systemów kontroli wersji: Git, Subversion, Mercurial, Perforce i TFS
  • Możliwość połączenia się do bazy danych (testowałem na MS SQL)
  • Dekompilator

    Rider decompilator

    Przy użyciu Go to Declaration na dowolnym elemencie biblioteki zostaniemy przeniesieni do jej kodu źródłowego. W sytuacji gdy jest on niedostępny dekompilator Rider’a przygotowuje dla nas kod C# biblioteki.

  • Rozszerzalność przez pluginy

Minusy

  • Pojawiające się błędy; przy czym trzeba mieć na uwadze że jest to wciąć wersja early build
  • Podczas otwarcia istniejącego projektu ASP.NET MVC nie zostały wczytane pliki widoków *.cshtml
  • Brak Package Manager Console
  • Brak możliwoście debugowania aplikacji w .NET Core

Podsumowanie

Pierwszy kontakt z Rider wyszedł pozytywnie. Praca w tym IDE jest przyjemna i szybka, a o to przecież chodzi. Projekt rozwija się bardzo dobrze i trzeba się cieszyć, że w końcu rośnie konkurencja dla Visual Studio. Być może zmotywuje to Microsoft do lepszej pracy nad swoim produktem. Mocno na to liczę, bo myślę że wielu z programistów wolałoby mieć jakąś alternatywę przy wyborze IDE.

Zachęcam również Was do spojrzenia na Rider’a. Aktualna wersja umożliwia darmowe przetestowanie i zapoznanie się z IDE.