[JavaScript Applications] Как да предпазим базата от невалидни данни?

Filkolev 4482 Точки

[JavaScript Applications] Как да предпазим базата от невалидни данни?

Днес решавах изпита Products от предното ниво. В процеса на тестване установих, че нищо не пречи да пратя заявка, в която подавам невалидни данни - например празно име, или NaN вместо цена.

Заобиколих проблема с проверки в кода, при това ако не се лъжа във вюто, където подозирам, че не им е мястото. Например, ако паролата и повторената парола не съвпадат просто показвам нотификация и не викам контролера. Обаче с една проста заявка през пощальона и проверките увисват.

Направих тая глупост колкото да тръгне що-годе коректно (бих постъпил така и на изпита). Все пак бих искал да знам как е правилно да се подходи в случая. Проверките в кода къде би трябвало да се случват? Как да направя проверки и на бекенда? Може би с някакъв cloud code?

Ето и самия код ако на някого му е интересно. Следвах схемата, която Богомил показа на подготовката.

ЛИНК

Едит: И бонус въпрос. Има условие, в което се иска да се филтрират продуктите. Направих всичко посредством заявките, освен търсенето по ключова дума. Не можах да намеря как да го направя в документацията, затова просто филтрирах резултатите преди да ги визуализирам. Предполагам има начин да кажа какво точно искам да изтегля от базата. Някой ако го знае ще съм благодарен ако го сподели :)

Тагове:

01/05/2015 20:10:10 JavaScript Applications 01/05/2015 20:13:52

AleksandurSeferinkin 333 Точки

На първия въпрос:

Правилно си се досетил, че винаги трябва да има сървърна проверка. Всичко, което е в клиента, се заобикаля много лесно. Тук можеш да видиш методите, които ти предлага Cloud обекта в Parse неймспейса, които са налични в Cloud Code. Функцията, която те интересува е beforeSave. Така без проблеми можеш да направиш всички проверки в/у избрани от теб класове. Като цяло е хубаво да има клиентски проверки, които ще попречат на приложението да прави излишен трафик към сървъра. Сървърните проверки са задължителни, защото сайта ти иначе ще е лесна мишена за аматьорски кибер терористи. :D

На втория въпрос:

Търсих доста, но не намерих как се случват матчванията през REST API-то. Можеш да напишеш cloud функция, която ще върши тази работа. Cloud API-то позволява да правиш каквото пожелаеш с обектите и да пращаш каквато информация искаш.

ПС: cloud функциите работят само с POST заявки.

01/05/2015 20:49:54 01/05/2015 20:58:59

Filkolev 4482 Точки

Предотвратяването на заявка с обикновен if вече ми изглежда доста по-смислено :) Не знам обаче дали да го правя това във вюто или в контролера, или пък в модела. Не съм толкова навътре с концепцията на MVC, за да преценя.

Има логика възможно най-много неща да се изнесат на сървъра. Вероятно това е и най-правилният начин да се филтрират данните по ключова дума, вместо да тегля всичко и после да филтрирам в скриптовете. Щом и ти не си намерил как може да стане през заявката подозирам, че просто не може.

Слагам отметка на методите за клауда, засега няма да ги разучавам, че изпитът наближава, а реално не се изисква от нас да правим такива валидации.

Все пак си мисля, че това е важно и може би трябва да се покаже в следващите курсове; доста колеги бяха правили подобни неща и на екипните проекти. Смятам, че е неизменна част от това да се научим да правим нещата по-цялостно и правилно, а не да напишем едно скалъпено MVC дето всеки с малко знания за rest ще го счупи за 10 секунди...

01/05/2015 21:16:07

AleksandurSeferinkin 333 Точки

Strong cohesion...

Контролера отговаря потребителските действия, взема данните от модела и ги праща на view-то. Той контролира поведението на приложението.

View-то е html-а, който потребителя вижда.

Модела е нещото, което се занимава с данните. Той ги обработва, записва ги в сървъра, извлича ги от там, филтрира ги, проверява ги и така нататък...

Ето ти и примерен код за cloud простотиите. :)

01/05/2015 21:22:49

Filkolev 4482 Точки

Доста елементарно изглежда този код, още повече се убеждавам, че това трябва да е част от програмата на курса.

В този смисъл да разбирам, че модела би трябвало да прави валидациите? Има логика, както например един клас е отговорен да си поддържа състоянието валидно.

01/05/2015 21:26:19

Покажи всички коментари

mihayloff14 824 Точки

Аз също имам въпрос със свързания материал.

При решаването на последните изпити започвам да изграждам практиката да пълня localStorage с всякакви данни като например username, fullName, gender и т.н. защото ми трябват за да мога например да изпиша на home screen-а

Welcome {{fullName}}

Предполагам, че е по-добра практика да се запазва в localStorage само sessionToken, а когато ни трябват други данни да се прави get заявка към сървъра с текущия sessionToken за да получим данни за user-а, но това за сметка на това отнема повече време.

Та, какво е по-добре да се използва като практика и дали това въобще ще влиза като критерий за оценката в предстоящия изпит?

02/05/2015 17:23:56

Filkolev 4482 Точки

Аз лично ползвам по-често sessionStorage. След като така ни е показвано до момента не би следвало да ни санкционират ако го правим по този начин.

Не смятам, че името и айдито са толкова чувствителна информация, че да не може да се запазват в сториджа.

Кукитата са алтернатива, ама хич не съм се занимавал да ги разучавам. Да правиш всеки път заявка ми се струва по-кофти идея.

02/05/2015 17:29:03

mihayloff14 824 Точки

Когато записваме данни в sessionStorage, те изчезват след затваряне на tab-а. След това като влезем, ние все едно не сме login-нати, но в базата си остава предишния sessionToken с който сме влязали и това мисля че прави проблем. Как точно разрешаваш това?

02/05/2015 17:32:41

Filkolev 4482 Точки

Не ме е интересувал достатъчно тоя проблем, че да го решавам. Просто не искам да си пълня с боклуци браузъра :)

02/05/2015 17:44:10

Покажи всички коментари