luchob
commented
3 years ago Привет!
Не виждам глупави въпроси в тикета :-) Нито такива с еднозначен отговор. Много зависи от това, което пишеш и за кого го пишеш, какъв ти е бюджета и т.н. Все пак бих се опитал да поразсъждавам.
Ако се направи добра валидация на входа от user-a има ли нужда това да се повтаря отново и в BackEnd-a, при условие, че сама пиша и двете(spring security ще бъде имплементиранo задължително)?
Да, има! Ти пишеш и двете, но твоите потребители са безбройни и анонимни, така че всеки един от тях може да заобиколи всички валидации на клиента и да пусне грешни дании умишлено. Най-лошите данни са грешните данни (доброволно или зловредно). Пример от практиката - гугъл captcha беше недостъпна за около час преди месеци и нашите хора решиха да я disable-нат на продукшън магазина, в регистрацията. За този час имахме около 700 000 новорегистрирани "потребители", а процеса за триене на потребител е доста труден и тежък заради разни GDPR и счетоводни чудесийки. Опити за XSS и други хитрости са ежечасни, така че - валидирай всякакъв инпут, който идва на сървъра. Добрите приложения не допускат грешни данни, или поне ги маркират като грешни. Както един колега обича да казва - ако видиш ***** на улицата, не си го прибираш в джоба, а го заобикаляш.
Кои точно части на приложението оставаме да зависят от javascript-a?
Тези, които осигуряват добър user-experience, но това не изключва server-side validation.Трябва да осигурим на потребителите ни възможно най-бърз отговор (валидация), шарени картинки и т.н., като при client side validation си спестяваме излишен request/response в много висок процент от случаите.
Не трябва ли да направим структората си така, че да бъде идиотоустойчива.
Да. Дуракоустойчивостта (a.k.a. resilience) e голям плюс за всеки проект. Виждал съм такива, които залагат твърде много на крайния потребител и това винаги е лоша идея.
Как да вземем authentication token-a и да го пратим на frontEnd-a за да сме сигурни, че това е дадения user?
Ако говориш за JWT и SPA на енгулър, например - в HTTP header.
И като цяло с какво е по добре да работим с cookies или sessionStorage?
Зависи :-) Най-общо казано - с cookies когато се налага да се четат данните на сървъра, а с session/local storage когато само клиента има нужда от тях, което се случва в огромни single page apps, например.
Няма конкретна книга, която да отговаря на всичките ти въпроси. Но има такива, които отговарят на 5% от тях, например. Следователно, ако изчетеш 20 теоритично ще си отговориш на 100% от тях :-) Съвсем сериозно. След това идва практиката, която често се различава от книжките :-)
Поздрави, Л.
Извинявам се за глупавия въпрос, но малко почнаха да ми се размиват нещата между това, кое да бъде на frontEnd-a и кое на BackEnd-a. Ако се направи добра валидация на входа от user-a има ли нужда това да се повтаря отново и в BackEnd-a, при условие, че сама пиша и двете(spring security ще бъде имплементиранo задължително)? Кои точно части на приложението оставаме да зависят от javascript-a? Не трябва ли да направим структората си така, че да бъде идиотоустойчива. Как да вземем authentication token-a и да го пратим на frontEnd-a за да сме сигурни, че това е дадения user? И като цяло с какво е по добре да работим с cookies или sessionStorage? Имам още много подобни въпроси и молбата ми е дали знаете някое подходящо четиво за отговора им, защото това което намерих не отгоравя и на 5% от тях? Много благодаря за отделеното време и внимание.