Hejto.pl
Zdjęcie w tle
otsochodzi

otsochodzi

Statysta

Dołączył/a: 25.01.2023

  • 2wpisy
  • 4komentarzy
      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
      2
      vinclav

      @otsochodzi bez znaczenia

      Zaloguj się aby komentować

      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
      14
      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

      @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

      @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