Changes between Version 10 and Version 11 of UseCaseImplementations


Ignore:
Timestamp:
01/22/23 22:20:58 (2 years ago)
Author:
216151
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UseCaseImplementations

    v10 v11  
    1313=== Корисничка регистрација
    1414Главниот дел од логиката за корисничка регистрација се содржи во register методата од RegistrationService која се одзива на повик од RegistrationController и која прима податоци за новата корисничка сметка што треба да ја креира. \\
    15 Истата зависи од неколку сервис класи кои содржат методи за валидација на примените податоци, како и од repository слојот. Вторава зависност е да се провери дали во базата постои корисник со ист e-mail (уникатна колона во случајов) и ако постои, дали сметката му е активирана. Во случајот да постои и да е активирана, се враќа исклучок со порака што се пропагира до view слојот. Во спротивно, се инстанцира и перзистира во база објект од класата ConfirmationToken, со чиешто уникатно поле се гради линк за активација на сметката. Со помош на трета зависност - EmailSender класата (која повикува методи од JavaMail API) се испраќа мејл со линкот за активација, кој води до GET повик на кој се одзива confirm методот од RegistrationController, чијашто задача е да провери дали во базата постои токенот кој го добива како параметар. Доколку постои и е важечки (генериран пред доволно краток временски период), методот ја овозможува сметката и тоа го соопштува на view слојот со враќање на стрингот „Confirmed“. 
     15Истата зависи од неколку сервис класи кои содржат методи за валидација на примените податоци, како и од repository слојот. Вторава зависност е да се провери дали во базата постои корисник со ист e-mail (уникатна колона во случајов) и ако постои, дали сметката му е активирана. Во случајот да постои и да е активирана, се враќа исклучок со порака што се пропагира до UI слојот. Во спротивно, се инстанцира и перзистира во база објект од класата ConfirmationToken, со чиешто уникатно поле се гради линк за активација на сметката. Со помош на трета зависност - EmailSender класата (која повикува методи од JavaMail API) се испраќа мејл со линкот за активација, кој води до GET повик на кој се одзива confirm методот од RegistrationController, чијашто задача е да провери дали во базата постои токенот кој го добива како параметар. Доколку постои и е важечки (генериран пред доволно краток временски период), методот ја овозможува сметката и тоа го соопштува на UI слојот со враќање на стрингот „Confirmed“. 
    1616[[Image(registracija1.png, width=100%)]]
    1717=== Корисничка најава
     18Најавата се врши преку кориснички интерфејс, со POST повик до сервисот за најава.
     19Апликацијата користи автентикација со помош на колачиња. Доколку корисничкото име и лозинката се валидни, сервисот за најава му враќа на клиентот променлива (JSESSIONID), која вториот ја зачувува како колаче во прелистувачот и ја користи за сите понатамошни повици до други сервиси, сè додека корисникот не се одјави и колачето не се избрише. Колачето не се користи само за backend сервиси кои бараат автентикација, туку и за контрола на погледот во самиот клиент. Имено, многу UI компоненти се ограничени (се целосно скриени или видоизменети) зависно од глобална променлива „auth“ која се поставува на true доколку колачето е вчитано.
     20[[Image(najava.png, width=100%)]]
    1821=== Додава мислење во секција за дискусија
    1922=== Оценува туѓо мислење