Archiwa tagu: Java

“Stałe” w Javie:
final, static, i niemodyfikowalność

2018-01-24 ynka 3 komentarze

Wpis z dedykacją dla D, który postanowił nauczyć się nowego języka programowania i, chcąc utworzyć stałą (constant – słowo kluczowe niedostępne w Javie), zapytał mnie o relację pomiędzy terminami: final, static i obiekt niemodyfikowalny (immutable).

final

Słowo final zmienia znaczenie w zależności od kontekstu, ale zawsze oznacza, że coś jest “ostateczne” i po utworzeniu nie da się już tego zmienić.

Klasa final

Jeśli klasę oznaczymy słowem final, nie będzie można jej rozszerzać, czyli tworzyć jej podklas. Zatem będzie to “ostateczna” wersja danej klasy.

public final class MojaOstatecznaKlasa {}

// Błąd kompilacji:
public class Proba extends MojaOstatecznaKlasa {}

public final class MojaOstatecznaKlasa {}

// Błąd kompilacji:

public class Proba extends MojaOstatecznaKlasa {}

Metoda final

Z metodami jest podobnie jak z klasami. Jeśli słowem final oznaczymy metodę, nie będzie można jej przesłaniać w klasach pochodnych – czyli mamy do czynienia z “ostateczną” wersją danej metody.

public class Klasa {
    public void m1() {}
    public final void m2() {}
}

public class Podklasa extends Klasa {
    public void m1() {}  // OK
    public void m2() {}  // Błąd kompilacji
}

public class Klasa {

public void m1() {}

public final void m2() {}

}

public class Podklasa extends Klasa {

public void m1() {} // OK

public void m2() {} // Błąd kompilacji

}

Zmienna final

Jeśli jako final opiszemy zwykłą zmienną w środku kodu, wartość (a dokładniej: wartość w przypadku typów prostych lub referencję w przypadku obiektów) będzie można jej przypisać maksymalnie raz. Na przykład:

final int x; // OK
x = 3; // OK
System.out.println(x);
x = 4; // błąd kompilacji

final int x; // OK

x = 3; // OK

System.out.println(x);

x = 4; // błąd kompilacji

Pole klasy final

Jeśli słowem final oznaczymy pole klasy, będzie to oznaczało, że wartość (lub referencję, jak powyżej) można mu nadać tylko raz – będzie ona ostateczna. Wartość tę można przypisać na dwa sposoby – albo “w miejscu”, przy definiowaniu klasy, albo w konstruktorze. Nie da się tego zrobić później. Jeśli pole final nie otrzyma wartości w żadnym z tych dwóch miejsc, kompilator zaprostesuje.

Za przykład niech posłuży fragment definicji klasy String z Javy 8:

public final class String
    implements java.io.Serializable, Comparable<String>, CharSequence {
    // inicjalizacja w konstruktorze
    private final char value[];

    // inicjalizacja w miejscu
    private static final long serialVersionUID = -6849794470754667710L;

    // konstruktor inicjalizujący pole final
    public String(String original) {
        this.value = original.value;
        this.hash = original.hash;
    }

public final class String

implements java.io.Serializable, Comparable<String>, CharSequence {

// inicjalizacja w konstruktorze

private final char value[];

// inicjalizacja w miejscu

private static final long serialVersionUID = -6849794470754667710L;

// konstruktor inicjalizujący pole final

public String(String original) {

this.value = original.value;

this.hash = original.hash;

}

Parametr final

Jeśli jako final oznaczymy parametr metody, zablokujemy możliwość zmiany jego wartości. I tak nie powinniśmy tego robić – to jedna z dobrych praktyk. Użycie słowa final oficjalnie nas do niej zobowiązuje.

public void dontMessWithParams(final int p1, int p2){
&nbsp; p2 = p1; // OK!
&nbsp; p1 = p2; // Błąd kompilacji.
}

public void dontMessWithParams(final int p1, int p2){

  p2 = p1; // OK!

  p1 = p2; // Błąd kompilacji.

}

static

Słowo kluczowe static nie musi być łączone ze stałymi. Chcę jednak rozebrać je na czynniki pierwsze, ponieważ często spotyka się je razem z final w następujących konstrukcjach (ta akurat znów klasy String):

private static final long serialVersionUID = -6849794470754667710L;

1	private static final long serialVersionUID = -6849794470754667710L;

Słowo “statyczny”, jako przeciwieństwo “dynamiczny” można w uproszczeniu rozumieć w ten sposób, że opisany nim byt do życia nie potrzebuje obiektów (tworzonych dynamicznie).

Pole klasy static

Jeśli pole klasy zostanie oznaczone jako static (jak w przykładzie bezpośrednio powyżej), oznacza to, że jest współdzielone przez wszystkie obiekty danej klasy. Można uzyskać do niego dostęp odwołując się do nazwy obiektu lub do nazwy klasy – efekt będzie ten sam. Pamięć jest przydzielana tylko raz, podczas ładowania klasy.

W ten sposób można definiować ważne stałe albo różnego rodzaju liczniki (np. liczba egzemplarzy danej klasy – wówczas w konstruktorze zwiększamy wartość tego pola o 1).

Metoda static

Metoda static jest współdzielona przez wszystkie obiekty, można ją także wywołać odnosząc się bezpośrednio do nazwy klasy, bez potrzeby tworzenia obiektu.

Metoda ta ma dostęp jedynie do statycznych atrybutów (pól i metod) danej klasy. Co za tym idzie, nie może też używać słów this ani super.

W ten sposób często definiuje się różne metody pomocnicze – na przykład większość metod w klasy Math.

Najbardziej znana metoda statyczna to oczywiście main.

public static void main(String[] args){
  OtherClass myObject = new OtherClass("Hello World!");
  System.out.print(myObject);
}

public static void main(String[] args){

OtherClass myObject = new OtherClass("Hello World!");

System.out.print(myObject);

}

Blok kodu static

Wewnątrz definicji klasy można umieścić statyczny blok kodu, w którym, na przykład, zainicjalizujemy jakieś statyczne pola. Zostanie on wywołany w trakcie ładowania klasy.

Mimo że bloki statyczne rzadko pojawiają się w kodzie, kolejność ich wykonywania to konik wielu profesorów informatyki na egzaminach z programowania obiektowego.

class Klasa{
  static{
    System.out.println("blok statyczny");
  }
}

class Klasa{

static{

System.out.println("blok statyczny");

}

Zagnieżdżona klasa static

Jeśli klasę zagnieżdżoną opiszemy słowem static, będzie ona mogła odwoływać się jedynie do statycznych atrybutów swojej klasy zewnętrznej.

Obiekty niemodyfikowalne

Obiekt niemodyfikowalny (immutable) to taki obiekt, w którym po użyciu konstruktora nie można już dokonywać żadnych zmian.

Przekazując taki obiekt, mamy pewność, że nie zostanie on zmieniony przez żaden kod – ani nasz, ani znajdujący się pod kontrolą kogoś innego. Obiekty niemodyfikowalne są wybawieniem podczas pracy z wątkami, ponieważ nie trzeba synchronizować ich stanu.

Niemutowalne są na przykład obiekty klasy Integer.

Oto fragment definicji tej klasy:

private final int value;
   
public Integer(int value) {
    this.value = value;
}

public Integer(String s) throws NumberFormatException {
    this.value = parseInt(s, 10);
}

private final int value;

public Integer(int value) {

this.value = value;

}

public Integer(String s) throws NumberFormatException {

this.value = parseInt(s, 10);

}

Wartość value (czyli liczbę typu prostego int opakowywaną przez klasę Integer) można ustawić jedynie przy użyciu któregoś z konstruktorów. Nie da się jej zmienić później. Klasa Integer ma szereg metod pozwalających uzyskać dostęp do tej wartości, ale sama wartość wewnątrz obiektu tej klasy nigdy nie zostanie zmieniona. Nie jest do tego potrzebne słowo final (które zostało tu użyte) – wystarczyłaby sama enkapsulacja. final daje nam jednak niezbitą pewność, że po inicjalizacji nikt już tej wartości nie zmieni.

Co ma zrobić osoba, która potrzebuje innej liczby Integer? Będzie musiała po prostu utworzyć nowy obiekt.

Integer result = new Integer(1); // obiekt
result = new Integer(result.intValue() + 1); // nowy obiekt
result = new Integer(result.intValue()) + 1; // czary-mary, też nowy obiekt
System.out.println(result.doubleValue()); // 3.0

Integer result = new Integer(1); // obiekt

result = new Integer(result.intValue() + 1); // nowy obiekt

result = new Integer(result.intValue()) + 1; // czary-mary, też nowy obiekt

System.out.println(result.doubleValue()); // 3.0

Nie istnieje słowo kluczowe immutable. Obiekty niemodyfikowalne tworzy programista, korzystając z mechanizmu enkapsulacji oraz słowafinal.

Wszystko razem, czyli static final String

Rozważmy definicję poniższych pól:

public static final int ERROR_CODE = 404;
public static final String RESPONSE = "Ouch";
public static final Client CLIENT = new Client("John Snow");

public static final int ERROR_CODE = 404;

public static final String RESPONSE = "Ouch";

public static final Client CLIENT = new Client("John Snow");

Wszystkie trzy pola są opisane jako static final, czyli są to stałe współdzielone przez wszystkie obiekty danej klasy.

W pierwszym przypadku mamy stałą typu prostego. Sprawa jest oczywista – nie wolno nam zmienić jej wartości. Nie możemy przypisać pod ERROR_CODE żadnej innej wartości.

W drugim przypadku mamy obiekt. Jest to, dodatkowo, obiekt niemodyfikowalny (immutable). Uczący się Javy kolega zapytał ostatnio, po co dodawać final, skoro obiekt jest niemodyfikowalny. Po co? – żeby nie można było zmienić referencji. Gdyby nie słowo final, możliwa byłaby następująca operacja:

RESPONSE = "Ooops!"; // Możliwe bez użycia final

1	RESPONSE = "Ooops!"; // Możliwe bez użycia final

Obiekt String z wartością “Ouch” jest co prawda niemodyfikowalny (nie można zmienić przechowywanej w nim wartości), ale nic nie stałoby na przeszkodzie, żeby podmienić obiekty przypisane do zmiennej RESPONSE. Użycie final nas przed tym chroni.

W ostatnim przypadku mamy zwykły (modyfikowalny) obiekt ze zmiennym stanem, przypisany do pola oznaczonego jako final. Co to oznacza? Że co prawda, dzięki final, nie możemy zmienić referencji (to będzie nadal tem sam obiekt) ale ciągle możemy nieźle namieszać w jego wnętrzu przy użyciu API:

// Nie skompiluje się, 
// nie wolno nam przypisać tu nowego obiektu.
CLIENT = new Client("Aegon Targaryen");

// Nic nie stoi na przeszkodzie. 
// Słowo final chroni referencję. 
// Obiekt musi chronić się sam.
CLIENT.setName("Aegon");

// Nie skompiluje się,

// nie wolno nam przypisać tu nowego obiektu.

CLIENT = new Client("Aegon Targaryen");

// Nic nie stoi na przeszkodzie.

// Słowo final chroni referencję.

// Obiekt musi chronić się sam.

CLIENT.setName("Aegon");

Jasne?

Odpowiedne korzystanie z javowych “stałych”, wartości statycznych i obiektów niemodyfikowalnych pozwala na oszczędzenie miejsca w pamięci i stworzenie czytelnego, łatwego w utrzymaniu kodu.

Średnio zaawansowane

Wyrażenia regularne w Javie – figle i psikusy

2017-01-07 ynka Dodaj komentarz

To trzeci (i na jakiś czas ostatni) z serii wpisów na temat wyrażeń regularnych w Javie, po O wyrażeniach regularnych. Podstępna różnica pomiędzy find i matches oraz Wyrażenia regularne dla nieprogramistów. Historycznie ten jest najwcześniejszy – to zaktualizowana wersja tekstu z mojego poprzedniego bloga.

Poruszam tu bardzo podstawowe kwestie, które potrafią jednak dać się we znaki. Rozwiązanie tych paru niewinnych problemików kosztowało mnie niemało czasu i nerwów. Liczę, że kiedy jakaś zbłąkana dusza znajdzie się w tej samej sytuacji, Google zaprowadzi ją prosto w moje troskliwe ramiona.

Artykuł powstał podczas mojej pracy nad narzędziem do przekształcania metadanych.

Psikus 1: znaki ucieczki w wyrażeniach wczytywanych z zewnętrznego pliku

Załóżmy, że wyrażenie (które chcemy wczytać z zewnętrznego pliku) w zwykłym kodzie Javy wygląda tak:

Pattern yearPattern = Pattern.compile("^\\d{2}[-/]\\d{2}\\s*w\\.$");

1	Pattern yearPattern = Pattern.compile("^\\d{2}[-/]\\d{2}\\s*w\\.$");

Linia przedstawia zakres wieków, do którego dopasuje się na przykład linia:

14-16 w.

14-16 w.

Proste, prawda?

Prawda – ale do czasu. Problemy pojawiły się, kiedy zaczęłam wczytywać wyrażenia regularne zapisane w zewnętrznym pliku. Wczytywałam między innymi następujący fragment:

^\\d{2}[-/]\\d{2}\\s*w\\.$

1	^\\d{2}[-/]\\d{2}\\s*w\\.$

Wszystko przestało działać. Łańcuchy znaków, które bez najmniejszych wątpliwości powinny były dopasować się do wyrażenia, przechodziły niezauważone. Po godzinie analiz niebezpiecznie zbliżałam się do stanu, w którym myślałam, że oszalał albo świat dokoła mnie. Wtedy na szczęście nadeszła pora lunchu. Opowiedziałam o problemie nad talerzem naleśników, a jeden z kolegów zadał oczywiste w sumie pytanie – czy na pewno dobrze wyeskejpowałam (przepraszam!!!) wszystkie znaki specjalne. I wtedy wreszcie nadeszło olśnienie: nie, nie zrobiłam tego dobrze. Przeeskejpowałam je.

Znaki specjalne, takie jak d, w wyrażeniu regularnym oznaczające cyfrę, należy poprzedzić tzw. symbolem ucieczki, czyli w tym wypadku backslashem (ukośnikiem wstecznym). W łańcuchach znaków w kodzie Javy konieczne jest wprowadzenie dodatkowego backslasha, gdyż musimy jeszcze odebrać specjalne znaczenie samemu backslashowi (musimy poprzedzić znak ucieczki znakiem ucieczki…). Tyle razy widziałam te dwa ukośniki w parze, że zupełnie zapomniałam o tym, że w zewnętrznym pliku należy użyć tylko jednego!

Psikus 2: flagi

To bardzo proste. Załóżmy, że wyrażenie nie ma brać pod uwagę wielkość liter. Normalnie oznaczamy to tak:

Pattern yearPattern = Pattern.compile("^\\d{2}[-/]\\d{2}\\s*w\\.$",Pattern.CASE_INSENSITIVE);

1	Pattern yearPattern = Pattern.compile("^\\d{2}[-/]\\d{2}\\s*w\\.$",Pattern.CASE_INSENSITIVE);

Świetnie, tylko jak przekazać tę flagę, jeśli wyrażenie jest wczytywane z zewnątrz? Wychodzi na to, że flagę, poprzedzoną znakiem zapytania, należy umieścić w nawiasie na początku wyrażenia. Ignorowanie wielkości liter (przy okazji, poznałam ostatnio nowe słowo – kasztowość) to literka i, zatem dodajemy (?i). Ostatecznie, w kodzie wyrażenie wygląda tak:

(?i)^\\d{2}[-/]\\d{2}\\s*w\\.$

1	(?i)^\\d{2}[-/]\\d{2}\\s*w\\.$

a poza kodem, z pojedynczymi ukośnikami, tak:

(?i)^\d{2}[-/]\d{2}\s*w\.$

1	(?i)^\d{2}[-/]\d{2}\s*w\.$

Psikus 3: String.replaceAll

W pewnym brzegowym przypadku mój kod, w wyniku wczytania wyrażeń regularnych z pliku, wykonywał operację, którą można w uproszczeniu zapisać tak:

String s = "stara treść".replaceAll(".*","nowa treść")

1	String s = "stara treść".replaceAll(".*","nowa treść")

Po wykonaniu się tego kodu spodziewałam się, że treść zostanie całkowicie zastąpiona, czyli wartością s będzie:

nowa treść

1	nowa treść

skoro * jest zachłannym kwantyfikatorem, to .* powinno dopasować się do całego napisu niezależnie od okoliczności.

Wyobraźcie sobie moje zaskoczenie (czy raczej przerażenie), gdy okazało się, że s przyjęło wartość:

nowa treśćnowa treść

1	nowa treśćnowa treść

Próbowałam użyć jeszcze bardziej zaborczego kwantyfikatora *+, ale efekt był ten sam. Byłabym mniej zaskoczona, gdyby .* zostało dopasowane do każdej litery w łańcuchu. Jakim cudem dopasowało się dokładnie dwa razy?

Dalsze śledztwo wykazało, że przebieg akcji jest następujący:

Cały łańcuch dopasowuje się do .* i jest zamieniany na łańcuch “nowa treść”.
Po dopasowaniu z oryginalnego łańcucha znaków nie zostaje nic, a raczej zostaje łańcuch "". Metoda replaceAll jeszcze raz sprawdza możliwość dopasowania i okazuje się, że "" także pasuje do .*, zatem pusty łańcuch również zostaje wymieniony.
Zasadniczo można by kontynuować i w nieskończoność dodawać na końcu "nowa zawartość", jednak na szczęście (?) dana pozycja w łańcuchu znaków jest traktowana jako sprawdzona i wykonanie metody kończy się.

Pozdrawiam siostry i braci w cierpieniu.

Średnio zaawansowane

O wyrażeniach regularnych. Podstępna różnica pomiędzy find i matches

2016-11-01 ynka 5 komentarzy

Wyrażenia regularne to jedno z zagadnień dzielących programistów. Są tacy, którzy je uwielbiają i ci, którzy szczerze ich nienawidzą.

Sama zaliczam się do pierwszej grupy, być może z powodu upodobań lingwistycznych (wyrażenia regularne ≈ języki regularne ≈ automaty skończone). Wyrażenia regularne pozwalają na bardzo zwięzły i precyzyjny zapis warunków wyszukiwania, które – gdyby ograniczyć się do tradycyjnych konstrukcji zawartych w danym języku programowania – mogłyby zająć wiele linii. Po stronie minusów należy zapisać trudność zrozumienia dłuższych wyrażeń regularnych, zwłaszcza, jeśli są dziełem kogoś innego.

W tym wpisie chcę podzielić się swoją niedawną przygodą optymalizacyjną. W najbliższym czasie (czyli przed końcem roku) wrzucę jeszcze stary tekst o pułapkach, w które można wpaść pisząc wyrażenia regularne w Javie oraz nowy o tym, jak regeksy mogą przydać się nieprogramistom w ich codziennych zadaniach.

Do rzeczy.

Napisałam ostatnio kod analizujący treść stron internetowych. Mniejsza z tym, po co to robił. Stanowił część większej całości (moduł mavenowy) i podobnie jak reszta kodu korzystał m.in. z Javy 8 i biblioteki JSoup. Napisałam masę testów jednostkowych, testowałam na kilkuset stronach… Jednak prawdziwa próba ognia miała nadejść kilka dni po oddaniu przeze mnie projektu, podczas uruchomienia pełnego łańcucha przetwarzania na kilkudziesięciu (kilkuset?) tysiącach stron.

W pięciu przypadkach mój kod zawiesił się na ponad dobę.

Naprawa, kiedy już do niej zasiadłam zajęła mi niecałą godzinę. Co się okazało? W kilku miejscach w moim kodzie użyłam metody Element::getElementsByAttributeValueMatching i dałam się zwieść nazwie. Na swoją obronę mam to, że Javadoc też wprowadza w błąd. Otóż wyobraziłam sobie, że gdzieś w głębinach metoda wywołuje metodę Matcher::matches, dlatego szukany przeze mnie fragment otoczyłam znakami ".*" przed i po właściwym wzorcu.

Skoro już wszystko się zapętliło, zajrzałam do środka, a tam:

...
return element.hasAttr(key) && pattern.matcher(element.attr(key)).find();
...

...

return element.hasAttr(key) && pattern.matcher(element.attr(key)).find();

...

Podstawowa różnica pomiędzy wspomnianą już Matcher::matches a Matcher::find jest taka, że matches szuka pełnych dopasowań (cały łańcuch znaków musi pasować do wzorca), a find zadowoli się dopasowaniem w środku łańcucha znaków (i może takich dopasowań zwrócić wiele).

Czyli jeśli nasz wzorzec ma postać "[abc]e", to find dopasuje go do łańcucha "cel", w przeciwieństwie do metody matches:

Pattern p = Pattern.compile("[abc]e");
String a = "cel";
System.out.println(p.matcher(a).find()); //true
System.out.println(p.matcher(a).matches()); //false

Pattern p = Pattern.compile("[abc]e");

String a = "cel";

System.out.println(p.matcher(a).find()); //true

System.out.println(p.matcher(a).matches()); //false

Jeśli dodam na początku i na końcu wzorca uniwersalne symbole ".*" (uzyskując ".*[abc]e.*") to również metoda matches uzna, że mamy dopasowanie:

Pattern p = Pattern.compile(".*[abc]e.*");
String a = "cel";
System.out.println(p.matcher(a).find()); //true
System.out.println(p.matcher(a).matches()); //true

Pattern p = Pattern.compile(".*[abc]e.*");

String a = "cel";

System.out.println(p.matcher(a).find()); //true

System.out.println(p.matcher(a).matches()); //true

Jednak jednak użyjemy metody find przy odpowiednio złożonym i zagnieżdzonym wyrażeniu regularnym z opcjonalnymi elementami i przy odpowiednio długim tekście, pojawi się tyle możliwości dopasowania wyrażenia do łańcucha znaków, że wejdziemy na obszar tzw. Catastrophic Backtracking (katastrofalne nawracanie?).

Moja poprawka sprowadziła się, oczywiście, do usunięcia czterech znaków: ".*" z początku i końca wyrażenia przekazanego jako argument metodzie Element::getElementsByAttributeValueMatching.

Jaka z tego nauczka? Rutynowo zaglądać w cudzy kod, niestety.

PS. Polecam krzyżówki regeksowe: Regex Crossword.

Tajemne szyfry (zaawansowane)

Maven ➝ Pivotal. Automatyczne wdrożenie w chmurze

2016-07-29 ynka 1 komentarz

Pisałam już o tym, jak uruchomić aplikację w chmurze Pivotal oraz jak podłączyć do niej bazę danych. W tym odcinku pokażę, jak ułatwić sobie życie i bez wysiłku wdrażać nowe wersje aplikacji zaraz po ich poprawnym zbudowaniu. Wykorzystam do tego plugin Cloud Foundry Maven (Cloud Foundry ≈ Pivotal).

Cel

Wdrożenie nowej wersji w chmurze po wydaniu jednego polecenia. Spoiler – w tym wypadku będzie to:

mvn clean package cf:push

1	mvn clean package cf:push

Realizacja celu

Plugin w pom.xml

    <build>
        <plugins>
            ...
            <plugin>
                <groupId>org.cloudfoundry</groupId>
                <artifactId>cf-maven-plugin</artifactId>
                <version>1.1.3</version>
            </plugin>
            ...
        </plugins>
    </build>

<build>

...

<groupId>org.cloudfoundry</groupId>

<artifactId>cf-maven-plugin</artifactId>

</plugin>

...

</plugins>

</build>

Pierwszy tutorial, jak znalazłam w archiwach Cloud Foundry, twierdził, że pluginu nie ma w głównym repozytorium Mavena – konieczne miało być dodanie wpisu w sekcji pluginRepositories pliku pom.xml. Od tego czasu sytuacja uległa zmianie (https://mvnrepository.com/artifact/org.cloudfoundry/cf-maven-plugin) i nie trzeba już zawracać sobie tym głowy.

Konfiguracja pluginu w pom.xml

W moim wypadku wygląda tak:

            <plugin>
                <groupId>org.cloudfoundry</groupId>
                <artifactId>cf-maven-plugin</artifactId>
                <version>1.1.3</version>
                <configuration>
                    <server>mycloudfoundry-instance</server>
                    <org>namiekko</org>
                    <space>development</space>
                    <appname>szafbook</appname>
                    <target>http://api.run.pivotal.io</target>
                    <url>http://szafbook.cfapps.io/</url>
                    <memory>1024</memory>
                    <services>
                        <service>
                            <name>mLabMongoDB</name>
                            <label>mLabMongoDB</label>
                            <provider>mLab</provider>
                            <version>n/a</version>
                            <plan>sandbox</plan>
                        </service>
                    </services>
                </configuration>
            </plugin>

<groupId>org.cloudfoundry</groupId>

<artifactId>cf-maven-plugin</artifactId>

<server>mycloudfoundry-instance</server>

<org>namiekko</org>

<space>development</space>

<appname>szafbook</appname>

<target>http://api.run.pivotal.io</target>

<url>http://szafbook.cfapps.io/</url>

<name>mLabMongoDB</name>

<label>mLabMongoDB</label>

<plan>sandbox</plan>

</service>

</services>

</configuration>

</plugin>

Czym jest mycloudfoundry-instance? O tym poniżej.

Dane logowania

Dane logowania można podać w konsoli (ale wtedy nie będzie to wdrożenie za pomocą jednego polecenia!), w treści pom.xml (ale wtedy trafią one do systemu kontroli wersji, być może publicznego!), albo zdefiniować je w przeznaczonym dla Mavena pliku settings.xml na własnym dysku. Więcej o samym pliku settings.xml można poczytać tutaj. Szukać go należy (lub utworzyć) na jednej z dwóch ścieżek:

${maven.home}/conf/settings.xml (dla całej instalacji Mavena)
${user.home}/.m2/settings.xml (per użytkownik)

U mnie wpis wygląda tak:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  ...
  <servers>
     ...
	<server>
	  <id>mycloudfoundry-instance</id>
	  <username>justyna@...</username>
	  <password>...</password>
	</server>
  </servers>
  ...
</settings>

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">

...

...

<id>mycloudfoundry-instance</id>

<username>justyna@...</username>

</server>

</servers>

...

</settings>

id to nadana przeze mnie nazwa, za pomocą której mogę odwołać się do tej konfiguracji w pliku pom.xml (linia 6 w listingu z konfiguracją).

Więcej informacji

Więcej informacji na temat korzystania z pluginu można znaleźć na stronie https://docs.run.pivotal.io/buildpacks/java/build-tool-int.html.

Napotkane problemy

Wcześniej musiałam tylko raz wyklikać powiązanie pomiędzy aplikacją a usługą MongoDB (mLab). Przy wdrożeniach przez konsolę cf konfiguracja ta była zachowywana. Dlatego początkowo pominęłam definicję serwisów w konfiguracji pluginu (linie 13-21). Błąd! – baza danych była przez to “odczepiana” od aplikacji przy wdrożeniu.

Kod

Jak zwykle w GitHub.

PS.

Wiedziałam, że po zakończeniu konkursu Daj się poznać wrócę do swojego projektu, ale nie byłam pewna, czy chcę na ten temat blogować. Co mnie przekonało? To, że kiedy zapomniałam, jakie czynności należy wykonać w celu podłączenia bazy danych do aplikacji w chmurze, nie musiałam szukać daleko. Zerknęłam jedynie we własne wcześniejsze teksty! W ten sposób zostałam swoim najwdzięczniejszym czytelnikiem.

Tajemne szyfry (zaawansowane)

Strumienie w Javie 8

2016-07-15 ynka 5 komentarzy

Odkrywam na poważnie Javę 8. Jestem tak zachwycona strumieniami, że aż się muszę podzielić!

Przykład (Java 8)

Zacznę od przykładu. Napisałam ostatnio taki kod:

    return map.entrySet().stream()
                .filter(entry -> entry.getValue() > 0)
                .map(entry -> entry.getKey())
                .toArray(String[]::new);

return map.entrySet().stream()

.filter(entry -> entry.getValue() > 0)

.map(entry -> entry.getKey())

.toArray(String[]::new);

Co robi ten fragment? Zwraca tablicę zawierającą te klucze z mapy, których wartości są większe od 0.

Dokładniej:

Odwołuje się do obiektu mapy (map).
Pobiera zbiór par klucz-wartość przechowywany w tej mapie (entrySet()).
Zamienia ten zbiór na strumień, albo, poprawniej, odczytuje ten zbiór poprzez strumień (stream()).
Filtruje strumień, pozostawiając w nim (a właściwie w nowym strumieniu) tylko te pary klucz-wartość, w których wartość jest większa od zera. Do filtrowania używana jest lambda, czyli definiowana w miejscu anonimowa funkcja zwracająca wartość typu boolean, przekazana jako parametr (.filter(entry -> entry.getValue() > 0)).
Na wszystkich elementach (typu Map.Entry) pozostałych w strumieniu wykonywana jest funkcja zwracająca klucz (.map(entry -> entry.getKey())).
Na samym końcu wywoływana jest metoda toArray z interfejsu Stream, do której przekazujemy generator (toArray(String[]::new)), czyli funkcję, dzięki której strumień wie, ile pamięci zaalokować. Istnieje bezargumentowa wersja tej metody, tyle że przy jej użyciu otrzymamy tablicę obiektów typu Object.

Przykład (Java 7 i starsze)

Po napisaniu tych paru linijek (ciągle mam problemy z formatowaniem takiego kodu i liczeniem linii) zaczęłam się zastanawiać, jak wyglądałby ten kod w wersji przedstrumieniowej. Musiałoby to być coś takiego:

        List<String> list = new ArrayList<>();
        for(Map.Entry<String, Integer> entry : map.entrySet())
            if(entry.getValue() > 0)
                list.add(entry.getKey());
        return list.toArray(new String[list.size()]);

List<String> list = new ArrayList<>();

for(Map.Entry<String, Integer> entry : map.entrySet())

if(entry.getValue() > 0)

list.add(entry.getKey());

return list.toArray(new String[list.size()]);

Porównanie

Kilka różnic:

	Java 7	Java 8
Definicja zadania	Algorytm / opis procedury	Strumień przetwarzania / deklaracja oczekiwanego wyniku
Kolejność przetwarzania	Sekwencyjna	Nieokreślona – może zostać poddana optymalizacji
Typy danych	W niektórych miejscach, jak pętla for, trzeba je powtórzyć	Kompilator jest w stanie je wywnioskować, nie trzeba ich powtarzać (np. w definicjach lambd)
Układ kodu	Kod z blokami i wcięciami	Łańcuch wywołań (oczywiście w przypadku bardziej złożonych lambd również trzeba stosować bloki)

Uczciwie dodam, że po stronie minusów stosowania strumieni muszę na razie dopisać debugowanie. W przypadku wystąpienia problemu, odrobinę trudniej jest mi się zorientować, co dokładnie poszło nie tak.

Czy naprawdę nie było innego wolnego słowa?

Strumieni z Javy 8 (z pakietu java.util.stream) nie należy mylić ze strumieniami służącymi do obsługi wejścia i wyjścia (z pakietu java.io). Co za geniusz wymyślił tę nazwę – nie wiem. Być może chodziło i uniknięcie jeszcze gorszego słowa “monada”.

Jeśli chcesz wyszukać w Google informacji na temat “nowych” strumieni, używaj nazwy “Java 8 Streams”.

Co się dzieje w tle?

Strumień nie przechowuje własnych danych – można uznać go za “widok” na dane pochodzące z kolekcji lub innego źródła. Podczas potokowego przetwarzania danych na przykład za pomocą kilku kolejnych operacji map, strumień nie jest modyfikowany, tylko zwracany jest wtedy nowy strumień, oferujący inne dane.

Wniosek

Wygodne. Używać.

Kiedy po raz pierwszy, w ramach prezentacji na Poznań JUG, zobaczyłam strumienie, nie byłam zachwycona. Pomyślałam sobie, że to kolejny wynalazek, który świetnie działa na wymyślonych, zabawkowych przykładach, a który okazuje się bezużyteczny w prawdziwym świecie. Nic bardziej mylnego, w pracy korzystam z nich teraz regularnie.

PS. Sklejanie Stringów

Od lat jeden z najbardziej irytujących braków w bibliotece standardowej Javy to sklejacz łańcuchów znaków. Teraz, jeśli chcesz za pomocą np. średników połączyć słowa przechowywane w kolekcji, nie już musisz pisać specjalnej funkcji ani załączać zewnętrznych bibliotek. Można tak:

String joined = list.stream().collect(Collectors.joining(";"));

1	String joined = list.stream().collect(Collectors.joining(";"));

Średnio zaawansowane

Aktywacja konta poprzez email

2016-05-30 ynka 1 komentarz

Poprzedni wpis poświęciłam kwestii wysyłania maili przez aplikację napisaną w Javie.

Kontynuując, teraz chcę upewnić się, że świeżo zarejestrowany użytkownik to człowiek (a nie bot) i że podał poprawny adres email. Poniżej opisuję kroki prowadzącego do tego celu.

Krok 1: nieaktywny użytkownik z wygenerowanym kodem

Po wypełnieniu formularza rejestracyjnego obiekt reprezentujący użytkownika jest zapisywany w bazie danych jako nieaktywny. Razem z nim zapisywany jest losowo wygenerowany kod do aktywacji konta. Na tym etapie użytkownik nie może się logować, nie zna też przypisanego mu kodu.

...
@Document
public class User {
	...
	private boolean confirmationStatus;
	private String confirmationId;
	...
}

...

@Document

public class User {

...

private boolean confirmationStatus;

private String confirmationId;

...

}

    private String createConfirmationID() {
        return java.util.UUID.randomUUID().toString();
    }

private String createConfirmationID() {

return java.util.UUID.randomUUID().toString();

}

Krok 2: email z linkiem aktywacyjnym

Aplikacja wysyła na adres podany przez użytkownika wiadomość zawierającą link aktywacyjny. Kod wygenerowany losowo w poprzednim kroku jest doklejony do adresu jako parametr URL.

...
@Controller
public class UserController extends WebMvcConfigurerAdapter {
	...
	@RequestMapping(value = "/signup", method = RequestMethod.POST)
	public String checkPersonInfo(@Valid User user, BindingResult bindingResult, Model model) {
		...
		user.setConfirmationId(createConfirmationID());
		emailService.send(user.getEmail(), "Szafbook Account Confirmation Link",
				"http://szafbook.pl/confirm?id=" + user.getConfirmationId());
		userRepository.save(user);
		model.addAttribute("message", "Please, check your mailbox for the email confirmation link. ");
        return "message";
	}
...
}

...

@Controller

public class UserController extends WebMvcConfigurerAdapter {

...

@RequestMapping(value = "/signup", method = RequestMethod.POST)

public String checkPersonInfo(@Valid User user, BindingResult bindingResult, Model model) {

...

user.setConfirmationId(createConfirmationID());

emailService.send(user.getEmail(), "Szafbook Account Confirmation Link",

"http://szafbook.pl/confirm?id=" + user.getConfirmationId());

userRepository.save(user);

model.addAttribute("message", "Please, check your mailbox for the email confirmation link. ");

return "message";

}

...

}

Krok 3: obsługa linku aktywacyjnego

Wejście pod adres podany w mailu powoduje uruchomienie servletu weryfikacyjnego. Aplikacja szuka w bazie danych obiektu użytkownika, któremu przypisano kod podany jako parametr. Jeśli taki użytkownik istnieje, jest oznaczany jako aktywny. Od tej chwili może się już logować, ponieważ potwierdzono (czy raczej zwiększono prawdopodobieństwo), że to rzeczywista osoba.

...
@Controller
public class ConfirmationController {
	
    @Autowired 
    private UserRepository userRepository; 

    @RequestMapping("/confirm")
    public String greeting(@RequestParam(value="id", required=true) String confirmationId, Model model) {      
    	
    	User user = userRepository.getUserByConfirmationId(confirmationId);
    	String message = "Invalid confirmation id. Contact us or try again.";
    	if(user!=null){
    		if(!user.isConfirmationStatus()){
    			user.setConfirmationStatus(true);
    			user.setConfirmationId(null);
    			userRepository.save(user);
    		}
    		message = user.getUserName() + ", your account has been verified. You may now log in. ";
    	}             
        
        model.addAttribute("message", message);
        return "message";
    }

}

...

@Controller

public class ConfirmationController {

@Autowired

private UserRepository userRepository;

@RequestMapping("/confirm")

public String greeting(@RequestParam(value="id", required=true) String confirmationId, Model model) {

User user = userRepository.getUserByConfirmationId(confirmationId);

String message = "Invalid confirmation id. Contact us or try again.";

if(user!=null){

if(!user.isConfirmationStatus()){

user.setConfirmationStatus(true);

user.setConfirmationId(null);

userRepository.save(user);

}

message = user.getUserName() + ", your account has been verified. You may now log in. ";

}

model.addAttribute("message", message);

return "message";

}

Krok 4: usunięcie nieaktywnych kont

Należałoby usunąć zbyt długo przechowywane nieaktywne konta. Ale jeszcze się za to nie zabrałam 🙂

Ciekawostka: wyszukanie użytkownika w bazie

Oto ilość pracy, którą włożyłam w wyszukanie użytkownika w bazie danych MongoDB po wartości confirmationId:

...
public interface UserRepository extends CrudRepository<User, BigInteger>{
		
	public User getUserByConfirmationId(String confirmationId);
	
}

...

public interface UserRepository extends CrudRepository<User, BigInteger>{

public User getUserByConfirmationId(String confirmationId);

}

Resztę robi za mnie Spring Data, parsując nazwę metody!

Więcej informacji na ten temat można znaleźć tutaj.

PS.

To ostatni techniczny wpis w ramach konkursu Daj się poznać 2016. Jutro postaram się napisać krótkie podsumowanie. O ile wieczorem na spotkaniu młodych mam nie poleje się za dużo wina.

Średnio zaawansowane

Jak wysłać maila z aplikacji webowej w Javie?

2016-05-24 ynka 1 komentarz

Po co mi maile?

Warunkiem utworzenia konta użytkownika jest podanie poprawnego adresu email, do którego dany użytkownik rzeczywiście ma dostęp.

W kolejnym wpisie omówię dokładniej proces weryfikacji. Na teraz istotne jest to, że moja aplikacja musi być w stanie wysłać do użytkownika maila z linkiem do uaktywnienia konta.

Jak to zrobić?

Korzystam z frameworka Spring Boot (czyli właściwie z nakładki ułatwiającej korzystanie z frameworka Spring zgodnie z zasadą “konwencja ponad konfiguracją”).

Kroki do realizacji mojego celu są następujące:

1. Dodaję zależność w pliku pom.xml:

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-mail</artifactId>
</dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-mail</artifactId>

</dependency>

2. Piszę kod tworzący i wysyłający wiadomości:

...
import javax.mail.MessagingException;
import javax.mail.internet.MimeMessage;
import org.springframework.mail.javamail.JavaMailSender;
import org.springframework.mail.javamail.MimeMessageHelper;

@Service
public class EmailService {

	@Autowired
	private JavaMailSender javaMailSender;

	public void send(String to, String title, String contents) {

		MimeMessage mail = javaMailSender.createMimeMessage();

		try {
			MimeMessageHelper helper = new MimeMessageHelper(mail, true);
			helper.setTo(to);
			helper.setReplyTo("auto@szafbook.pl");
			helper.setFrom("auto@szafbook.pl");
			helper.setSubject(title);
			helper.setText(contents);
		} catch (MessagingException e) {
			e.printStackTrace();
		} finally {
		}
		javaMailSender.send(mail);
	}
}

...

import javax.mail.MessagingException;

import javax.mail.internet.MimeMessage;

import org.springframework.mail.javamail.JavaMailSender;

import org.springframework.mail.javamail.MimeMessageHelper;

@Service

public class EmailService {

@Autowired

private JavaMailSender javaMailSender;

public void send(String to, String title, String contents) {

MimeMessage mail = javaMailSender.createMimeMessage();

try {

MimeMessageHelper helper = new MimeMessageHelper(mail, true);

helper.setTo(to);

helper.setReplyTo("auto@szafbook.pl");

helper.setFrom("auto@szafbook.pl");

helper.setSubject(title);

helper.setText(contents);

} catch (MessagingException e) {

e.printStackTrace();

} finally {

}

javaMailSender.send(mail);

}

3. Ustawiam właściwości aplikacji

...
spring.mail.host=serwer.smtp
spring.mail.port=nr.portu
spring.mail.username=username
spring.mail.password=password
spring.mail.properties.mail.smtp.starttls.enable=true
spring.mail.properties.mail.smtp.starttls.required=true
spring.mail.properties.mail.smtp.auth=true;

...

spring.mail.host=serwer.smtp

spring.mail.port=nr.portu

spring.mail.username=username

spring.mail.password=password

spring.mail.properties.mail.smtp.starttls.enable=true

spring.mail.properties.mail.smtp.starttls.required=true

spring.mail.properties.mail.smtp.auth=true;

Co może pójść nie tak?

com.sun.mail.smtp.SMTPSendFailedException: 530 5.7.0 Must issue a STARTTLS command first.

Koniecznie jest nadanie wartości true właściwości spring.mail.properties.mail.smtp.starttls.enable, a najlepiej całej trójce kończącej powyższy listing.

javax.mail.AuthenticationFailedException: 534-5.7.9 Application-specific password required.

To akurat sprawa typowa dla serwisu GMail. Jeśli chcesz, żeby aplikacja łączyła się z kontem email i w Twoim imieniu wysyłała maile, musisz stworzyć specjalne hasło aplikacji, różne od hasła prywatnego. W każdej chwili możesz podejrzeć listę aplikacji, które korzystają z takiego hasła (na stronie https://security.google.com/settings/security/apppasswords), a także dowolną z nich zablokować.

Google uprzejmie zwraca uwagę, że nadal nie jest to najbezpieczniejsze rozwiązanie.

com.sun.mail.util.MailConnectException: Couldn’t connect to host.

Ten błąd pojawił się, kiedy przełączyłam konto z GMaila na adres email na mojej wirtualnej instancji obsługującej kilka domen. Początkowo myślałam, że Java Mail nie chce pracować z “wirtualnymi” adresami obsługiwanymi przez serwer SMTP w innej domenie. Ostatecznie okazało się jednak, że przyczyną błędu był nadmiarowy biały znak w pliku application.properties 🙂

Ciekawostka: tymczasowe maile

Wiele aplikacji wymusza na użytkowniku podanie działającego adresu email. Główne powody to:

zwiększenie prawdopodobieństwa, że mamy do czynienia z człowiekiem, a nie robotem,
umożliwienie spamowania 🙂
zabezpieczenie użytkownika przed literówką w adresie email, która mogłaby doprowadzić nawet do utraty konta w aplikacji (brak możliwości zresetowania hasła bez działającego adresu).

Wiele osób tworzy sobie dodatkowe konto email, które używane jest do rejestracji w mniej istotnych serwisach (sama mam osobne konto do zakupów internetowych). Zdarza się jednak, że adresu email żąda strona lub aplikacja, z którą na pewno już nigdy nie będziesz mieć nic wspólnego. Co wtedy zrobić?

Możesz założyć tzw. jednorazowe (ang. disposable) konto email, np. w serwisie Guerilla Mail. Poczta, która tam trafia, jest przechowywana przez godzinę niezależnie od tego, czy ktoś ja odczyta, czy nie.

Ocenę moralną pozostawiam Czytelnikowi.

Tajemne szyfry (zaawansowane)

Zapisuję dane użytkowników w bazie i robię głupie błędy podczas walidacji formularza

2016-05-20 ynka 3 komentarze

Zapis danych użytkowników w MongoDB

O MongoDB pisałam już w dwóch wcześniejszych postach: Jak zacząć z MongoDB? i MongoDB + Spring Data.

Dzisiaj postanowiłam zaimplementować wreszcie zapis danych z formularza użytkownika w mojej nierelacyjnej (dokumentowej) bazie danych.

W poprzednim tekście pokazałam, jakich adnotacji należy użyć w klasie User, żeby jej instancje zostały poprawnie zapisane w bazie danych. Żeby faktycznie zapisać dane z formularza, musiałam tylko dopisać kilka linii w kodzie kontrolera:

...
@Autowired
	private UserRepository userRepository;
...

	@RequestMapping(value = "/signup", method = RequestMethod.POST)
	public String checkPersonInfo(@Valid User user, BindingResult bindingResult, Model model) {	

		if (bindingResult.hasErrors() || !processPasswords(user, bindingResult)) {
			return "userform";
		}
		
		model.addAttribute("currentUser", user);
		userRepository.save(user);
		return "userpage";
	}

...

@Autowired

private UserRepository userRepository;

...

@RequestMapping(value = "/signup", method = RequestMethod.POST)

public String checkPersonInfo(@Valid User user, BindingResult bindingResult, Model model) {

if (bindingResult.hasErrors() || !processPasswords(user, bindingResult)) {

return "userform";

}

model.addAttribute("currentUser", user);

userRepository.save(user);

return "userpage";

}

Co zrobić z hasłami?

Zależało mi na spełnieniu trzech warunków:

Użytkownik podaje hasło dwa razy, żeby zmniejszyć ryzyko literówki.
Wpisywane hasło jest niewidoczne.
Hasło w bazie danych nie jest przechowywane w postaci jawnej.

Dwa hasła

Dodałam następujące pola do klasy reprezentującej użytkownika:

@Document
public class User {

	...

	@Transient
	@NotNull
    @Size(min=5,max=30)
	private String password1;
	
	@Transient
	@NotNull
    @Size(min=5,max=30)	
	private String password2;

	...	

}

@Document

public class User {

...

@Transient

@NotNull

@Size(min=5,max=30)

private String password1;

@Transient

@NotNull

@Size(min=5,max=30)

private String password2;

...

}

Specjalnie zaznaczyłam adnotację @Transient. Dzięki jej użyciu wskazane pola (w tym wypadku hasła zapisane jawnym tekstem) nie zostaną zapisane w bazie danych.

Ukrycie literek

Pola musiałam również dopisać do formularza. Użyłam pola input w wersji password, żeby zamiast liter wyświetlić gwiazdki (czy tam kropki).

<tr>
	<td>Password:*</td>
	<td><input type="password" th:field="*{password1}" /></td>
	<td th:if="${#fields.hasErrors('password1')}" th:errors="*{password1}">Password error</td>
</tr>
<tr>
	<td>Repeat Password:*</td>
	<td><input type="password" th:field="*{password2}" /></td>
	<td th:if="${#fields.hasErrors('password2')}" th:errors="*{password2}">Password error</td>
</tr>

<tr>

<td>Password:*</td>

<td th:if="${#fields.hasErrors('password1')}" th:errors="*{password1}">Password error</td>

</tr>

<tr>

<td>Repeat Password:*</td>

<td th:if="${#fields.hasErrors('password2')}" th:errors="*{password2}">Password error</td>

</tr>

Funkcja hashująca

Wreszcie, hasła. Nie powinny być przechowywane w bazie danych w postaci jawnej. Powodów jest wiele. Na przykład taki: ludzie często używają tych samych haseł w wielu miejscach. Gdyby administrator bazy danych miał wgląd w hasła do aplikacji, mógłby podjąć próbę zalogowania się na konta użytkowników w innych serwisach (np. gmail) przy użyciu tego samego hasła i adresu email.

Oprócz pokazanych już dwóch pól do wprowadzenia hasła roboczego, klasa User przechowuje jeszcze następujące dwie wartości:

@Document
public class User {

	...
	
	private String passwordEncrypted;
	private String passwordSalt;	

	...	

}

@Document

public class User {

...

private String passwordEncrypted;

private String passwordSalt;

...

}

passwordSalt to losowa wartość doklejana do hasła przed jego “zaszyfrowaniem” (dzięki niej w bazie danych nie będzie widać, że dwa użytkownicy przypadkowo użyli tego samego hasła), passwordEncrypted to wynik szyfrowania.

Losowanie i szyfrowanie realizuje następujący pomocniczy serwis, wywoływany z kontrolera dzięki adnotacji @Autowired:

@Service
public class PasswordsHelper {
	
	private SecureRandom generator;	
	private String encryptionAlgorithm = "PBEWithMD5AndDES";
	
	public PasswordsHelper() throws NoSuchAlgorithmException{
		generator = new SecureRandom();
	}
	
	public String getNextPasswordSeed(){
		return String.valueOf(generator.nextInt());
	}	
	
	public String encrypt(String password){
		SecretKey secretKey = new SecretKeySpec(password.getBytes(), encryptionAlgorithm);
		return secretKey.getEncoded().toString();
	}
	
	...
}

@Service

public class PasswordsHelper {

private SecureRandom generator;

private String encryptionAlgorithm = "PBEWithMD5AndDES";

public PasswordsHelper() throws NoSuchAlgorithmException{

generator = new SecureRandom();

}

public String getNextPasswordSeed(){

return String.valueOf(generator.nextInt());

}

public String encrypt(String password){

SecretKey secretKey = new SecretKeySpec(password.getBytes(), encryptionAlgorithm);

return secretKey.getEncoded().toString();

}

...

}

Kontroler wygląda tak:

...
@Controller
public class UserController extends WebMvcConfigurerAdapter {

	...

	@Autowired
	private PasswordsHelper passwordsHelper;			    

	@RequestMapping(value = "/signup", method = RequestMethod.POST)
	public String checkPersonInfo(@Valid User user, BindingResult bindingResult, Model model) {	

		if (bindingResult.hasErrors() || !processPasswords(user, bindingResult)) {
			return "userform";
		}
		
		...		
		return "userpage";
	}

	private boolean processPasswords(User user, BindingResult bindingResult) {
		if (!user.getPassword1().equals(user.getPassword2())) {
			bindingResult.rejectValue("password1", "Passwords don't match", "Passwords don't match");
			bindingResult.rejectValue("password2", "Passwords don't match", "Passwords don't match");
			return false;
		}
		user.setPasswordSalt(passwordsHelper.getNextPasswordSeed());
		user.setPasswordEncrypted(passwordsHelper.encrypt(user.getPasswordSalt() + user.getPassword1()));
		return true;
	}
}

...

@Controller

public class UserController extends WebMvcConfigurerAdapter {

...

@Autowired

private PasswordsHelper passwordsHelper;

@RequestMapping(value = "/signup", method = RequestMethod.POST)

public String checkPersonInfo(@Valid User user, BindingResult bindingResult, Model model) {

if (bindingResult.hasErrors() || !processPasswords(user, bindingResult)) {

return "userform";

}

...

return "userpage";

}

private boolean processPasswords(User user, BindingResult bindingResult) {

if (!user.getPassword1().equals(user.getPassword2())) {

bindingResult.rejectValue("password1", "Passwords don't match", "Passwords don't match");

bindingResult.rejectValue("password2", "Passwords don't match", "Passwords don't match");

return false;

}

user.setPasswordSalt(passwordsHelper.getNextPasswordSeed());

user.setPasswordEncrypted(passwordsHelper.encrypt(user.getPasswordSalt() + user.getPassword1()));

return true;

}

Błąd 1: strona błędu zamiast komunikatu o błędzie w formularzu

Podanie niepoprawnych danych w formularzu z nieznanego mi powodu zaczęło przenosić mnie na moją własną stronę błędu (zamiast wyświetlenia komunikatu przy polu formularza, które spowodowało problem).

Co się okazało?

W pewnym momencie zmieniłam sygnaturę metody kontrolera z:

public String checkPersonInfo(@Valid User user, BindingResult bindingResult) {

1	public String checkPersonInfo(@Valid User user, BindingResult bindingResult) {

na:

public String checkPersonInfo(@Valid User user, Model model, BindingResult bindingResult) {

1	public String checkPersonInfo(@Valid User user, Model model, BindingResult bindingResult) {

ponieważ chciałam dopisać informacje do modelu.

Okazuje się, że parametr reprezentujący BindingResult musi następować bezpośrednio po parametrze, przez który przekazywany jest dotyczący go obiekt (co ma sens, gdy jeden formularz obsługuje wiele obiektów).

Formularz zaczął działać poprawnie po zamianie kolejności parametrów:

public String checkPersonInfo(@Valid User user, BindingResult bindingResult, Model model) {

1	public String checkPersonInfo(@Valid User user, BindingResult bindingResult, Model model) {

Błąd 2: Error during execution of processor ‘org.thymeleaf.spring4.processor.attr.SpringErrorsAttrProcessor’

Kolejny błąd zaskoczył mnie, kiedy testowałam sytuację, w której użytkownik wpisze dwa różne hasła. Okazało się, że poczyniłam złe założenia na temat parametrów metody rejectValue, za pomocą której chciałam przekazać do formularza informację o wykryciu problemu. Napisałam:

bindingResult.rejectValue("password1", "Passwords don't match");

1	bindingResult.rejectValue("password1", "Passwords don't match");

zakładając, że drugi parametr to komunikat o błędzie. Tymczasem – to kod błędu. Komunikat można przekazać dopiero w trzecim parametrze (poprawny kod widać na listingu z metodą processPasswords). Błąd wynikał zatem z braku komunikatu o błędzie, który był wymagany w szablonie.

Wreszcie działa

Kod jest dostępny w moim repozytorium GitHub.

Komunikat o niepasujących do siebie hasłach

Wyświetlenie informacji o pierwszym lepszym użytkowniku z bazy

Tajemne szyfry (zaawansowane)

Jak zabezpieczyć strony generowane przez Spring Boot Actuator?

2016-05-13 ynka 1 komentarz

W mojej aplikacji webowej korzystam z biblioteki Actuator, która daje dostęp do masy pożytecznych informacji na temat działania aplikacji (w czasie rzeczywistym).

Wystarczy dodać w pom.xml następujący wpis:

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

Po uruchomieniu aplikacji uzyskuję dostęp do wielu stron ze szczegółami działania aplikacji. Przykładowo, pod adresem /health znajdę podstawowe informacje o aktualnym statusie aplikacji:

Raport na temat stanu zdrowia aplikacji — Raport na temat stanu zdrowia 🙂

Wszystko pięknie, tyle tylko, że nie chcę dzielić się takimi danymi z przypadkowymi (lub, co gorsza, nieprzypadkowymi) użytkownikami Internetu.

Pokazywałam już (we wpisie Spring Boot: Bezpieczeństwo 101) jak oznaczyć strony, które mają być wyświetlane tylko użytkownikom o statusie administratora. Problem z Actuatorem polega na tym, że generowane przez tę bibliotekę adresy nie mają wspólnego rdzenia. Mamy np.: /env, /metrics, /trace. Ich wymienianie jest nieco upierdliwe!

Wtem! Wyczytałam (w Spring Boot in Action), że można dodać tym stronom wspólny przedrostek za pomocą wpisu w pliku application.properties:

management.context-path=/actuator

1	management.context-path=/actuator

A następnie zabezpieczyć dostęp do stron na tej ścieżce:

...

@Configuration
@EnableGlobalMethodSecurity(securedEnabled = true)
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
	
	...
	
	@Override
	protected void configure(HttpSecurity http) throws Exception {
		http
		.authorizeRequests()
			.antMatchers("/", "/signup", "/about", "/assets/**","/login").permitAll()
			.antMatchers("/admin/**").hasRole("ADMIN")
			.antMatchers("/actuator/**").hasRole("ADMIN")
			.anyRequest().authenticated()
			.and()
			...
	}
	
}

...

@Configuration

@EnableGlobalMethodSecurity(securedEnabled = true)

public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

...

@Override

protected void configure(HttpSecurity http) throws Exception {

http

.authorizeRequests()

.antMatchers("/", "/signup", "/about", "/assets/**","/login").permitAll()

.antMatchers("/admin/**").hasRole("ADMIN")

.antMatchers("/actuator/**").hasRole("ADMIN")

.anyRequest().authenticated()

.and()

...

}

I voilà! Po zalogowaniu się jako administrator widzę:

Raport o stanie zdrowia wyświetlam teraz pod innym, wspólnym adresem

Tajemne szyfry (zaawansowane)

MongoDB + Spring Data

2016-05-12 ynka Dodaj komentarz

W poprzednim wpisie pokazałam, jak dodawać dokumenty i kolekcje do nierelacyjnej bazy MongoDB oraz jak połączyć się z tą bazą z kodu javowego.

W tym odcinku pokażę, jak łatwo utrwalić w MongoDB obiekty przetwarzane w aplikacji webowej.

Wpis w pom.xml

Kolejny raz korzystam ze “startera” Spring Boot, który grupuje w sobie kilka podstawowych bibliotek realizujących spójny cel – w tym wypadku mapowanie, zapis i odczyt danych z MongoDB:

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-data-mongodb</artifactId>

</dependency

Adnotacje w obiekcie, który ma zostać utrwalony w bazie danych

Do obiektu reprezentującego użytkownika bazy danych dodałam następujące adnotacje:

...

import org.springframework.data.annotation.Id;
import org.springframework.data.mongodb.core.mapping.DBRef;
import org.springframework.data.mongodb.core.mapping.Document;

@Document
public class User {

	@Id
	private BigInteger id;

	private String displayedName;
	private String description;

	private Calendar birthday;
	private URI profilePic;

	...
	
	@DBRef
	private List<Size> sizes;
	
	...
}

...

import org.springframework.data.annotation.Id;

import org.springframework.data.mongodb.core.mapping.DBRef;

import org.springframework.data.mongodb.core.mapping.Document;

@Document

public class User {

@Id

private BigInteger id;

private String displayedName;

private String description;

private Calendar birthday;

private URI profilePic;

...

@DBRef

private List<Size> sizes;

...

}

@Document oznacza, że mamy do czynienia z obiektem zapisywanym w bazie danych. Jest to odpowiednik @Entity w wersji Spring Data dla relacyjnych baz danych.
@Id to automatycznie generowany, obowiązkowy identyfikator dokumentu w ramach kolekcji w MongoDB.
Pola nieopisane zostaną bezpośrednio odwzorowane w dokumencie w bazie danych.
@DBRef oznacza odwołanie do innej kolekcji w bazie. Uwaga! Nie wolno tworzyć odwołań obustronnych, MongoDB brzydko się przez nie zapętli. Zamiast tego należy po jednej stronie jawnie zapisać identyfikator dokumentu.

Interfejs do obsługi repozytorium

Muszę tylko zasygnalizować, że będę chciała pobierać z bazy obiekty danego typu:

package pl.namiekko.controllers;

import java.math.BigInteger;
import org.springframework.data.repository.CrudRepository;
import pl.namiekko.entities.User;

public interface UserRepository extends CrudRepository<User, BigInteger>{

}

package pl.namiekko.controllers;

import java.math.BigInteger;

import org.springframework.data.repository.CrudRepository;

import pl.namiekko.entities.User;

public interface UserRepository extends CrudRepository<User, BigInteger>{

}

Użycie w kodzie: kontroler i widok

Kontroler

W celu przetestowania konfiguracji dodałam odwołanie do kolekcji użytkowników do mojego powitalnego kontrolera GreetingController:

@Controller
public class GreetingController {
	
    @Autowired 
    private UserRepository userRepository; 

    @RequestMapping("/")
    public String greeting(@RequestParam(value="name", required=false, defaultValue="World") String name, Model model) {
        model.addAttribute("name", name);
        for(User user: userRepository.findAll()){
        	model.addAttribute("retrievedName", user.getUserName());
        	break;
        }                
        return "index";
    }

}

@Controller

public class GreetingController {

@Autowired

private UserRepository userRepository;

@RequestMapping("/")

public String greeting(@RequestParam(value="name", required=false, defaultValue="World") String name, Model model) {

model.addAttribute("name", name);

for(User user: userRepository.findAll()){

model.addAttribute("retrievedName", user.getUserName());

break;

}

return "index";

}

Nazwa pierwszego napotkanego użytkownika zostanie dodana do modelu.

Widok

W powitalnym szablonie Thymeleaf dopisałam kod, który wyświetli nazwę odnalezionego w bazie danych użytkownika, o ile taki użytkownik istnieje:

...
<p th:if="${retrievedName != null}" th:text="'Our database user is, ' + ${retrievedName} + '!'" />
...

...

...

Efekt

Wyświetlenie informacji pobranej z bazy danych. Przecinek od czapy.

Zapis informacji w bazie

Mogę skorzystać ze sposobu pokazanego w poprzednim wpisie. Mogę też przygotować kod, który będzie wywoływany przy każdym uruchomieniu aplikacji:

@Service
public class DatabaseLoader {
	...	

	@PostConstruct
	private void initDatabase() {
		userRepository.deleteAll();

		User user = new User();
		user.setEmail("user@example.com");
		user.setDisplayedName("First User <3");
		user.setUserName("first1");
		userRepository.save(user);
	}
}

@Service

public class DatabaseLoader {

...

@PostConstruct

private void initDatabase() {

userRepository.deleteAll();

User user = new User();

user.setEmail("user@example.com");

user.setDisplayedName("First User <3");

user.setUserName("first1");

userRepository.save(user);

}

Konfiguracja połączenia z bazą danych

Tym razem oparłam się na wartościach domyślnych. Nie wpisałam w application.properties żadnych danych na temat połączenia z bazą danych. Oczywiście musiałam uruchomić mój serwer MongoDB.

Wszystko zadziałało.

Mogę podejrzeć zastosowane wartości właściwości związanych z MongoDB dzięki dołączonej w pom.xml bibliotece Spring Boot Actuator. Pod adresem http://localhost:8080/configprops widzę m.in. takie dane:

   "spring.data.mongodb.CONFIGURATION_PROPERTIES":{
      "prefix":"spring.data.mongodb",
      "properties":{
         "database":null,
         "password":null,
         "fieldNamingStrategy":null,
         "gridFsDatabase":null,
         "port":null,
         "host":null,
         "uri":"mongodb://localhost/test",
         "authenticationDatabase":null,
         "username":null
      }
   }

"spring.data.mongodb.CONFIGURATION_PROPERTIES":{

"prefix":"spring.data.mongodb",

"properties":{

"database":null,

"password":null,

"fieldNamingStrategy":null,

"gridFsDatabase":null,

"port":null,

"host":null,

"uri":"mongodb://localhost/test",

"authenticationDatabase":null,

"username":null

}

Test to baza danych, którą utworzyłam na potrzeby poprzedniego wpisu.

Troubleshooting: co zrobiłam nie tak przy pierwszym podejściu?

Zapomniałam o wpisaniu @Autowired w kontrolerze w punkcie 4 (komunikat CrudRepository ... is no accessor method!)
Nie włączyłam MongoDB (Timed out after 10000 ms while waiting for a server that matches AnyServerSelector{} ... caused by {java.net.ConnectException: Connection refused: connect}})

final

Klasa final

Metoda final

Zmienna final

Pole klasy final

Parametr final

static

Pole klasy static

Metoda static

Blok kodu static

Zagnieżdżona klasa static

Obiekty niemodyfikowalne

Wszystko razem, czyli static final String

Psikus 1: znaki ucieczki w wyrażeniach wczytywanych z zewnętrznego pliku

Psikus 2: flagi

Psikus 3: String.replaceAll

Cel

Realizacja celu

Napotkane problemy

Kod

PS.

Przykład (Java 8)

Przykład (Java 7 i starsze)

Porównanie

Czy naprawdę nie było innego wolnego słowa?

Co się dzieje w tle?

Wniosek

PS. Sklejanie Stringów

Krok 1: nieaktywny użytkownik z wygenerowanym kodem

Krok 2: email z linkiem aktywacyjnym

Krok 3: obsługa linku aktywacyjnego

Krok 4: usunięcie nieaktywnych kont

Ciekawostka: wyszukanie użytkownika w bazie

PS.

Po co mi maile?

Jak to zrobić?

1. Dodaję zależność w pliku pom.xml:

2. Piszę kod tworzący i wysyłający wiadomości:

3. Ustawiam właściwości aplikacji

Co może pójść nie tak?

com.sun.mail.smtp.SMTPSendFailedException: 530 5.7.0 Must issue a STARTTLS command first.

javax.mail.AuthenticationFailedException: 534-5.7.9 Application-specific password required.

com.sun.mail.util.MailConnectException: Couldn’t connect to host.

Ciekawostka: tymczasowe maile

Zapis danych użytkowników w MongoDB

Co zrobić z hasłami?

Dwa hasła

Ukrycie literek

Funkcja hashująca

Błąd 1: strona błędu zamiast komunikatu o błędzie w formularzu

Błąd 2: Error during execution of processor ‘org.thymeleaf.spring4.processor.attr.SpringErrorsAttrProcessor’

Wreszcie działa

Wpis w pom.xml

Adnotacje w obiekcie, który ma zostać utrwalony w bazie danych

Interfejs do obsługi repozytorium

Użycie w kodzie: kontroler i widok

Kontroler

Widok

Efekt

Zapis informacji w bazie

Konfiguracja połączenia z bazą danych

Troubleshooting: co zrobiłam nie tak przy pierwszym podejściu?

Milsza strona programowania