Tag:

java

Spring multi-tenant – strategia same table

by Grzegorz Sowa 13 marca, 2022

written by Grzegorz Sowa

Większość aplikacji SaaS działa w architekturze multi-tenant, gdzie na tych samych maszynach koegzystują różne firmy-klienci. Takie rozwiązanie ma wiele zalet, jednak stawia przed inżynierami szereg wyzwań. Zobaczmy, jakie to wyzwania i jak zastosować sprawdzone wzorce, żeby im sprostać. Na koniec stworzymy aplikację Spring multi-tenant z użyciem strategii same table.

Cały kod zawarty w tym artykule znajdziecie tutaj.

Czemu multi-tenant?

Architektura single-tenant zakłada uruchamianie aplikacji na oddzielnym środowisku per klient, gdzie zasoby i dane są oddzielnie przygotowywane dla każdego klienta. Oprócz kilku zalet, jak większe bezpieczeństwo danych i możliwość dostosowania środowiska do klienta, to rozwiązanie ma też szereg wad:

skomplikowany proces stawiania nowych środowisk,
wysokie koszta i niepełne wysycenie zasobów.

spring single-tenant vs multi-tenant same table

Aby zniwelować te niekorzystne czynniki, w środowiskach chmurowych zaczęto korzystać z architektury multi-tenant, gdzie jedna infrastruktura jest dzielona pomiędzy kilku klientów-tenantów. Budowa takich systemów wprowadziła jednak szereg wyzwań, głównie związanych z bezpieczeństwem danych i stabilnością:

noisy neighbour problem, czyli gdy jeden tenant chwilowo zabiera tyle zasobów, że pozostali mają za mało,
separacja danych, czyli jak zminimalizować ryzyko, że jeden tenant dostanie się do danych drugiego,
trudne obliczanie kosztu per tenant.

Problemy te jednak da się zaadresować i prawdziwe systemy SaaS prędzej czy później stają się systemami hybrydowymi, stosując minimalną separację dla większości klientów i bardziej zaawansowane rozwiązania dla dużych firm o wysokich wymaganiach.

Skoro wiemy już, z jakimi problemami mamy do czynienia, zobaczmy, jakie są strategie separacji danych w systemach multi-tenant.

Strategie separacji danych

Jest kilka głównych strategii separacji danych:

same table (discriminator column),
same schema, separate tables,
same database, separate schemas,
separate database.

Oprócz tego jest kilka innych technik, dzięki którym najbardziej wymagającym klientom możemy zapewnić szczególne bezpieczeństwo danych, jak np. Bring Your Own Key Encryption.

Prawie wszystkie główne strategie są implementowane przez Hibernate – w wersji 5.6 wszystkie oprócz same table (ciągle jednak trwają pracę nad dodaniem tego feature- polecam śledzić to zgłoszenie.

W tym artykule zobaczymy, jak możemy bez natywnego wsparcia Hibernate stworzyć aplikację Spring multi-tenant z użyciem strategii same table.

Implementacja same table

Kod implementacji znajdziecie na branchu discriminator-column.

W przypadku strategii same table separujemy dane na podstawie tzw. discriminator column, czyli kolumny zawierającej informację o przynależności danego rekordu do tenanta. Wydaje się oczywiste, że kolumna ta będzie dodana w każdej tabeli zawierającej dane encji, dodatkowo musimy przechować discriminator column w danych użytkownika.

Model

Załóżmy, że mamy aplikację, w której różni użytkownicy (User) mogą organizować sobie pracę i tworzą zadania (Task). Do zadań powinni mieć dostęp inni użytkownicy w ramach tej samej firmy, która jest u nas podmiotem subskrybującym usługę (Tenant). Zatem zadanie będzie w dużym uproszczeniu wyglądać tak:

public class Task {

    private String title;

    public static Task newInstance(String title) {
        final Task task = new Task();
        task.title = title;
        return task;
    }
}

Problem

Użytkownicy danego przedsiębiorstwa mogą być tworzeni przez administratora przypisanego do tej samej firmy. Administrator powinien mieć też prawo wyświetlenia listy użytkowników, ale tylko firmy, do której należy.

Musimy więc zapewnić w naszej aplikacji separację danych należących do różnych tenantów, a także wydzielić uprawnienia administratorów.

Aby rozwiązać powyższe problemy w naszej aplikacji Spring multi-tenant użyjemy strategii same table.

Tenants

Naszą implementację zacznijmy od zdefiniowania encji przechowującej dane naszych tenantów:

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PRIVATE)
class Tenant implements Persistable<TenantId> {

    @Id
    @Embedded
    private TenantId id;
    @Transient
    private boolean isNew;
    private String name;

    public static Tenant newInstance(String name) {
        final Tenant tenant = of(TenantId.random(), name);
        tenant.isNew = true;
        return tenant;
    }

    static Tenant of(TenantId id, String name) {
        final Tenant tenant = new Tenant();
        tenant.id = id;
        tenant.name = name;
        return tenant;
    }

    TenantData toData() {
        final TenantData data = new TenantData();
        data.setId(id.toString());
        data.setName(name);
        return data;
    }
}

Serwis, który będzie odpowiadał za tworzenie nowych tenantów:

@Service
public class TenantService {

    private final UserService userService;
    private final TenantRepository tenantRepository;

    public TenantService(UserService userService,
                         TenantRepository tenantRepository
    ) {
        this.userService = userService;
        this.tenantRepository = tenantRepository;
    }

    public TenantData createTenant(CreateTenantDto dto) {
        final Tenant tenant = tenantRepository.save(Tenant.newInstance(dto.getName()));
        try {
            TenantContext.override(tenant.getId());
            userService.createAdmin(dto.getAdmin());
        } finally {
            TenantContext.reset();
        }
        return tenant.toData();
    }
}

W mamy tu zależność do UserService, ponieważ w momencie tworzenia nowego tenanta zakładamy mu też konto użytkownika-administratora.

Zdefiniujmy teraz interfejs, który będzie definiował obiekty należące do jakiegoś tenanta:

public interface TenantAdherent {

    TenantId getTenantId();
}

Dla kolejnych encji, które będziemy definiować, stwórzmy encję bazową, implementującą ten interfejs:

@MappedSuperclass
@Getter
@Setter(AccessLevel.PACKAGE)
@NoArgsConstructor
public abstract class TenantAdherentEntity implements TenantAdherent, Persistable<UUID> {

    @Id
    private UUID id;
    @Transient
    private boolean isNew;
    @Embedded
    private TenantId tenantId;
}

Jeśli zastanawiasz się, skąd właściwie wzięło się isNew lub interfejs Persistable<>, koniecznie zajrzyj do tego artykułu.

Wrapper, którego użyliśmy, czyli TenantId, zawiera implementację id tenanta. Dzięki adnotacji @Embedded Hibernate potraktuje obiekt jako transparentny i zapisze do tabeli tylko jego wewnętrzne pola.

@NoArgsConstructor(access = AccessLevel.PRIVATE)
@EqualsAndHashCode
@Embeddable
public class TenantId implements Serializable {

    private UUID value;

    public static TenantId any() {
        return new TenantId();
    }

    public static TenantId of(String value) {
        assert value != null;
        TenantId tenantId = new TenantId();
        tenantId.value = UUID.fromString(value);
        return tenantId;
    }

    public static TenantId random() {
        TenantId tenantId = new TenantId();
        tenantId.value = UUID.randomUUID();
        return tenantId;
    }

    @Override
    public String toString() {
        return Optional.of(value)
                .map(UUID::toString)
                .orElse("");
    }
}

Mamy tu też metodę statyczną any() – pozwoli to nam w przyszłości określić, że działamy w kontekście każdego tenanta – np. gdy wyszukujemy użytkowników po username w trakcie logowania. Mając to wszystko, możemy zdefiniować logikę wyciągania id tenanta z kontekstu zalogowanego użytkownika:

public class TenantContext {

    private static final ThreadLocal<TenantId> tenantId = new ThreadLocal<>();

    static TenantId getTenantId() {
        if (TenantContext.tenantId.get() != null) {
            return TenantContext.tenantId.get();
        }
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        if (authentication != null) {
            return ((TenantAdherent) authentication.getPrincipal()).getTenantId();
        } else {
            return TenantId.any();
        }
    }

    public static void override(TenantId tenantId) {
        TenantContext.tenantId.set(tenantId);
    }

    public static void reset() {
        TenantContext.tenantId.remove();
    }
}

TenantContext pozwala na wyciągnięcie id tenanta z SecurityContextHolder, przechowującego dane użytkownika. W przypadku niezalogowanego użytkownika zwracamy any(), aby móc wyszukiwać użytkownika wśród wszystkich tenantów, gdy przychodzi login request. Możemy również nadpisać id tenanta gdy wykonujemy operacje w kontekście tenanta ale bez zalogowanego użytkownika, np. gdy obsługujemy eventy z kolejki.

Users

Standardowa implementacja użytkownika, jaką mamy w Spring Security, nie uwzględnia istnienia systemów multi-tenant, będziemy więc musieli trochę przy niej „pogrzebać”. Po pierwsze, użytkownik należy do tenanta, więc musi rozszerzać TenantAdherentEntity. Po drugie, będzie on używany jako źródło informacji dla Spring Security, więc musi implementować interfejs UserDetails:

@Entity
@Table(name = "app_user")
@Getter
@NoArgsConstructor(access = AccessLevel.PRIVATE)
class User extends TenantAdherentEntity implements UserDetails {

    @Column(unique = true)
    private String username;
    private String password;

    @Convert(converter = AuthoritiesToStringConverter.class)
    private Set<Authority> authorities;

    public static User newInstance(String username,
                                   String password,
                                   Set<Authority> authorities) {
        final User user = new User();
        user.username = username;
        user.password = password;
        user.authorities = authorities;
        return user;
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }

    public UserData toData() {
        final UserData data = new UserData();
        data.setId(getId().toString());
        data.setUsername(username);
        return data;
    }

    static Example<User> byUsername(String username) {
        User user = new User();
        user.username = username;
        return Example.of(user);
    }
}

Możemy teraz skonstruować implementację UserDetailsService, którą „podłączymy” potem do flow Spring Security – od tej pory będziemy dysponować naszym nowym userem w kontekście każdego requestu, wyciągając go z SecurityContext.

@Service
public class UserService implements UserDetailsService {

    private final UserRepository userRepository;

    @Override
    public User loadUserByUsername(String username) throws UsernameNotFoundException {
        return userRepository.findOne(User.byUsername(username))
                .orElseThrow(() -> new UsernameNotFoundException("No user with such username!"));
    }

}

Dlaczego używamy tutaj metody findOne(Example<User>), zamiast po prostu zdefiniować query method findByUsername(String)? To jest właśnie jedna z wad tego rozwiązania, mianowicie nie obsługuje ono query methods ani native queries.

Dodajmy jeszcze metody manipulowania użytkownikami:

    public UserData createUser(CreateUserDto dto) {
        return createUserWithAuthorities(dto, Set.of(Authority.USER));
    }

    private UserData createUserWithAuthorities(CreateUserDto dto, Set<Authority> authorities) {
        final User user = User.newInstance(
                dto.getUsername(),
                passwordEncoder.encode(dto.getPassword()),
                authorities);
        return userRepository.save(user).toData();
    }

public class CreateUserDto {
    private String username;
    private String password;
}

@Data
public class UserData {
    private String id;
    private String username;
}

Konfiguracja Spring Security

Teraz możemy już wpiąć nasz nowy serwis we flow Springa:

@Configuration
@RequiredArgsConstructor
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

    private final PasswordEncoder passwordEncoder;
    private final UserService userService;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth
                .userDetailsService(userService)
                .passwordEncoder(passwordEncoder);
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .authorizeRequests()
                .antMatchers("/login").permitAll()
                .antMatchers("/tenants").permitAll()
                .anyRequest().authenticated()
                .and()
                .formLogin()
                .successHandler((req, resp, auth) -> resp.setStatus(OK.value()))
                .failureHandler((req, resp, auth) -> resp.setStatus(UNAUTHORIZED.value()))
                .and()
                .exceptionHandling()
                .authenticationEntryPoint((req, resp, ex) -> resp.setStatus(UNAUTHORIZED.value()))
                .and()
                .logout()
                .and()
                .csrf().disable();
    }
}

PasswordEncoder wyjątkowo zdefiniujemy w osobnej klasie (żeby uniknąć zapętlenia zależności):

@Configuration
public class PasswordHandlingConfiguration {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

}

TenantAwareRepository

Teraz dochodzimy do momentu, gdzie możemy globalnie wymusić podział danych pomiędzy tenantów. Zrobimy to przez customową implementację JpaRepository, która dla klas dziedziczących po TenantAdherentEntity będzie w stanie weryfikować dostęp do danych przed odpytaniem bazy danych.

@Transactional
public class TenantAwareJpaRepository<T extends TenantAdherentEntity>
        implements JpaRepositoryImplementation<T, UUID> {

    private final JpaEntityInformation<T, UUID> metadata;
    private final SimpleJpaRepository<T, UUID> repository;

    public TenantAwareJpaRepository(JpaEntityInformation<T, UUID> entityInformation, EntityManager entityManager) {
        this.repository = new SimpleJpaRepository<>(entityInformation, entityManager);
        this.metadata = entityInformation;
    }

    @Override
    public List<T> findAll() {
        return repository.findAll(example());
    }

    @Override
    public long count() {
        return repository.count(example());
    }

    @Override
    public void delete(T entity) {
        if (entity.getTenantId().equals(TenantContext.getTenantId())) {
            repository.delete(entity);
        }
    }

    @Override
    public <S extends T> S save(S entity) {
        if (entity.getId() == null) {
            entity.setId(UUID.randomUUID());
            entity.setNew(true);
        }
        return repository.save(tenant(entity));
    }

    @Override
    public Optional<T> findById(UUID uuid) {
        return repository.findOne(Example.of(instance(uuid)));
    }

    @Override
    public boolean existsById(UUID uuid) {
        return exists(Example.of(instance(uuid)));
    }

    @Override
    public <S extends T> Optional<S> findOne(Example<S> example) {
        return repository.findOne(tenant(example));
    }

    private Example<T> example() {
        return Example.of(instance());
    }

    private T instance() {
        try {
            Constructor<T> constructor = this.metadata.getJavaType().getDeclaredConstructor();
            constructor.setAccessible(true);
            return tenant(constructor.newInstance());
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    private T instance(UUID id) {
        T instance = instance();
        instance.setId(id);
        return instance;
    }

    private <S extends T> Example<S> tenant(Example<S> example) {
        S entity = example.getProbe();
        return Example.of(tenant(entity));
    }

    private <S extends T> S tenant(S entity) {
        if (entity.getTenantId() == null) {
            entity.setTenantId(TenantContext.getTenantId());
        }
        return entity;
    }
}

Dużo się tutaj dzieje, więc zostawiłem implementację tylko kilku głównych metod, wszystko jednak opiera się na pewnym hacku, dzięki któremu zamiast szukać po id encji, szukamy po Example, zawierającym id encji i tenanta. Niestety, nie wszystkie metody są możliwe do zaimplementowania w ten sposób. Cały kod implementacji znajdziecie w repo.

Bardzo podobne rozwiązanie – tyle, że dla MongoDB – zostało przedstawione w tym genialnym wystąpieniu Josha Cummingsa. Polecam obejrzeć całość.

Teraz pozostało nam tylko upewnić się, że podłączymy naszą implementację tylko pod repozytoria encji dziedziczących po TenantAdherentEntity. Możemy do tego celu nadpisać domyślny JpaRepositoryFactoryBean.

public class TenantAwareFactoryBean<R extends JpaRepository<T, I>, T, I extends Serializable> extends JpaRepositoryFactoryBean<R, T, I> {

    public TenantAwareFactoryBean(Class<? extends R> repositoryInterface) {
        super(repositoryInterface);
    }

    @Override
    protected RepositoryFactorySupport createRepositoryFactory(EntityManager entityManager) {
        return new TenantAwareJpaExecutorFactory(entityManager);
    }

    private static class TenantAwareJpaExecutorFactory<T, I extends Serializable> extends JpaRepositoryFactory {

        public TenantAwareJpaExecutorFactory(EntityManager entityManager) {
            super(entityManager);
        }

        @Override
        protected JpaRepositoryImplementation<?, ?> getTargetRepository(RepositoryInformation information, EntityManager entityManager) {
            if (TenantAdherentEntity.class.isAssignableFrom(information.getDomainType())) {
                return new TenantAwareJpaRepository(super.getEntityInformation(information.getDomainType()), entityManager);
            } else {
                return super.getTargetRepository(information, entityManager);
            }
        }

        @Override
        protected Class getRepositoryBaseClass(RepositoryMetadata metadata) {
            if (TenantAdherentEntity.class.isAssignableFrom(metadata.getDomainType())) {
                return TenantAwareJpaRepository.class;
            } else {
                return SimpleJpaRepository.class;
            }
        }
    }
}

Aby używać przy implementacji każdego repozytorium naszego TenantAwareFactoryBean, musimy podłączyć je w adnotacji @EnableJpaRepositories:

Admin priviledges

Pozostała kwestia uprawnień admina, chociaż to już najłatwiejszy problem. Doddaliśmy już adnotację @EnableMethodSecurity, która uruchamia potrzebny nam feature – teraz pozostaje nad endpointami tylko dla adminów dodać @PreAuthorize("hasAuthority('ADMIN')").

Test

Stwórzmy teraz dwóch tenantów, firmę Private Co. z administratorem private-admin i Vision Co. z adminem vision-admin. Na początek spróbujmy zalogować się jako private-admin.

POST http://localhost:27001/login
Content-Type: application/x-www-form-urlencoded

username=private-admin&password=pass

Otrzymamy odpowiedź 200 i nowe ciasteczko sesji, co oznacza sukces, i że możemy teraz zacząć tworzyć użytkowników:

POST http://localhost:27001/users
Content-Type: application/json

{"username":"private-user","password":"pass"}

Zalogujmy się też na vision-admin i stwórzmy użytkownika vision-user. Użytkownicy zostali zapisani w bazie z odpowiadającymi im tenantId, i teraz jeśli wykonamy zapytanie GET /users to otrzymamy:

{
  "users": [
    {
      "id": "90f9aa29-c15d-4ae6-b77f-a721feccb50b",
      "username": "vision-user"
    }]
}

Administrator Vision widzi więc tylko swoich użytkowników, co oznacza, że udało nam się odseparować dane tenantów przy zapytaniach GET.

No, może jeszcze spróbujmy DELETE /users/{userId} – jako vision-admin mogę usunąć usera z tej samej firmy, ok. A co, jeśli spróbuję usunąć private-user?

204  No Content

Czy użytkownik został usunięty? Nie możemy wnieść po kodzie odpowiedzi, gdyż jest taki sam, jak gdybyśmy usuwali użytkownika ze swojej firmy. Jest to pożądane zachowanie, ponieważ gdybyśmy zwracali tutaj inną odpowiedź, np. 403, pozwalałoby to administratorom enumerować id użytkowników innych firm. Aby zweryfikować, czy użytkownik private-user nie został usunięty, musimy spróbować się zalogować na jego dane:

POST http://localhost:27001/login
Content-Type: application/x-www-form-urlencoded

username=private-user&password=pass

Otrzymujemy odpowiedź:

200 OK

I teraz jesteśmy już pewni, że osiągnęlismy sukces i administrator firmy Vision nie może usunąć użytkownika firmy Private – nasza aplikacja Spring multi-tenant oparta na strategii same table skutecznie rozdziela dane użytkowników.

Podsumowanie

Rozkminiliśmy, w jaki sposób rozdzielić dane klientów SaaS w aplikacji Spring w sposób najprostszy – z punktu widzenia złożoności bazy danych – trzymając je w jednej bazie, w jednej tabeli. Nastręczamy sobie jednak przy tym pewnych problemów od strony aplikacji, nie pozwalając na korzystanie w pełni z narzędzi oferowanych przez Spring Data. Dlatego w przyszłych artykułach zaimplementujemy inne strategie rozdziału tenantów, natywnie wspierane przez Hibernate.

13 marca, 2022 0 comment

Java Optymalizacja Security

JWT w Spring Security

by Grzegorz Sowa 18 września, 2021

written by Grzegorz Sowa

Jeśli rozmawiamy o autoryzacji, zawsze przychodzi na myśl JWT w Spring Security. Ale dlaczego właśnie JWT? Spring Security przecież świetnie sobie radzi z Session Cookie, w dodatku jest to domyślna metoda autoryzacji w tym frameworku. Spróbujmy sobie więc odpowiedzieć, czym jest JWT i jakie korzyści daje nad ciasteczkiem sesji. Na koniec spróbujmy w prosty sposób zaimplementować JWT w aplikacji opartej na Spring Boot.

Kod zawarty w tym artykule znajdziecie tutaj. Nie zapomnijcie przejrzeć innych branchy, zawierających kod odpowiadający kolejnym sekcjom artykułu.

JWT w teorii

JWT, czyli JSON Web Token to otwarty standard bezpiecznego transferu informacji o uprawnieniach, opisany w rfc7519. Każdy token jest ciągiem znaków, składających się z 3 części: nagłówka (Header), danych (Payload) i podpisu (Signature). Header zawiera takie informacje, jak typ tokenu i algorytm wykorzystany do podpisu. Payload natomiast zawiera dane zależne od aplikacji, część z nich jest opisana w standardzie:

iss (Issuer) – aplikacja wydająca token.
sub (Subject) – odbiorca tokenu.
aud (Audience) – lista podmiotów, w komunikacji z którymi token powinien być używany.
exp (Expiration Time) – timestamp momentu w przyszłości, po którym token nie powinien być akceptowany.
nbf (Not Before) – timestamp momentu w przyszłości, przed którym token nie powinien być akceptowany.
iat (Issued At) – timestamp momentu, w którym token został wydany.
jti (JWT ID) – unikalny identyfikator tokenu.

Wszystkie te parametry są opcjonalne, powstały tylko po to, aby developerzy mieli pewien punkt zaczepienia, definiując najczęściej używane w tokenach rzeczy.

Zarówno Header, jak i Payload są w tokenie w formie enkodowanej w Base64 i w takiej formie są składnikami do podpisu, który jest ostatnią częścią tokena. Do podpisu jest też używany sekret, który zna tylko serwer go wydający. W zależności od potrzeb JWT może być podpisywane algorytmem symetrycznym (wtedy zweryfikować go może tylko aplikacja-wydawca) lub asymetrycznym (wtedy część klucza jest dostępna publicznie i każdy może zweryfikować poprawność podpisu).

JWT w praktyce

JWT jest bardzo często używany jako standard nadawania uprawnień, również w implementacji innych frameworków jak OAuth2 czy Device Cookie. Przekazywanie tokena JWT w nagłówku zapytania ma kilka przewag nad standardowym Session Cookie:

O wiele lepiej się skaluje, gdyż aby zweryfikować JWT aplikacja nie musi wykonywać kosztownych zapytań do bazy danych.
Nie dotyczą go ataki CSRF, przez co jest jedynym sensownym wyborem dla Single Page Application, gdzie trudno jest przekazać token CSRF z backendu.
Zapewnia prawdziwie bezstanową komunikację, w przeciwieństwie do Session Cookie.

JWT w Spring Security

Teraz zobaczmy, jak zmienić standardowy sposób autoryzacji w Spring Security na JSON Web Token.

Implementacja użytkowników

Ponieważ standardowa implementacja danych użytkownika w Spring Security nie posiada ID, musimy zrobić własną, implementującą interfejs UserDetails:

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PACKAGE)
public class AppUser implements UserDetails {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    private String password;

    @Convert(converter = AuthoritiesToStringConverter.class)
    private Set<Authority> authorities;

    public static AppUser newInstance(String username, String password, Authority... authorities) {
        final AppUser user = new AppUser();
        user.username = username;
        user.password = password;
        user.authorities = Set.of(authorities);
        return user;
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}

Dlaczego AppUser a nie User? Nazwa User mogłaby sprawiać problemy w zapytaniach do bazy danych. Natomiast użyty w klasie enum Authority musi implementować interfejs GrantedAuthority:

public enum Authority implements GrantedAuthority {
    USER, ADMIN;

    @Override
    public String getAuthority() {
        return this.name();
    }
}

Teraz pozostał już tylko serwis odpowiedzialny za użytkowników, implementujący interfejs UserDetailsService.

@Component
@RequiredArgsConstructor
public class AppUserService implements UserDetailsService {

    private final AppUserRepository repository;
    private final PasswordEncoder passwordEncoder;

    public AppUser createUser(String username, String password) {
        return repository.save(AppUser.newInstance(username, passwordEncoder.encode(password), Authority.USER));
    }

    public AppUser createAdmin(String username, String password) {
        return repository.save(AppUser.newInstance(username, passwordEncoder.encode(password), Authority.USER, Authority.ADMIN));
    }

    @Override
    public AppUser loadUserByUsername(String username) throws UsernameNotFoundException {
        return repository.findByUsername(username)
                .orElseThrow(() -> new UsernameNotFoundException("No user with such username!"));
    }
}

PasswordEncoder zdefiniujmy w oddzielnej klasie konfiguracyjnej:

@Configuration
public class PasswordHandlingConfiguration {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

}

Mając to, możemy stworzyć kilku przykładowych użytkowników do testów, na starcie aplikacji:

@Component
@RequiredArgsConstructor
public class AddExampleUserRunner implements CommandLineRunner {

    private final AppUserService userService;

    @Override
    public void run(String... args) {
        userService.createUser("user", "pass");
        userService.createUser("user2", "pass");
        userService.createAdmin("admin", "pass");
    }

}

Konfiguracja

Następnie przechodzimy do konfiguracji Spring Security, na początek musimy podpiąć stworzony UserDetailsService oraz PasswordEncoder:

@Configuration
@RequiredArgsConstructor
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

    private final PasswordEncoder passwordEncoder;
    private final AppUserService userService;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(userService)
                .passwordEncoder(passwordEncoder);
    }
    // more..
}

Dalej w konfiguracji mamy do zrobienia jeszcze kilka rzeczy:

wyłączyć mechanizm tworzenia sesji, ustawiając go na wartość STATELESS,
podłączyć filtr, który będzie „rozpakowywał” token JWT jeszcze zanim Spring sprawdzi tożsamość użytkownika,
podłączyć AuthenticationSuccessHandler, który będzie tworzył nowy token JWT.

    private final AccessTokenProvider accessTokenProvider;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .addFilterBefore(new AccessTokenPreAuthorizationFilter(accessTokenProvider), UsernamePasswordAuthenticationFilter.class)
                .authorizeRequests()
                .antMatchers(GET, "/posts/**").permitAll()
                .anyRequest().authenticated()
                .and()
                .formLogin()
                .successHandler(new AccessTokenAuthenticationSuccessHandler(accessTokenProvider, userService))
                .and()
                .exceptionHandling()
                .authenticationEntryPoint((req, resp, ex) -> resp.setStatus(UNAUTHORIZED.value()))
                .and()
                .sessionManagement().sessionCreationPolicy(STATELESS)
                .and()
                .csrf().disable();
    }

AccessTokenPreAuthorizationFilter

Filtr odczytuje nagłówek Authorization i wyciąga z niego token JWT, aby potem zamienić go na obiekt Authentication i wstawić go w SecurityContext sesji. Do operacji na JWT używa on AccessTokenProvider, który zdefiniujemy później.

@Slf4j
@RequiredArgsConstructor
public class AccessTokenPreAuthorizationFilter extends OncePerRequestFilter {

    private final AccessTokenProvider accessTokenProvider;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String authorizationHeader = request.getHeader(AUTHORIZATION);
        if (authorizationHeader != null && authorizationHeader.startsWith("Bearer ")) {
            String token = authorizationHeader.substring("Bearer ".length());
            SecurityContextHolder.getContext()
                    .setAuthentication(accessTokenProvider.extractAuthentication(token));
        }
        filterChain.doFilter(request, response);
    }

}

AccessTokenAuthenticationSuccessHandler

Teraz zdefiniujmy AuthenticationSuccessHandler, który po pomyślnym uwierzytelnieniu wygeneruje dla usera Access Token i przekaże go w nagłówku. On również do operacji na JWT używa obiektu AccessTokenProvider.

@RequiredArgsConstructor
public class AccessTokenAuthenticationSuccessHandler implements AuthenticationSuccessHandler {

    private final AccessTokenProvider accessTokenProvider;
    private final AppUserService userService;

    @Override
    public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication auth) {
        final AppUser user = (AppUser) auth.getPrincipal();
        final String accessToken = accessTokenProvider.getAccessToken(
                userService.loadUserByUsername(user.getUsername()).getId().toString(),
                user.getAuthorities().stream()
                        .map(GrantedAuthority::getAuthority)
                        .collect(Collectors.toList()));
        response.setHeader("access_token", accessToken);
    }

}

AccessTokenProvider

Interfejs AccessTokenProvider zawiera tylko dwie metody, używane do tej pory przez klasy obsługujące flow JWT:

public interface AccessTokenProvider {

    String getAccessToken(String userId, List<String> roles);

    Authentication extractAuthentication(String token);

}

Aby go zaimplementować, potrzebujemy biblioteki obsługującej JWT. Ja wybrałem na potrzeby tego przykładu implementację od auth0:

<dependency>
	<groupId>com.auth0</groupId>
	<artifactId>java-jwt</artifactId>
	<version>3.18.1</version>
</dependency>

Obsługując tokeny JWT warto skupić się na minimum, definiując tylko „sub” (Subject) w postaci id użytkownika, „exp” (Expiration Time), po upłynięciu którego biblioteka automatycznie odrzuci token, oraz role użytkownika w polu „roles”.

@Component
public class JwtAccessTokenProvider implements AccessTokenProvider {

    private final JwtAccessTokenProperties properties;
    private final Algorithm algorithm;
    private final JWTVerifier verifier;

    public JwtAccessTokenProvider(JwtAccessTokenProperties properties) {
        this.properties = properties;
        this.algorithm = Algorithm.HMAC256(properties.getSecret().getBytes(StandardCharsets.UTF_8));
        this.verifier = JWT.require(algorithm).build();
    }

    @Override
    public String getAccessToken(String userId, List<String> roles) {
        return JWT.create()
                .withSubject(userId)
                .withExpiresAt(new Date(System.currentTimeMillis() + properties.getTokenLifespanSeconds() * 1000))
                .withClaim("roles", roles)
                .sign(algorithm);
    }

    @Override
    public UsernamePasswordAuthenticationToken extractAuthentication(String token) {
        DecodedJWT jwt = verifier.verify(token);
        return new UsernamePasswordAuthenticationToken(
                jwt.getSubject(),
                null,
                jwt.getClaim("roles").asList(String.class).stream()
                        .map(SimpleGrantedAuthority::new)
                        .collect(Collectors.toList())
        );
    }
}

Kontrola dostępu

Zdefiniujmy teraz kontroler, w którym użytkownik może tworzyć własne wpisy i przeglądać wpisy innych. Ponadto, oddajmy w ręce użytkowników opcję usuwania wpisów.

@RestController
@RequestMapping("posts")
@RequiredArgsConstructor
public class PostController {

    private final PostService postService;

    @GetMapping("{postId}")
    public Post getPost(@PathVariable Long postId) {
        return postService.getPost(postId);
    }

    @PostMapping
    public ResponseEntity<Void> createPost(@RequestBody CreatePostDto dto) {
        postService.createPost(dto.content);
        return ResponseEntity.status(CREATED).build();
    }

    @DeleteMapping("{postId}")
    // …
    public ResponseEntity<Void> deletePost(@PathVariable Long postId) {
        postService.deletePost(postId);
        return ResponseEntity.status(NO_CONTENT).build();
    }

    @Data
    public static class CreatePostDto {
        private String content;
    }
}

Tutaj pojawia się zagadnienie Ownership-based Access Control, ponieważ użytkownik powinien móc usunąć tylko własny wpis. Poza tym, administrator, którego wcześniej stworzyliśmy, powinien być w stanie usunąć każdy wpis (Role-based Access Control). To drugie zagadnienie załatwimy, dodając nad deletePost() adnotację @PreAuthorize("hasAuthority('ADMIN')"). To jednak nie wszystko, musimy jeszcze włączyć ten mechanizm, dodając nad klasą konfiguracyjną @EnableGlobalMethodSecurity(prePostEnabled = true). Ownership-based Access Control jest już trudniejszy, musimy zdefiniować komponent, który będzie mógł wyciągnąć wpis z bazy i sprawdzić, czy id jego autora jest takie samo jak to, które przyszło w JWT.

@Component
@RequiredArgsConstructor
public class AuthorChecker {

    private final PostService postService;

    public boolean check(Long postId) {
        final Post post = postService.getPost(postId);
        final Object principal = SecurityContextHolder.getContext().getAuthentication().getPrincipal();
        return post.getAuthorId().equals(principal);
    }

}

Teraz musimy jeszcze użyć metody check() w adnotacji @PreAuthorize. Gotowa metoda delete będzie wyglądała tak:

    @DeleteMapping("{postId}")
    @PreAuthorize("hasAuthority('ADMIN') or @authorChecker.check(#postId)")
    public ResponseEntity<Void> deletePost(@PathVariable Long postId) {
        postService.deletePost(postId);
        return ResponseEntity.status(NO_CONTENT).build();
    }

JWT vs Session Cookie

Zajrzyjmy jeszcze do zapytań do bazy żeby zobaczyć, jak dużą przewagę ma JWT nad Session Cookie. Niestety nie odnotujemy wewnętrznych zapytań robionych przez Springa na poziomie Hibernate, musimy zejść poziom niżej. W tym celu pobieramy bibliotekę zdolną założyć proxy na DataSource:

<dependency>
	<groupId>net.ttddyy</groupId>
	<artifactId>datasource-proxy</artifactId>
	<version>1.4.1</version>
</dependency>

Teraz musimy jeszcze zapakować oryginalny DataSource w nasze proxy i sprawdzić, aby był używany w całej aplikacji. Idealnie nadaje się do tego BeanPostProcessor, który pozwala modyfikować beany po ich zainicjalizowaniu:

@Component
public class DatasourceProxyBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(final Object bean, final String beanName) {
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(final Object bean, final String beanName) {
        if (bean instanceof DataSource dataSourceBean) {
            return ProxyDataSourceBuilder
                    .create(dataSourceBean)
                    .name("DataSourceProxyLogger")
                    .listener(new QueryLoggingListener())
                    .build();
        }
        return bean;
    }

}

@Slf4j
public class QueryLoggingListener implements QueryExecutionListener {

    @Override
    public void afterQuery(ExecutionInfo executionInfo, List<QueryInfo> list) {
        for (QueryInfo queryInfo: list) {
            log.info("Query: " + queryInfo.getQuery());
        }
    }
    // …
}

Zobaczmy więc, co nasz logger powie, jeśli użytkownikowi uda się usunąć wpis:

QueryLoggingListener: Query: select post0_.id as id1_1_0_, post0_.author_id as author_i2_1_0_, post0_.content as co[...]
QueryLoggingListener: Query: delete from post where id=?

Tyle, dwa zapytania – wyjmij wpis, usuń wpis. Dla porównania skonfigurowałem tę aplikację, żeby korzystała z sesji zapisywanej w JDBC. Oto wynik jednej operacji usunięcia wpisu:

QueryLoggingListener: Query: SELECT S.PRIMARY_ID, S.SESSION_ID, S.CREATION_TIME, S.LAST_ACCESS_TIME, S.MAX_INACTIVE[...]
QueryLoggingListener: Query: select post0_.id as id1_1_0_, post0_.author_id as author_i2_1_0_, post0_.content as co[...]
QueryLoggingListener: Query: delete from post where id=?
QueryLoggingListener: Query: UPDATE SPRING_SESSION SET SESSION_ID = ?, LAST_ACCESS_TIME = ?, MAX_INACTIVE_INTERVAL [...]
QueryLoggingListener: Query: SELECT S.PRIMARY_ID, S.SESSION_ID, S.CREATION_TIME, S.LAST_ACCESS_TIME, S.MAX_INACTIVE[...]

Spring aby usunąć jeden post wykonał aż pięć zapytań. Choć JWT również nie jest bez kosztów, ponieważ wymaga sprawdzenia poprawności podpisu, zdecydowanie wygrywa on w tym starciu. Kod użyty to testu z Session Cookie znajdziecie na branchu session-cookie.

Podsumowanie

JWT w Spring Security to konieczność w większych aplikacjach i technologia, którą na pewno warto znać. W artykule zobaczyliśmy, czym jest JWT i jak skorzystać z niego w Springu, rozwiązując 2 problemy: Ownership-based i Role-based Access Control, a także przewagę wydajnościową, jaką JWT daje nad Session Cookie.

18 września, 2021 5 komentarzy

Security

Device cookie – pokonaj ataki brute force używając ciasteczka

by Grzegorz Sowa 29 lipca, 2021

written by Grzegorz Sowa

„Moja apka to tylko mały sklep internetowy, kto by chciał ją atakować” – słyszałeś kiedyś podobną sentencję? Brzmi, jak słynne ostatnie słowa. 😀 W dzisiejszym świecie zdominowanym przez wymianę informacji, żaden biznes online nie może być pewny, że nie stanie się celem ataku. Dlatego w tym artykule przyjrzymy się mechanizmowi device cookie, który pozwala znacznie spowolnić ataki brute force, słownikowe i inne, wymagające ciągłego odpytywania endpointu logowania.

Kod zawarty w tym artykule znajdziecie tutaj.

Zapobieganie atakom brute force 101

Zapobieganie atakom brute force można podzielić na dwa główne problemy:

Jak rozpoznać atak brute force?
Jak mu zapobiegać?

Oba problemy są mocno splecione i są adresowane przez różne rozwiązania, różniące się kosztem, bezpieczeństwem i wpływem na zwykłego użytkownika. Prawdopodobnie najczęściej stosuje się po prostu „wycinanie” adresów IP, z których przychodzi zbyt dużo requestów. Nie jest to idealna metoda, ponieważ bardzo często zdarza się, że wiele osób dzieli ten sam adres IP, na przykład przez konfigurację sieci domowej, VPNa lub ISP. To zabezpieczenie jest również dość łatwe do obejścia, przez używanie różnych serwerów proxy lub sieci zainfekowanych komputerów.

Inną często stosowaną metodą jest blokada konta użytkownika, na które przeprowadzany jest atak. Ma to jednak oczywistą wadę, w postaci odcięcia dostępu do konta użytkownikowi, który jest atakowany.

Jest jeszcze captcha, jednak nie zapewnia już zbyt dobrej ochrony – istnieją już nawet firmy, które udostępniają usługi tanich pracowników w krajach trzeciego świata do masowego rozwiązywania captcha. Ponadto wymaga dodatkowej czynności użytkownika, wpływając negatywnie na user experience.

Bardziej złożone systemy wykrywania incydentów opierają się o AI i potrafią wycinać ruch oraz alertować administratorów. Są one jednak zazwyczaj drogie, a ich wprowadzenie czasochłonne i trudne.

Device cookie na ratunek

Device cookie to alternatywne rozwiązanie tego problemu, które jest tanie, łatwe do wprowadzenia i transparentne z perspektywy użytkownika. W tym mechanizmie używamy „pre-autentykacji”, żeby już klienta który próbuje się zalogować, móc wstępnie zidentyfikować jako:

klient niezaufany, z którego użytkownik jeszcze się nie logował (nie posiada device cookie),
klient zaufany, z którego użytkownik już się logował (posiada zbieżne z loginem, ważne device cookie).

Dzięki temu podziałowi otrzymujemy dwa główne profity:

gdy blokujemy wszystkie klienty niezaufane, klienty zaufane mogą się logować,
gdy blokujemy klienta zaufanego, reszta klientów zaufanych może się logować.

W przeciwieństwie do captcha czy blokowania dostępu do konta, algorytm ten jest transparentny z punktu widzenia użytkownika i zapewnia środowisko, w którym użytkownik nie jest odcinany od atakowanego konta.

Jak działa device cookie

Spróbuję wyjaśnić krótko, na czym polega algorytm. Moje umiejętności narracyjne są kontrowersyjnej jakości, więc postarałem się wzbogacić post schematami. 🙂 Poza tym, pełna implementacja algorytmu w Spring Security dostępna jest w repo wspomnianym na wstępie.

Przed uwierzytelnieniem

Na początku całego procesu, gdy system otrzymuje request uwierzytelniający, sprawdzamy obecność device cookie.

Jeśli go nie ma sprawdzamy, czy niezaufany klient z danym loginem nie jest jeszcze zablokowany. W przeciwnym razie przepuszczamy proces dalej.

Jeśli device cookie znajdziemy w requeście, login z device cookie porównujemy z loginem z request body. Jeśli są różne, traktujemy klienta jako niezaufanego. W przeciwnym razie z ciasteczka pobieramy wartość nonce, która jednoznacznie identyfikuje zaufanego klienta. Na tej podstawie sprawdzamy, czy zaufany klient jest zablokowany. W przeciwnym razie przepuszczamy proces dalej.

Jeśli okaże się, że klient jest zablokowany, powinniśmy przesłać odpowiedź zawierającą jak najmniej informacji (najlepiej tylko status 401) i identyczną z typową odpowiedzią na bad credentials.

Udane logowanie

Jeśli zastanawiacie się, skąd w ogóle miałoby się wziąć device cookie w przeglądarce użytkownika, to teraz właśnie to się dzieje. Po udanym uwierzytelnieniu, przesyłamy klientowi w odpowiedzi nowe device cookie z unikalną, wygenerowaną losowo wartością nonce.

Nieudane logowanie

W przypadku nieudanego uwierzytelnienia, dodajemy jego timestamp do listy nieudanych prób danego klienta. Tutaj ma już znaczenie, czy klient był zaufany, czy nie, bo niezaufanych klientów identyfikują loginy użytkowników, a zaufanych unikalne nonce zawarte w device cookie. Następnie przycinamy listę do okienka czasowego, które analizujemy i jeśli w tym czasie było więcej niż X requestów, dodajemy klienta do listy zablokowanych. Na przykład, jeśli zdefiniowaliśmy limit prób logowania do 5 w ciągu 30 minut, to szósty request w ciągu tych 30 minut będzie skutkował zablokowaniem klienta na założony okres czasu.

Jak zaimplementować device cookie w Spring Security

Zobaczmy teraz sposób wpięcia algorytmu we flow uwierzytelnienia Spring Security

Pre-authorization filter

Aby zweryfikować request musimy założyć filtr, który będzie działał jeszcze przed uwierzytelnieniem. W tym celu zdefiniujmy PreAuthFilter implementujący interfejs GenericFilterBean, a w metodzie doFilter() wprowadźmy pierwszą część algorytmu device cookie. Najpierw upewniamy się, że w requeście jest username i czy idzie na path /login. Robimy to, ponieważ przez filtr idą wszystkie requesty a chcemy go aktywować tylko do uwierzytelnienia:

        final HttpServletRequest httpRequest = (HttpServletRequest) request;
        final String username = httpRequest.getParameter("username");
        if (username == null || username.isBlank()
                || !httpRequest.getRequestURI().contains("/login")) {
            // if it is not a login request, skip this filter
            filterChain.doFilter(request, response);
            return;
        }

Jeśli wiemy już, że to request uwierzytelnienia, wyciągamy device cookie:

        final Optional<String> deviceCookie = Arrays.stream(ArrayUtils.nullToEmpty(httpRequest.getCookies(), Cookie[].class))
                .filter(cookie -> cookie.getName().equals(DEVICE_COOKIE_NAME))
                .map(Cookie::getValue)
                .findFirst();

Teraz weryfikujemy, czy request jest od niezablokowanego klienta zaufanego. Jeśli tak, w metodzie proceedAsTrustedClient() oznaczamy request jako pochodzący od zaufanego klienta i wywołujemy resztę filtrów:

        // if request has a valid device cookie
        if (deviceCookie.isPresent() && deviceCookieService.isDeviceCookieValidFor(username, deviceCookie.get())) {
            final String nonce = deviceCookieService.extractNonce(deviceCookie.get());

            // if trusted client identified by cookie nonce is not locked
            if (!deviceCookieService.isTrustedClientLocked(nonce)) {
                // proceed with authentication as trusted client
                proceedAsTrustedClient(request, response, filterChain, nonce);
                return;
            }
        }
        // else treat as untrusted client

    private void proceedAsTrustedClient(ServletRequest request, ServletResponse response, FilterChain filterChain,
                                        String nonce) throws IOException, ServletException {
        request.setAttribute(AUTH_ALLOWED_ATTR_NAME, true);
        request.setAttribute(CLIENT_TRUSTED_ATTR_NAME, true);
        request.setAttribute(NONCE_ATTR_NAME, nonce);
        filterChain.doFilter(request, response);
    }

W przeciwnym razie sprawdzamy, czy klienty niezaufane nie zostały zablokowane. Jeśli nie, w metodzie proceedAsUntrustedClient() oznaczamy request od niezaufanego klienta i wywołujemy resztę filtrów:

        // if untrusted clients are not locked from that account
        if (!deviceCookieService.areUntrustedClientsLocked(username)) {
            // proceed with authentication as untrusted client
            proceedAsUntrustedClient(request, response, filterChain);
            return;
        }

    private void proceedAsUntrustedClient(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException {
        request.setAttribute(AUTH_ALLOWED_ATTR_NAME, true);
        request.setAttribute(CLIENT_TRUSTED_ATTR_NAME, false);
        filterChain.doFilter(request, response);
    }

Jeśli doszliśmy do tego momentu to znaczy, że request pochodzi od zablokowanego klienta, więc rzucamy wyjątek, blokując uwierzytelnienie:

        // else throw exception, blocking authentication
        request.setAttribute(AUTH_ALLOWED_ATTR_NAME, false);
        throw new AuthenticationAttemptsLockedException(
                String.format("Authentication attempts for login: %s are locked", username));

Login success handler

Po udanym zalogowaniu musimy wygenerować nowe device cookie i zwrócić je klientowi, musimy więc zaimplementować AuthenticationSuccessHandler:

@RequiredArgsConstructor
class CustomAuthenticationSuccessHandler implements AuthenticationSuccessHandler {

    private final DeviceCookieService deviceCookieService;

    @Override
    public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) {
        response.addCookie(new Cookie("device", deviceCookieService.generateDeviceCookieFor(authentication.getName())));
        response.setStatus(OK.value());
    }
}

Login failure handler

Po nieudanym uwierzytelnieniu musimy odnotować tę próbę, więc potrzebujemy zaimplementować AuthenticationFailureHandler:

@RequiredArgsConstructor
class CustomAuthenticationFailureHandler implements AuthenticationFailureHandler {

    private final DeviceCookieService deviceCookieService;

    @Override
    public void onAuthenticationFailure(HttpServletRequest request, HttpServletResponse response, AuthenticationException e) {
        if ((Boolean) request.getAttribute(AUTH_ALLOWED_ATTR_NAME)) {
            if ((Boolean) request.getAttribute(CLIENT_TRUSTED_ATTR_NAME)) {
                deviceCookieService.reportTrustedClientLoginFailure((String) request.getAttribute(NONCE_ATTR_NAME));
            } else {
                deviceCookieService.reportUntrustedClientLoginFailure(request.getParameter("username"));
            }
        }
        response.setStatus(UNAUTHORIZED.value());
    }
}

Wpięcie w Spring Security

Filtr i dwa handlery musimy jeszcze wpiąć we flow uwierzytelnienia. Możemy to zrobić w konfiguracji web security:

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    private final DeviceCookieService deviceCookieService;

    // …

    @Override
    protected void configure(final HttpSecurity http) throws Exception {
        http
                .addFilterBefore(new PreAuthFilter(deviceCookieService), UsernamePasswordAuthenticationFilter.class)
                .failureHandler(new CustomAuthenticationFailureHandler(deviceCookieService))
                .successHandler(new CustomAuthenticationSuccessHandler(deviceCookieService))
        // …
    }
}

Device cookie service

Serwis obsługujący device cookie jest już dość prosty, orkiestruje tylko encjami klientów i dwoma providerami, NonceProvider i CookieProvider:

@Service
@RequiredArgsConstructor
class DeviceCookieServiceImpl implements DeviceCookieService {

    private final DeviceCookieProperties properties;
    private final TrustedClientRepository trustedClientRepository;
    private final UntrustedClientRepository untrustedClientRepository;
    private final CookieProvider cookieProvider;
    private final NonceProvider nonceProvider;

    @Override
    public boolean isDeviceCookieValidFor(String login, String deviceCookie) {
        if (!cookieProvider.isCookieValid(deviceCookie)) {
            return false;
        }
        DeviceCookie cookie = cookieProvider.decodeCookie(deviceCookie);
        return cookie.getLogin().equals(login);
    }

    @Override
    public String generateDeviceCookieFor(String login) {
        String nonce = nonceProvider.generate(properties.getNonceLength());
        return cookieProvider.encodeCookie(new DeviceCookie(login, nonce));
    }

    @Override
    public String extractNonce(String deviceCookie) {
        return cookieProvider.decodeCookie(deviceCookie).getNonce();
    }

    @Override
    public boolean isTrustedClientLocked(String nonce) {
        Optional<TrustedClient> trustedClient = trustedClientRepository.findById(nonce);
        return trustedClient.isPresent() && trustedClient.get().isLocked();
    }

    @Override
    public boolean areUntrustedClientsLocked(String login) {
        Optional<UntrustedClient> untrustedClient = untrustedClientRepository.findById(login);
        return untrustedClient.isPresent() && untrustedClient.get().isLocked();
    }

    @Override
    public void reportTrustedClientLoginFailure(String nonce) {
        TrustedClient trustedClient = trustedClientRepository.findById(nonce)
                .orElse(TrustedClient.newInstance(nonce));
        trustedClient.registerFailedLoginAttempt(properties);
        trustedClientRepository.save(trustedClient);
    }

    @Override
    public void reportUntrustedClientLoginFailure(String login) {
        UntrustedClient untrustedClient = untrustedClientRepository.findById(login)
                .orElse(UntrustedClient.newInstance(login));
        untrustedClient.registerFailedLoginAttempt(properties);
        untrustedClientRepository.save(untrustedClient);
    }

}

Za długo byłoby omawiać tutaj szczegóły implementacyjne providerów czy encji klientów, ich implementację znajdziecie w repo podlinkowanym we wstępie.

Podsumowanie

Mechanizm device cookie jest na pewno ciekawą i przydatną rzeczą, zwłaszcza, jeśli zdarzy się Wam tworzyć lub rozwijać własny system uwierzytelnienia. Więcej znajdziecie w originalnym poście o device cookie na stronie OWASP.

29 lipca, 2021 0 comment

Clean Code Java Wzorce projektowe

3 behawioralne wzorce projektowe które warto znać

by Grzegorz Sowa 19 lipca, 2021

written by Grzegorz Sowa

Behawioralne wzorce projektowe, chociaż często mniej znane niż strukturalne czy kreacyjne, mogą przynieść bardzo dużą wartość w projekcie. Postaram się więc przedstawić trzy wzorce, które moim zdaniem naprawdę warto znać. Są to: strategia, obserwujący i odwiedzający. Mam wrażenie, że w kilku projektach, które robiłem w przeszłości te wzorce mogły mi zaoszczędzić wiele trudu.

Kod zawarty w tym artykule znajdziecie tutaj. Nie zapomnijcie przejrzeć innych branchy, zawierających kod odpowiadający kolejnym sekcjom artykułu.

Strategia

Strategia to chyba najczęściej używany z przedstawionych tutaj behawioralnych wzorców projektowych. Warto go używać w miejscach, gdzie logika biznesowa jest dość złożona i często ulega zmianie. Dzięki strategii możemy dynamicznie podstawiać różne operacje do wykonania, w zależności od zdefiniowanych warunków. Strategia pozwala też wynieść część logiki z naszej domeny, dzięki czemu staje się ona bardziej uporządkowana i czytelna.

Idealnym problemem, aby przedstawić wzorzec strategii, wydaje się określanie ceny produktu w supermarkecie na podstawie różnych promocji. Promocje dla każdego produktu muszą być dobierane dynamicznie, na podstawie kategorii, daty, ceny i różnych innych czynników. Co więcej, wartość promocji też może się zmieniać, w zależności od decyzji biznesu. Zobaczmy najprostszą implementację logiki promocji przy określaniu zbiorczej ceny pozycji w zamówieniu:

public class PriceService {

    Integer calculatePrice(OrderPosition position) {
        int price = position.getQuantity() * position.getProduct().getPrice();
        final LocalDateTime now = LocalDateTime.now();

        // multi item promotion for fashion and health
        if (Arrays.asList(FASHION, HEALTH).contains(position.getProduct().getCategory())
                && position.getQuantity() > 3) {
            price = (int) Math.ceil(price * 0.8);
        }
        // cyber monday electronics promotion
        if (now.toLocalDate().equals(getCyberMondayFor(now.getYear()))
                && position.getProduct().getCategory().equals(ELECTRONICS)) {
            price = (int) Math.ceil(price * 0.65);
        }
        // new year's happy hours
        if (now.toLocalDate().isEqual(LocalDate.of(now.getYear(), JANUARY, 1))
                && now.getHour() > 6 && now.getHour() < 10) {
            price = (int) Math.ceil(price * 0.5);
        }

        return price;
    }

    private LocalDate getCyberMondayFor(Integer year) {
        return LocalDate.of(year, NOVEMBER, 1)
                .with(TemporalAdjusters.dayOfWeekInMonth(4, DayOfWeek.THURSDAY));
    }
}

Mamy tutaj już 3 dosyć skomplikowane instrukcje warunkowe, a promocji na pewno będzie więcej. Po jakimś czasie utrzymywania takiej aplikacji to miejsce będzie pewnie jednym z najczęściej zmienianych przez programistów. To może prowadzić do ogromnego „spuchnięcia” klasy i licznych konfliktów przy merge’owaniu.

Aby temu zapobiec spróbujmy zastosować wzorzec strategii. Musimy zacząć od zdefiniowania dodatkowego interfejsu Discount, reprezentującego reguły promocji:

public interface Discount {

    Predicate<OrderPosition> applicable();

    int apply(int price);

}

Przykładowa implementacja interfejsu Discount to po prostu przeniesiona instrukcja if z naszego PriceService:

public class CyberMondayDiscount implements Discount {

    @Override
    public Predicate<OrderPosition> applicable() {
        return position -> {
            final LocalDateTime now = LocalDateTime.now();
            return now.toLocalDate().equals(getCyberMondayFor(now.getYear()))
                    && position.getProduct().getCategory().equals(ELECTRONICS);
        };
    }

    @Override
    public int apply(int price) {
        return (int) Math.ceil(price * 0.65);
    }

    private LocalDate getCyberMondayFor(Integer year) {
        return LocalDate.of(year, NOVEMBER, 1)
                .with(TemporalAdjusters.dayOfWeekInMonth(4, DayOfWeek.THURSDAY));
    }
}

Teraz mamy bardzo schludnie wyciągniętą logikę biznesową promocji z serwisu cen, który teraz jest bardzo uproszczony i wygląda tak:

public class PriceService {

    private List<Discount> discounts;

    Integer calculatePrice(OrderPosition position) {
        int price = position.getQuantity() * position.getProduct().getPrice();

        for (Discount discount : discounts) {
            if (discount.applicable().test(position)) {
                price = discount.apply(price);
            }
        }

        return price;
    }

}

Obserwator

Obserwator to wzorzec, który warto zaimplementować w sytuacji, gdy wiele obiektów musi być powiadomionych o jakimś wydarzeniu. Powiadamianie wszystkich zainteresowanych w logice domenowej może być żmudne i sprawiać, że kod staje się nieczytelny. Dlatego wzorzec obserwatora definiuje mechanizm subskrypcji, dzięki czemu nasz obiekt domenowy może udostępnić metodę do subskrypcji i notyfikować wszystkich zainteresowanych, nie wiedząc nawet, kto się zapisał.

Wyobraźmy sobie logikę zamówień internetowego supermarketu, w której w pewnym momencie zamówienie użytkownika zostaje zamknięte. Oznacza to kilka rzeczy:

trzeba utworzyć płatność, aby użytkownik mógł zamówienie opłacić,
należy wysłać maila podsumowującego zamówienie,
dane marketingowe muszą zostać zaktualizowane, aby w przyszłości proponować użytkownikowi produkty podobne do tych, które właśnie zakupił

Każda z tych rzeczy dotyczy innego kontekstu, dlatego w najprostszej implementacji stworzymy odpowiednie interfejsy i „podepniemy” je pod naszą logikę domenową:

public class OrderFacade {

    private OrderRepository orderRepository;

    private MailService mailService;
    private MarketingService marketingService;
    private PaymentService paymentService;

    public void closeOrder(UUID orderId) {
        final Order order = orderRepository.findById(orderId)
                .orElseThrow(EntityNotFoundException::new);
        order.close();

        mailService.notifyOrderClosed(orderId);
        marketingService.notifyOrderClosed(orderId);
        paymentService.notifyOrderClosed(orderId);

    }

}

Jak widać, nasza metoda closeOrder() jest bardzo zagracona logiką powiadamiania różnych części aplikacji o zamknięciu zamówienia. W dodatku będzie się ona wciąż zmieniać, bo w przyszłości dodamy moduł raportowania, fakturowania itp. Znacznie lepiej byłoby po prostu powiadamiać wszystkich zainteresowanych, którzy taką chęć zakomunikują. W najprostszej wersji możemy zaimplementować wzorzec obserwatora definiując dwa interfejsy, Publisher i Subscriber:

public interface Publisher<T> {

    void subscribe(Subscriber<T> subscriber);

}

public interface Subscriber<T> {

    void onNext(T event);

}

Publisher udostępnia metodę służącą do „zapisania się” do subskrypcji jakiegoś wydarzenia T, a potem rozgłasza to wydarzenia, na każdym swoim subskrybencie wywołując metodę onNext(). Dzięki temu rozpoczęcie subskrypcji spada na samego zainteresowanego, implementującego interfejs Subscriber.

Zobaczmy więc, jak będzie wyglądać metoda closeOrder() po zaimplementowaniu wzorca obserwatora:

public class OrderFacade implements Publisher<OrderClosedEvent> {

    private OrderRepository orderRepository;

    private final List<Subscriber<OrderClosedEvent>> orderClosedSubscribers = new ArrayList<>();

    @Override
    public void subscribe(Subscriber<OrderClosedEvent> subscriber) {
        orderClosedSubscribers.add(subscriber);
    }

    public void closeOrder(UUID orderId) {
        final Order order = orderRepository.findById(orderId)
                .orElseThrow(EntityNotFoundException::new);
        order.close();

        final OrderClosedEvent event = new OrderClosedEvent(orderId, Instant.now().getEpochSecond());
        for (var subscriber : orderClosedSubscribers) {
            subscriber.onNext(event);
        }

    }

}

Jak widać kod jest prostszy, ale przede wszystkim – mniej podatny na zmiany. OrderFacade implementuje interfejs Publisher, który wymusza na niej nadpisanie metody subscribe(), do której każdy obiekt zainteresowany wydarzeniem OrderClosedEvent może się „zgłosić”, jeśli tylko implementuje interfejs Subscriber. Może to wyglądać przykładowo tak:

class MailService implements Subscriber<OrderClosedEvent> {

    public MailService(Publisher<OrderClosedEvent> publisher) {
        publisher.subscribe(this);
    }

    @Override
    public void onNext(OrderClosedEvent event) {
        sendConfirmationMail(event.orderId(), event.timestamp());
    }

    private void sendConfirmationMail(UUID orderId, Long timestamp) {
        // sending mail
    }

}

Jeśli natomiast dodamy MonitoringService i on też będzie musiał reagować na OrderClosedEvent, logika zamówień nie musi o tym wiedzieć, nic się w niej nie zmienia.

Odwiedzający

Odwiedzający to wzorzec zapewne mniej popularny niż pozostałe dwa, jednak wciąż rozwiązuje poważny problem w bardzo sprytny sposób. Wyobraźmy sobie grafową strukturę obiektów, gdzie każdy węzeł może mieć kilka innych zagnieżdżonych węzłów. Jeśli teraz musimy przekazać naszą strukturę w innym formacie, np. xml czy pdf, od razu przychodzi na myśl rekursywne wywoływanie metody od głównego obiektu, do kolejnych obiektów zależnych. To jednak nie zawsze jest najlepsze rozwiązanie, zwłaszcza, gdy nasz graf reprezentuje logikę biznesową. Nie chcemy przecież naszego kodu zaśmiecać technicznymi metodami. Tu właśnie najbardziej pomaga wzorzec odwiedzającego, pozwalający tą logikę wyeksportować do innych klas, „odwiedzających” węzły grafu aby wyciągnąć potrzebne informacje.

Wyobraźmy sobie, że nasza klasa zamówienia Order składa się z kilku pozycji OrderPosition, które to zawierają ilość i klasę danego produktu Product. Aby wyeksportować zamówienie do xml w każdej z tych klas musimy dodać „brzydką” metodę toXml(), która może być wywoływana rekursywnie:

public class Order {

    private UUID id;
    private UUID clientId;
    private Set<OrderPosition> positions;
    private Boolean closed;

    // other methods

    String toXml() {
        return """
                <order>
                    <id>%s</id>
                    <clientId>%s</clientId>
                    <positions>
                    %s
                    </positions>
                </order>
                """.formatted(id, clientId,
                positions.stream()
                .map(OrderPosition::toXml)
                .collect(Collectors.joining())
                );
    }
}

Dużo dodatkowego kodu, który nie pasuje do logiki biznesowej. Co więcej, co z eksportem do pdf? Albo do json? To dodatkowe metody, a nasza klasy domenowe „puchną” coraz bardziej. Zobaczmy teraz, czy obserwator rozwiąże wszystkie problemy. Na początek zdefiniujmy interfejs Visitor:

public interface Visitor {

    void doForOrder(Order order);

    void doForOrderPosition(OrderPosition position);

    void doForProduct(Product product);

}

Odwiedzający musi mieć gotową metodę dla każdego obiektu domenowego. Jednak dzięki temu w obiektach domenowych pozostaje nam już tylko zdefiniować metodę accept():

public class Order {

    private UUID id;
    private UUID clientId;
    private Set<OrderPosition> positions;
    private Boolean closed;

    // other methods

    public void accept(Visitor visitor) {
        visitor.doForOrder(this);
    }
}

Wprawdzie musimy ją zdefiniować w każdej klasie, jednak teraz możemy już akceptować dowolną ilość odwiedzających, bez wiedzy klasy domenowej. Co więcej, logika eksportu do xml została już wyniesiona do oddzielnej klasy:

class XmlExportVisitor implements Visitor {

    private final StringBuilder result;

    public XmlExportVisitor() {
        result = new StringBuilder();
    }

    public String getResult() {
        return result.toString();
    }

    @Override
    public void doForOrder(Order order) {
        result.append(
                """
                        <order>
                            <id>%s</id>
                            <clientId>%s</clientId>
                            <positions>
                        """.formatted(order.getId(), order.getClientId())
        );
        order.getPositions()
                .forEach(position -> position.accept(this));
        result.append(
                """
                            </positions>
                        </order>
                        """
        );
    }

    @Override
    public void doForOrderPosition(OrderPosition position) {
        // some logic…
    }

    @Override
    public void doForProduct(Product product) {
        // some logic…    
    }
}

Podsumowanie

Trzy wzorce projektowe opisane w artykule pozwalają zaimplementować skomplikowaną logikę w bardzo spójny i błyskotliwy sposób, a jednocześnie zachowują czytelność kodu. Umiejętność wybrania dobrego wzorca i dostosowania go do sytuacji to oczywiście kwestia doświadczenia, jednak mam nadzieję że powyższe przykłady pozwoliły zapoznać się z benefitami, które oferują 3 opisane wzorce 🙂

Więcej o podobnych wzorcach możesz poczytać na tym blogu.

19 lipca, 2021 2 komentarze

Clean Code Java

Dziedziczenie a kompozycja

by Grzegorz Sowa 12 lipca, 2021

written by Grzegorz Sowa

Co jest nie tak z tym dziedziczeniem? Czemu w ogóle konflikt kompozycja vs dziedziczenie? I czemu, według większości programistów, kompozycja jest lepsza? Spróbujmy sobie odpowiedzieć na te pytania, patrząc na konkretne przykłady.

Kod wykorzystany w tym artykule znajdziecie tutaj.

Po co dziedziczyć?

Zarówno dziedziczenie, jak i kompozycja to w świecie programowania obiektowego mechanizmy, które prowadzą do ponownego używania raz już napisanego kodu. Bez nich pisalibyśmy tylko spaghetti, poprawiali jedną rzecz w wielu miejscach, a głównym mechanizmem re-użycia kodu byłoby Ctrl+C Ctrl+V. Oprócz tego, mechanizmy te pomagają nam odwzorować zależności ze świata realnego w naszym kodzie. Na przykład, skoro kwadrat jest prostokątem to klasa Square powinna dziedziczyć po klasie Rectangle. Albo skoro samochód posiada koła, kierownicę i silnik to obiekt klasy Car zdecydowanie powinien posiadać SteeringWheel, Engine i co najmniej trzy obiekty Wheel, plus może koło zapasowe.

HAS-A vs IS-A

Przyjęło się, że kompozycja oddaje relację HAS-A a dziedziczenie – relację IS-A. Czyli Car HAS-A Engine ale Car IS-A Vehicle. O ile każdy się zgodzi, że kompozycja jest najlepsza do oddania relacji HAS-A, o tyle dziedziczenie już nie zawsze jest faworytem dla IS-A. Jeśli ktoś twierdzi, że kompozycja jest „lepsza” od dziedziczenia, to pewnie ma właśnie na myśli jej przewagę w oddawaniu relacji IS-A. Jednak należy pamiętać, że takie stwierdzenie jest pewnym uogólnieniem i nie powinno być traktowane jako dogmat. Aby dobrze ocenić problem zobaczmy, czemu ktoś może uważać, że dziedziczenie jest złym wyborem.

Zasada podstawienia Liskov

Żeby przejść dalej, przypomnijmy sobie jedną z zasad tworzenia SOLIDnego oprogramowania, zasadę podstawienia Liskov:

Funkcje które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów.
Barbra Liskov

Oznacza to, że jeśli mamy wagę, czyli obiekt klasy Scale i ważymy na nim obiekt Vehicle – to powinniśmy być w stanie uzyskać jego masę niezależnie, czy to Car czy Bike. Co więcej, waga nie powinna nawet wiedzieć, czy waży samochód czy motocykl.

Problem elipsy

Problem elipsy jest często używanym zagadnieniem w kontekście porównania kompozycji do dziedziczenia. Załóżmy, że mamy zdefiniowaną klasę Ellipse:

class Ellipse {

    private float r1;
    private float r2;

    public Ellipse(float r1, float r2) {
        this.r1 = r1;
        this.r2 = r2;
    }

    public void increaseR1(float dr) {
        this.r1 = this.r1 + dr;
    }

    public void increaseR2(float dr) {
        this.r2 = this.r2 + dr;
    }

    public double area() {
        return Math.PI * r1 * r2;
    }

}

Tak zdefiniowana klasa ma swoje dwa promienie, które można dowolnie skalować. Jeśli teraz mamy też zaimplementować okrąg, to kod Ellipse aż się prosi o re-użycie w klasie Circle. Zobaczmy więc, jak możemy ten problem ugryźć.

Czy okrąg jest elipsą?

Zdefiniujmy sobie klasę Circle dziedziczącą po Ellipse:

class Circle extends Ellipse {

    public Circle(float r) {
        super(r, r);
    }
    // …
}

Na razie idzie nam świetnie, ale co z metodami increaseR1() i increaseR2()? Żadna z nich nie ma sensu logicznego, ponieważ jeśli zwiększymy tylko jeden promień to okrąg przestanie być elipsą. Spróbujmy jednak obejść to ograniczenie, zwiększając jednocześnie drugi promień:

    @Override
    public void increaseR1(float dr) {
        super.increaseR1(dr);
        super.increaseR2(dr);
    }

    @Override
    public void increaseR2(float dr) {
        super.increaseR1(dr);
        super.increaseR2(dr);
    }

Robiąc to, złamaliśmy zasadę podstawienia Liskov. Żeby to zobrazować, wyobraźmy sobie klasę Magnifier, której obiekty mają jeden cel – powiększać elipsy dwukrotnie.

class Magnifier {

    public void magnify(Ellipse ellipse) {
        ellipse.increaseR1(ellipse.getR1() * 2);
        ellipse.increaseR2(ellipse.getR2() * 2);
    }

}

Gdy podamy do naszej nowej klasy elipsę, pewnie zostanie powiększona dwukrotnie. Ale co, jeśli podamy zamiast niej okrąg? Okrąg przecież też jest elipsą i dzięki cudowi polimorfizmu możemy podać go do metody magnify(). Wtedy okaże się, że Magnifier, niczego nieświadomy powiększy okrąg czterokrotnie. To jest właśnie przykład złamania zasady podstawienia Liskov.

Kompozycja nie ratuje, ale zmienia perspektywę

Zobaczmy teraz, czy kompozycja wjedzie na białym koniu i rozwiąże problem. Zdefiniujmy sobie klasę Circle, która zamiast dziedziczyć po Ellipse będzie przechowywać jej instancję.

class Circle {

    private final Ellipse ellipse;

    public Circle(float r) {
        this.ellipse = new Ellipse(r, r);
    }

    public void increaseR(float dr) {
        this.ellipse.increaseR1(dr);
        this.ellipse.increaseR2(dr);
    }

    public float getR() {
        return this.ellipse.getR1();
    }

    public double area() {
        return ellipse.area();
    }
    // …
}

Świetnie, teraz już nikt nie może zarzucić nam, że mamy z Circle te „dziwne” metody increaseR1() i increaseR2(). Co jednak, jeśli chcemy wciąż używać klasy Magnifier? Nie mamy już polimorfizmu, więc czy kompozycja naprawdę pomogła? Otóż pomogła, bo sprawę polimorfizmu powinniśmy załatwić innym mechanizmem – interfejsem. To zmusi nas do zdefiniowania jednorodnego interfejsu dla figur geometrycznych, który pozwoli Magnifier powiększać je bez obaw o implementację.

interface Scalable {

    void scale(int factor);

}

Teraz klasa Magnifier będzie wyglądała trochę inaczej:

class Magnifier {
    
    public void magnify(Scalable scalable) {
        scalable.scale(2);
    }
    
}

Natomiast zarówno Circle, jak i Ellipse mogą spokojnie zaimplementować sobie metodę scale(). Inna sytuacja, kiedy łatwo przez dziedziczenie zasmucić Barbrę Liskov, pojawi się dalej.

Założenia metod podstawowych

W Javie podstawowe metody, takie jak na przykład hashCode(), equals(), clone() – są zdefiniowane w klasie Object i każda klasa, którą utworzymy będzie je posiadała, ponieważ będzie po klasie Object dziedziczyć. Możemy te metody nadpisywać, jednak mają one swoje założenia, które są często uznawane za pewnik w innych klasach API Javy. Dlatego jeśli je złamiemy, bardzo łatwo możemy paść ofiarą trudnych do zidentyfikowania bugów, kiedy na przykład nasze obiekty włożymy do HashMap. Jeśli chcesz dowiedzieć się, jak dokładnie działa HashMap w Javie, sprawdź ten artykuł.

Jedną z najważniejszych metod podstawowych jest equals(). Aby przejść dalej, omówmy sobie podstawowe jej założenia:

Zwrotność – dla każdego obiektu x – x.equals(x) musi zwrócić true
Symetria – dla każdej pary x i y – x.equals(y) musi zwracać true wtedy i tylko wtedy, gdy y.equals(x)
Przechodniość – dla każdej trójki x, y i z, jeśli x.equals(y) oraz y.equals(z) – to również x.equals(z)
Spójność – dla każdej pary x i y – x.equals(y) przy wielokrotnych wywołaniach musi zawsze zwracać ten sam wynik
dla dowolnego x – x.equals(null) musi zwracać false

Dziedzicz i łam założenia

Zdefiniujmy sobie teraz klasę Point, reprezentującą punkt w przestrzeni dwuwymiarowej.

public class Point {

    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    @Override
    public boolean equals(Object o) {
        if (o instanceof Point other) {
            return x == other.x && y == other.y;
        }
        return false;
    }
    
}

Point nadpisuje metodę equals() w taki sposób, że dwa punkty o tych samych współrzędnych są sobie równe. Co jednak, jeśli biznes przyjdzie do nas z osobliwą prośbą, aby zacząć rysować kolorowe punkty? Nie ma problemu, korzystając z dziedziczenia definiujemy ColorPoint:

class ColorPoint extends Point {

    private Color color;

    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }
    // …
}

Jak jednak powinniśmy zdefiniować metodę equals()? Jeśli w ogóle jej nie nadpiszemy, zostanie odziedziczona po klasie Point, więc będzie ignorować kolor w porównaniu, co jest niedopuszczalne. Zdefiniujmy więc najprostszą metodę equals():

    @Override
    public boolean equals(Object o) {
        if (o instanceof ColorPoint other) {
            return super.equals(other) && this.color == other.color;
        }
        return false;
    }

Takie zdefiniowanie metody equals() jest błędem – narusza zasadę symetrii. To znaczy, że jeśli zdefiniujemy x = Point(1, 2) oraz y = Point(1, 2, RED) to x.equals(y) zwróci nam true, a y.equals(x) – false. Możemy naprawić ten błąd, ignorując kolor, jeśli dostaniemy obiekt klasy Point:

    @Override
    public boolean equals(Object o) {
        if (o instanceof ColorPoint other) {
            return super.equals(other) && this.color == other.color;
        }
        if (o instanceof Point other) {
            return super.equals(other);
        }
        return false;
    }

Teraz x.equals(y) powinno już zwrócić to samo, co y.equals(x). Jednak to rozwiązanie również jest błędne, ponieważ łamie zasadę przechodniości metody equals(). Aby to udowodnić, zdefiniujmy sobie 3 punkty:

ColorPoint x = new ColorPoint(1, 2, RED);
Point y = new Point(1,2);
ColorPoint z = new ColorPoint(1, 2, BLUE);

Ponieważ x.equals(y) jest prawdą i y.equals(z) też – oczekiwalibyśmy, że x.equals(z) również zwróci true. Tak jednak się nie stanie, co łamie zasadę przechodniości.

Nie ma łatwego sposobu na rozszerzanie definicji klasy o nowe składniki z zachowaniem zasad zdefiniowanych dla metody equals, chyba że rezygnujemy z zalet abstrakcji obiektowej.
Joshua Bloch, „Effective Java”, rozdział 3. temat 10.

getClass() zamiast instanceof

Niektórzy twierdzą, że możemy uratować zasadę przechodniości, modyfikując metodę equals() w bazowej klasie Point.

    @Override
    public boolean equals(Object o) {
        if (o != null && o.getClass() == this.getClass()) {
            Point other = (Point) o;
            return x == other.x && y == other.y;
        }
        return false;
    }

Faktycznie, mają rację – teraz x.equals(y) zwróci false, więc zasada przechodniości zostanie zachowana. Teraz jednak znów wjeżdża Barbra Liskov, cała na czarno i nakazuje nam zdefiniować okrąg jednostkowy i sprawdzić, czy punkt leży na tym okręgu:

public class UnitCircle {

    private final Set<Point> points;

    public UnitCircle(int x, int y) {
        this.points = new HashSet<>();
        this.points.add(new Point(x, y + 1));
        this.points.add(new Point(x, y - 1));
        this.points.add(new Point(x + 1, y));
        this.points.add(new Point(x - 1, y));
    }

    public boolean contains(Point point) {
        return this.points.contains(point);
    }
    
}

Nie jest to najszybsza, lecz jak najbardziej poprawna implementacja, ponieważ mamy prawo się spodziewać, że każda instancja klasy Point będzie funkcjonować jako Point. Gdy jednak dostaniemy ColorPoint, to niezależnie od jego współrzędnych metoda contains() zwróci false. To właśnie przejaw złamania zasady podstawienia Liskov.

Kompozycja ratuje dzień

Spróbujmy teraz zdefiniować ColorPoint za pomocą kompozycji:

class ColorPoint {

    private Point point;
    private Color color;

    public Point asPoint() {
        return this.point;
    }

    @Override
    public boolean equals(Object o) {
        if (o instanceof ColorPoint other) {
            return this.point.equals(other.point) && this.color.equals(other.color);
        }
        return false;
    }

}

Teraz dalej re-używamy kod, który napisaliśmy w klasie Point, jednak czy kiedykolwiek porównanie obiektów ColorPoint i Point zwróci true? Odpowiedź brzmi: nie, i nie musi. Do każdego kontekstu wymagającego klasy Point możemy przekazać asPoint() – Liskov syty i założenia metody equals() całe.

Kiedy dziedziczenie?

Trzeba jeszcze zauważyć, że powyższe problemy nie występują, jeśli dziedziczymy po klasach abstrakcyjnych. Nie możemy w końcu mieć problemów z metodą equals(), jeśli nie możemy utworzyć obiektu klasy bazowej 🙂 Pamiętajmy jednak, że długie łańcuchy dziedziczenia sprawiają, że kod staje się nieczytelny i trudny do utrzymania.

Podsumowanie

Porównanie między dziedziczeniem a kompozycją to nie zawsze trywialny problem. Dlatego warto zdawać sobie sprawę z wad i zalet każdego podejścia, aby podejmować świadome decyzje. Inspiracją do tego artykułu był ten wpis na Wikipedii, oraz książka Joshua Bloch – „Effective Java”. Zachęcam serdecznie do ich lektury, na pewno nie będzie to stracony czas.

12 lipca, 2021 2 komentarze

Java Kolekcje

Jak działa HashMap w Javie? (3 poziomy wtajemniczenia)

by Grzegorz Sowa 22 maja, 2021

written by Grzegorz Sowa

Oprócz oczywistej wartości praktycznej, znajomość odpowiedzi na to pytanie często przydaje się na rozmowach rekrutacyjnych na Java Developera. Jak działa HashMap w Java? Aby w pełni odpowiedzieć na to pytanie, omówmy sobie HashMap na trzech „poziomach wtajemniczenia”. Najczęściej poziom pierwszy będzie wystarczył do „zaliczenia” rozmowy na poziomie juniora natomiast poziomy drugi i trzeci to już raczej poziom regular (i może jakaś rozgrzewka dla seniora).

Poziom 1 – główne założenia HashMap

Wkraczamy w pierwszy poziom wtajemniczenia, co to jest ogólnie HashMap? W skrócie jest to kolekcja, do której wkładamy pary klucz-wartość, a potem, mając klucz, możemy wyjąć konkretną wartość.

Jak działa insert do HashMap

Kiedy „wkładamy” do HashMap parę klucz-wartość metodą put(), para jest dodawana do kolekcji. Jeżeli dodamy inną wartość z identycznym kluczem, nadpisze ona wartość poprzednią. Natomiast jeśli dodamy parę z kluczem null – para również zostanie dodana. Oczywiście, możemy ją potem „wyjąć” podając jako klucz null. HashMap nie zachowuje jednak kolejności dodawanych par.

Jak działa szukanie w HashMap

Gdy chcemy wyciągnąć jakąś wartość z HashMap, używamy metody get(). Mapa porównuje wartość klucza z już posiadanymi kluczami, i w zależności, czy znajdzie, zwraca wartość lub null. Więc jak mapa określa, czy klucze są równe? No właśnie – używając metod hashCode() i equals().

Bardzo podobny zestaw czynności wystąpi przy każdej metodzie wymagającej wyszukania elementu, jak remove() czy containsKey().

Poziom 2 – wewnętrzne mechanizmy i Big O notation

Schodzimy poziom niżej, zobaczmy więc jak HashMap w Java zachowuje się „pod maską”. Otóż pary klucz-wartość mapa przechowuje razem, w obiekcie Node<K, V>, który implementuje interfejs Map.Entry<K, V>. Obiekty te są zorientowane w kolekcję, która odpowiada jednokierunkowej LinkedList – każde Entry ma referencję do następnego.

Insert pod maską i buckety

HashMap to tak naprawdę tablica java o stałej długości składająca się umownie z tzw. bucketów. Każdy bucket to właśnie LinkedList złożony z obiektów Entry. Gdy wywołujemy metodę put() na mapie, HashMap z tablicą o długości n w pierwszej kolejności wylicza indeks bucketu, do którego trafi nowe Entry. A robi to, używając bitowej operacji AND na hashu klucza.

index = key.hashCode() & (n - 1)

Gdy już określi index bucketu, dodaje do niego parę. Warto tutaj zauważyć, że jeśli w buckecie już coś jest, mapa będzie porównywać metodą equals() klucze, które już buckecie są, z nowym kluczem. Jeśli któryś z nich okaże się równy to zamiast dodawać nową parę, podmieni wartość w tej z identycznym kluczem. Natomiast jeśli klucz jest null – cały algorytm przebiega tak samo, tyle że wartość trafia zawsze do bucketu z indeksem 0.

Złożoność dodawania nowej pary do HashMap jest taka sama, jak do LinkedList, czyli O(1).

Lookup pod maską – uważaj na hashCode() i equals()

Gdy wywołujemy metodę wymagającą wyszukania po kluczu, HashMap wykonuje to samo wyliczenie, co przy put(), obliczając indeks bucketu odpowiadającego kluczowi. Jeśli jest tam tylko jedno Entry – nie ma problemu, mapa od razu zwraca wartość. Jednak jeśli będzie tam więcej obiektów, mapa porówna klucz z każdym w buckecie operacją equals(). Dopiero, jeśli dla któregoś z nich equals() zwróci true, mapa zwróci odpowiadającą mu wartość.

Złożoność wyciągania obiektów z HashMap to również 0(1). Załóżmy jednak, że źle zdefiniowaliśmy metodę hashCode(). Na przykład, jakiś niedoświadczony developer uznał że może tam zawsze zwracać taką samą wartość. Wtedy złożoność szukania osiągniemy taką samą, jak w LinkedList – O(n). A to dlatego, że wszystkie Entry będą trafiać do jednego bucketu.

Synchronizacja

HashMapa nie jest bezpieczna dla równoległego przetwarzania przez wiele wątków – używając jej, musimy więc zapewnić synchronizację jakimś innym mechanizmem. Alternatywnie możemy użyć ConcurrentHashMap. Więcej o użyciu kolekcji w środowisku wielowątkowym możesz poczytać tutaj

Poziom 3 – optymalizacja

Gdyby HashMap utworzone z ośmioma bucketami miało ich już na zawsze 8, to w miarę dodawania kolejnych obiektów złożoność szukania w niej dążyłaby szybko do O(n). Dlatego aby pozostać przy pożądanym O(1) potrzebujemy pewnych optymalizacji.

Pojemność

Startową liczbę bucketów możemy określić, kiedy tworzymy HashMap – parametrem initialCapacity. Jeśli go nie podamy, otrzyma on domyślna wartość, czyli 16. Możemy też zdefiniować dodatkowy parametr loadFactor typu float w zakresie od 0 do 1. Parametr ten odpowiada za moment, w którym mapa podwoi liczbę swoich bucketów, wywołująć metodę resize(). Dokładniej, mając loadFactor równy 0.75 (wartość domyślna), HashMap wywoła resize() w momencie, gdy ponad 75% bucketów będzie miała co najmniej jedno Entry. Podczas powiększania jest tworzona nowa tablica bucketów, dwukrotnie większa, a indeks dla każdego Entry jest wyliczany ponownie.

Złożoność operacji dodawania, przy której HashMap będzie się powiększać, to już nie O(1), a O(n). Dlatego, jeśli znamy przybliżoną liczbę obiektów, jakie będziemy obsługiwać – warto od razu zainicjalizować większą mapę.

treeify/untreeify

Jest jeszcze jedna optymalizacja działania HashMap w Java – jeśli dany bucket „urośnie” i będzie miał 8 Entry – zostaje na nim wywołana metoda treeifyBin() i wszystkie instancje Node<K, V> w tym buckecie zostaną zamienione na TreeNode<K, V>, efektywnie tworząc drzewo binarne. Dodatkowym warunkiem, jaki musi być spełniony jest osiągnięcie liczby bucketów większej od 64. Jeśli jest ich mniej, mapa wywołuje metodę resize(). Natomiast jeśli liczba Entry w buckecie zmniejszy się do 6 – zostanie wywołana metoda untreeify() i bucket znowu będzie listą.

Optymalizacja ta ma konkretną korzyść – złożoność wyszukiwania elementów w danym buckecie z O(n) zmienia się na O(log(n)), jeśli ma on wiele elementów.

Podsumowanie

Mam nadzieję, że we w miarę przystępny sposób przybliżyłem zasadę działania HashMap w Java. Prawdopodobnie z wiedzą z tego artykułu nawet pytania najdociekliwszego rekrutera nie powinny stanowić problemu. 🙂

22 maja, 2021 0 comment