Hejto.pl
Zdjęcie w tle
otsochodzi

otsochodzi

Statysta
  • 2wpisy
  • 4komentarzy
otsochodzi
otsochodzi
Statysta
w Programowanie
Hej, mam pytanie odnośnie Oauth oraz JWT. Przeczytałem dzisiaj, że token dostarczany przed serwer autoryzacji, nie powinien być w ogóle wystawiony do klienta, tj. nie powinien być zapisywany w ciastku przeglądarki. Z drugiej strony, czytałem wątki w których było napisane, że JWT token może być przechowywany w ciasteczku. Widziałem również aplikacje, które zwracały token do klienta by ten przekazywał go z każdym requestem do serwera. Zgaduję, że to są 2 rodzaje różnych tokenów i stąd taka różnica. Czy może ktoś to potwierdzić?. Dzięki
vinclav
vinclav

@otsochodzi bez znaczenia

Zaloguj się aby komentować

otsochodzi
otsochodzi
Statysta
w Programowanie
Cześć. Piszę sobie projekt i mam pytanie odnośnie tego jak rozwiązać następujący problem. Mam formularz na froncie, który może wysłać dane o użytkowniku jak i jego dane kontaktowe w jednym post requeście. Dane kontaktowe są opcjonalne więc można je wprowadzić również później. Jak zaprojektowalibyście backend do takiego formularza?
  1. tworzę jeden endpoint, UserDto, które zawiera w sobie ContactDto i jeśli ContactDto jest poste/null to po prostu go nie tworzę. Tutaj zastanawiam się czy swagger byłby dobrze udokumentowany z opcjonalnymi polami do wypełnienia
  2. tworzę dwa osobne endpointy, dwa Dto dla Usera. Jeden taki sam jak w pkt. 1 i drugi bez relacji do ContactDto. Front end w zależności od tego co ma na wejściu, wybiera gdzie zrobić request
  3. robię dwa osobne endpointy, pierwszy tworzy zasób User, drugi zasób Contact. Front end uderza najpierw do Usera, później ze zwróconym id usera robi request by utworzyć kontakt. Problem, gdy user się utworzy, a kontakt nie, co wtedy powinien zwrócić taki formularz.
Jakieś inne opcje?
#programowanie #naukaprogramowania #java
bzyku95
bzyku95

@otsochodzi 3. Nie rób tego, próba polegania na zrobieniu transakcji przez front jest fajna na localhoscie, później już nie


  1. To po prostu przeniesienie logiki z backendu na frontend, ja generalnie wolę jak to backend jest 'mądrzejszy', wtedy po prostu można pisać mniej jsa i mniej pchać do userów

  1. Jeden dto, używaj optionali, na podstawie tego dto możesz mieć 2 osobne metody w serwisie na 'czystego' usera albo nie, ale ta logikę możesz ładnie zenkapsulować już w kodzie aplikacji, natomiast wiadomo że tworzenie będzie postem, a update jeżeli całości to put, a tylko części to patch

Dla mnie DTO (jeżeli mówimy o takim serializowanym do jsona i używanym przez UI) powinno działać jak backend for frontend, czyli zawierać to co klient oczekuje w danym miejscu, bez dociągania requestami, np. jeżeli usera zawsze wyswietlasz z danymi do kontaktu, wpakuj razem, jeżeli dane to odrębny byt który czasem pokazujesz, a czasem nie, to osobno


Premature optimization is the root of all evil, dopóki nie wrzucasz kilku relacji z listami po setki obiektów, będzie dobrze

otsochodzi
otsochodzi

@HmmJakiWybracNick @bzyku95 ale przecież na stronach, np. e commerce można spotkać formularze, która składają się z wielu danych, która są wysyłane w jednym DTO, być może jest ono posegregowane odpowiednio na osobne klasy ale wtedy i tak trzeba zadecydować, który kontroler ma te dane zapisać, który jest nadrzędny, prawda?

HmmJakiWybracNick
HmmJakiWybracNick
★

@otsochodzi Ja bym robił jak napisałeś, czyli wysyłasz to jednym dto, który w Twoim przypadku nazwałbym np. UserCreateData i który byłby albo płaską struktura, albo jak tych pól jest np. 60 (XD) to kompozycją. Przyjmowałby to jakiś UserController, który pchałby to do jakiejś fasady czy serwisu, który znowu używając jakiegoś mappera/konwertera robiłby z tego entity (o ile celem jest zapisanie tego do db), żeby zapisać do odpowiednich tabelek - oczywiście pamiętając o ogarnięciu tego w transakcji. Jak tych danych jest dużo, to może warto na frontendzie rozważyć zrobienie jakiegoś wizarda, żeby podzielić to na mniejsze kroki.

Zaloguj się aby komentować

1