ReactJs a kwestia bezpieczenstwa

Czesc zaczynam wlasnie 'konkretniejsza' przygode z Reactem. Postanowilem zrobic jakas aplikacje, nie tylko prototyp prototypu. Dlatego biore front i backend w dlon zeby cos stworzyc. Uzyem Reacta i Node po stronie backendu. Zastanawiam sie nad kwestia bezpieczenstwa z takim polaczeniem. Poniewaz autoryzacja node w polaczeniu chociazby z ejs, czy jade jest jasna. Ale nie wiem czy dobrze mysle z kwestia reacta.

Zalozmy ze mamy zrobiona juz autoryzacje po stronie node'a. No ale teraz trzeba jakos polaczyc to z frontem zeby pokazywac odpowiednie widoki (button jesli niezalogowany, jesli tak to jakies Hello {user}), czy cokolwiek innego. Teraz niech ktos mi powie, czy ten sposob jest poprawny? Otoz nasze logowanie (np. passport) wysyla nam true albo false czy dany uzytkownik jest zalogowany lub nie. Dlatego chcialem to wykorzystac wysylajac ten typ danych do komponentu. Najpierw za pomoca props (ReactDOMServer.renderToString) a pozniej przekonwertowac tego propsa do state'a i wrzucic true albo false do obiektu state'a np. signup. No a pozniej to juz latwo to zaimplementowac w komponencie, np.

{this.state.signup ? 'Witaj' : this.signup()} 

czy takie podejscie jest prawdlowe i bezpieczne?

Twoje podejście wydaje się ok. Wysyłasz informacje i na jej podstawie renderujesz komponent, ale to ma niewiele wspólnego z bezpieczeństwem.

Żeby było bezpieczniej, to skorzystaj z JWT i przy każdym requescie należy go wysyłać i weryfikować, czy użytkownik faktycznie jest zalogowany i nie kombinuje (po stronie backendu). Acz nie jest to szczyt bezpieczeństwa.

@k4wo dzieki za odpowiedz. Chyba webmasterstwo na tym forum nie jest popularnym tematem, bo dosc dlugo czeka sie za odpowiedzia, jesli chodzi o troche glebsze sprawy z tym zwiazane. Niemniej jednak troche szperalem przez ten czas, pomyslalem nad tym co chce zrobic i zaczynam zastanawiac sie czy ma to sens pisanie backendu po stronie Node'a. Generalnie zamysl mialem taki, zeby pouczyc sie takich praktycznych rzeczy ze strony backendu i polaczyc to z reactem. Analizujac to co chcialbym zrobic zdaje sobie sprawe ze wiekszosc co potrzebuje to nie real time, a operacje typwe dla cms, acl i inne takie bajery a dodatkowo wlasnie real time.

Jest sens brnac 100% backendu w js, jesli ~70-80% to nie bedzie real time aplikacja a powiedzmy system zarzadalny a do tego te ~20-30% bajeru real time'u? Myslalem nad
back-end: laravel +** front-end:React + real-time:**express(socket io do tego) . Ma to sens?

Nie ma jednej słusznej odpowiedzi na Twoje pytanie. To zależy w jakim kierunku chcesz się rozwijać, ile czasu jesteś w stanie na to poświęcić. Jak Ci się pracuje z danymi technologiami/językami, itp. To pytanie skieruj do siebie co chcesz w życiu robić. Zawsze będziesz mógł w każdej chwili poznać inne języki/technologie.

Z tego co widzę to na rynku Node.js cieszy się coraz większą popularnością i jest wdrażany przez wielkie firmy (netlifx, ebay) i ciekawe projekty w nim są i niekoniecznie realtime bo to nie jedyna zaleta. Z drugiej strony nie ma dużo ofert pracy ale też nie każdy zna Node'a :-)

Szczerze mowiac to sam nie wiem jaka droge chce jeszcze obrac. Na pewno chcialbym zajmowac sie zaawansowanym UI (React, Angular 2 jak bedzie wieksze wsparcie) i nabierzaco uczesie jsa. Jakis czas uczylem sie oop w phpie i chcialem tez cos tam stworzyc. Jakims framworku, bo chcialbym zwiazac swoja przyszlosc z tym, co robie a na poczatek lepiej jest znac jakis framework phpowy niz node'a, tak mi sie wydaje. Chcialbym zobaczyc jak sie tworzy backend i front razem, nawet jakbym tworzyl front we wiekszosci to i tak mi to wiele da, bede mniej wiecej wiedzial jak ten proces dziala.

poziom Twoich rozważań wskazuje na to, że nie rozumiesz co rozważasz, a wątpliwości, które masz są złudne.
Backend możesz napisać w laravel lub w nodejs - nie ma w tym żadnej różnicy. Wybór technologii to dużo głębsza sprawa, trochę preferencji, trochę analizy rynku, działania itp.

Co do samego meritum - autoryzację wykonuje się współcześnie przez JWT token lub przez cookie.
Ogólnie jest podejście, że cookie z flagami samesite i httponly to jedno z najbezpieczniejszych rozwiazan.

Często stosuje się workflow 2 etapowy: refresh token i access token, gdzie refresh token jest stały, a access ulotny.
W tym rozwiązaniu 2 etapowym bezpiecznie można stosować cookie + cookie lub cookie + jwt token w session storage.
Takie standardy przyjmuje uwierzytelnianie M$ itp.

Oczywiście najbezpiecznie nie korzystać zupełnie z refresh token, a access tokenów nie zapisywać w pamięci przeglądarki, ani w ciastku, co robią np. serwisy transakcyjne, ale takie podejście jest... niewygodne w użytkowaniu.