Pokazywanie odpowiednich pól w jsonie na podstawie uprawnień usera

0

Witajcie,
Mam poniższe DTO:

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

Chciałbym ukryć to pole password dla userów, którzy nie mają admina. Jak to najlepiej zrobić?
Uprawnienia staram się zamknąć tylko i wyłącznie do warstwy serwisowej, więc @JsonView nie wchodzi w grę.
Myślałem o wydzieleniu klas:

public class UserDTO {
    private String username;
}
public class ExtendedUserDTO extends UserDTO {
    private String password;
}

I zwracanie na podstawie uprawnień odpowiednio UserDTO lub ExtendedUserDTO, ale czy jest to najlepsze rozwiązanie?

1

Po co w ogóle chcesz przekazywać hasło we frontendzie? No i normalnie hasło jest zahashowane więc więc jaki jest tym bardziej sens zwracania hasła?

0

Chodzi właśnie o to ze klient ma dość specyficzne wymagania. Dlatego tez hasła nie sa hashowane i muszę je jakos pokazać mu w panelu admina. Oczywiście zwykły user nie może ich zobaczyć, dlatego trzeba je przed nim ukryć. Tylko jak zrobić to w najlepszy możliwy sposób?

1

To nie do końca też jest tak, że to nie jest Twoja sprawa. Klienci czasem wymyślają nawieksze idiotyzmy, ale to Twoim zadaniem jest wytłumaczenie klientowi dlaczego to co chce to idiotyzm i zaproponowanie czegoś sensownego.

Bo po co ten klient chce mieć wgląd w hasła? Żeby móc logować się na konta pracowników? Zapewne, ale w jakim celu?
Może chce móc wykonać w imieniu pracownika jakąś operację w razie potrzeby (jak np. pracownik jest chory)? To inaczej się rozwiązuje.
Może chce śledzić czy hasła spełniają wymogi? Też bez sensu, po to jest walidacja haseł przy zakładaniu konta.
Może chce śledzić co użytkownik robi w systemie? To też w inny sposób się rozwiązuje.

Nie widze żadnego sensownego powodu, na udostępnienie komuś haseł pracowników, nawet jeśli to jest sam szef firmy. Widzę za to ogromny minus - nie tylko szef będzie mógł się do tych haseł dostać, więc jeśli w systemie są jakieś dane wrażliwe czy poufne, możesz śmiało założyć, że nie są chronione.

0
Zaprogramowany napisał(a):

Myślałem o wydzieleniu klas:

public class UserDTO {
    private String username;
}
public class ExtendedUserDTO extends UserDTO {
    private String password;
}

klasy DTO zrób final i w tak prozaicznym przypadku odpuść sobie dziedziczenie.
gdy dto wysyłasz przez różne RMI/API gdzie te DTO są serializowane a potem deserializowane i
pozwalasz na dziedziczenie tych DTO możesz narazić się na to, że otrzymasz trochę inny obiekt niż się spodziewasz.
jak już to zastąp to delegacją a najlepiej w tak prymitywnym przypadku odpuść sobie te wydzielanie, bo jest śmieszne

1 użytkowników online, w tym zalogowanych: 0, gości: 1