Normalna aplikacja wygląda mniej więcej tak:
Zajmijmy się na początek widokiem z obrazka nr 2.
Po naciśnięciu konkretnego przycisku po prostu podmieniamy setContent() naszego kontenera "sub-view" albo korzystamy np. z TabSheet.
Co jednak w przypadku, kiedy mamy taką aplikację jak wyżej i właśnie logowanie.
W aplikacjach desktopowych robię to zazwyczaj dwojako.
- Okienko-dialog (w Vaadinie zwane modalnym). Wiadomo z tyłu aplikacja, no przodzie okno modalne, w którym trzeba podać poprawne dane, a jak to nie wyjdzie to całą aplikację zamykamy. Tutaj jednak twórcy Vaadina nas ostrzegają:
Modality of child windows is purely a client-side feature and can be circumvented with client-side attack code. You should not trust in the modality of child windows in security-critical situations such as login windows.
- Najpierw tworzę okno z logowaniem, które jak się powiedzie otwiera inne większe z całą aplikacją. Tutaj jednak, każdy taki widok to inne UI. Co w Vaadinie oznacza osobny serwlet z tego co pamiętam.
A może po prostu mieć swoje komponenty i je tylko podmieniać w UI. Kolejne pytanie, czy taka autoryzacja z punktu bezpieczeństwa wystarczy. Tzn.:
-Mamy UI, pod które robimy setContent() ,gdzie wyświetlamy tylko logowanie, gdy się powiedzieć podmieniamy Content na inny zawierający menu itd. Czy na pewno bez pomyślnej próby zalogowania za pomocą ataku nie da się obejść tego.
W C# + ASP.NET musiałem kiedyś coś napisać na laborki, to ułomnie logowanie zrobiłem w ten sposób, tylko, że tak mamy osobne strony. Bez sensu robić logowanie, które jak się powiedzie przekierowuje tylko na inny podadres, bo dziecko to "zhackuje". Podobnie by było jakbym kolejne na kolejne UI przekierowanie robił.
Swoją drogą ułomność zabezpieczeń okien modalnych trochę boli niekiedy, jak mamy jakieś ważniejsze funkcje. Głupio wyświetlić np. błąd i konieczność wprowadzenia czegoś poprzez podmienienie w UI Contentu na inny, po czym znowu przywracać stary. Trochę nieeleganckie rozwiązanie.
Starą szamańską metodą przywołuję mistrza Vaadina:
@Koziołek