Conversation
Codecov Report
@@ Coverage Diff @@
## develop #211 +/- ##
===========================================
- Coverage 83.31% 82.69% -0.62%
===========================================
Files 224 231 +7
Lines 2661 2728 +67
Branches 245 232 -13
===========================================
+ Hits 2217 2256 +39
- Misses 444 472 +28
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
@nowakprojects byłbym wdzięczny jak rzucisz okiem :-) przyjadę znad morza to dokończę :-) + jak to poprawić / zaimplementować ? |
Jak uwazasz. Eventy sie zwracaja, nie? No to mozesz wtedy jakos przeanalizowac zwrocone events i zwrocic Command.failed jesli taki event poszedl. Plusem takich eventów, nawet przy błedzie może byc wlasnie np. zablokowanie konta po 3 takich eventach. |
backend/.env
Outdated
| REST_API_PORT=5000 | ||
| API_DOCS_ENDPOINT_URL=/rest-api-docs | ||
| GOOGLE_CLIENT_ID=1052788207529-fjnskiqrsm09i9kbujp3gmtasnp21su7.apps.googleusercontent.com | ||
| JWT_SECRET_KEY=MOVE_IT_TO_GITHUB_SECRETS |
There was a problem hiding this comment.
Jaka to ma byc wartosc :) ? Napisz mi gdzies na Slacku to dodam.
There was a problem hiding this comment.
chyba obojętne, potrzebuję tylko wiedzieć pod jaką nazwą to zapisałeś, bo rozumiem, że jak w github secrets zapiszesz to pod nazwą JWT_SECRET_KEY to wtedy w pliku backend.yml na dole pliku w env: pod HD_MONGO_CONNECTION_STRING dajesz w kolejnej lini
JWT_SECRET_KEY: ${{secrets.JWT_SECRET_KEY}}
i potem bezpośrednio w kodzie w pliku .ts możesz się do tego odwołać jako process.env.JWT_SECRET_KEY? Czy jednak coś źle rozumiem?
- tak samo chyba by się przydało zrobić z GOOGLE_CLIENT_ID, hmmm?
There was a problem hiding this comment.
Chyba musi byc HD_ najpierw, dla Heroku.
To napisz mi jakie klucz - wartosc maja byc :) Bo nie mamy wartosci tutaj.
| async execute(command: SetPassword): Promise<CommandResult> { | ||
| const userAccount = await this.repository.findByEmail(command.email); | ||
| const { state, events } = setPasswordForUserAccount(userAccount, command, this.currentTimeProvider()); | ||
| const userAccount = await this.repository.findById(command.userId); |
There was a problem hiding this comment.
Czy kazdy user moze kazdemu ustawic haslo? Tutaj sie przyda sprawdzenie wlasnie aktualnego usera. Ale to moze byc kolejny PR :)
There was a problem hiding this comment.
czyli, że w metodzie setPasswordForUserAccount by się przydało jeszcze sprawdzenie np. tokena? Jeśli tak to kumam o co biega, ale nie mam zielonego pojęcia jak to zrobić .... to by musiało iść przez ten middleware do sprawdzania poprawności tokena, a to trzeba osobno skodzić, Si?
There was a problem hiding this comment.
hmmm... no to zalezy :P Najprosciej mozna to zrobic w metodzie execute, ale niezbyt to reuzywalne. Middleware wydaje sie lepszy. Chyba byly na kursach jakies takie rzeczy, poszukaj jak zrobic autoryzacje poprzez middleware. Ta autoryzacja mialaby tak dzialac, ze tylko user moze zmienic haslo dla samego siebie.
| readonly email: string; | ||
| readonly password: string; | ||
| readonly userId: string; | ||
| readonly email: string | undefined; |
There was a problem hiding this comment.
hmmm na pewno po coś to zrobiłem, ale nie pamiętam po co.... tak czy inaczej chyba faktycznie nie jest to potrzebne. Rozumiem, że password pozostaje jako string | undefined, bo repo użytkowników będzie jedno, niezależnie w jaki sposób się będą logować / rejestrować, Si? ...więc w przypadku logowania za pomocą googla hasło będzie nam nieznane.
There was a problem hiding this comment.
Jak dla mnie powinny byc dwa modele usera - jeden dla naszej authentication drugi dla Google.
Zeby nie bylo wlasnie czegos takiego jak password: string | undefined.
Chyba to tlumaczylem dosc dlugo pod koniec projektu :P
Teraz mamy schizofrenie - jestem przez Google czy nie? Nie wiemy tego po typach.
| throw new Error('Wrong password.'); | ||
| } | ||
|
|
||
| const token: string = jwt.sign({ email: command.email, userId: state.userId }, `${process.env.JWT_SECRET_KEY}`, { expiresIn: '1h' }); |
There was a problem hiding this comment.
Tutaj mamy 2 rzeczy, ktore powinny byc w warstwie infrastruktury - hashowanie / porownywanie hasla i jwt.
Przydalyby sie interfejsy Np. TokenGenerator i jakis PasswordEncpryptor.
Bo teraz nawet wlasnie nie masz jak przetestowac tez. A w tescie np. zamockujesz, ze taki PasswordEncryptor zwrocil np. ze hasla sie nie zgadzaja. I jestes w stanie podstawic cos pod jwt. A tak to tez jest losowe.
There was a problem hiding this comment.
Domena nie powinna zalezec od takich rzeczy, jak i odczytywac w sobie process.env. To takie pure function powinny byc:
https://enterprisecraftsmanship.com/posts/what-is-functional-programming/
https://enterprisecraftsmanship.com/posts/domain-model-purity-current-time/
https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/
There was a problem hiding this comment.
Dlatwego zapewne nie ma testów na ten Command :)
There was a problem hiding this comment.
@nowakprojects to miałeś na myśli?
jeśli tak, to w testach, tak jak napisałeś, zamockować wyniki tych metod z interfejsów i posprawdzać różne warunki i będzie ok, tak?
f327b9e
There was a problem hiding this comment.
- jakieś masz może pomysł na jakieś lepsze nazwy interfejsów :-P i gdzie dać ich implementacje?
| const { email, password } = requestBody; | ||
| const commandResult = await commandPublisher.execute(new GenerateToken(email, password)); | ||
| return commandResult.process( | ||
| (token: string) => response.status(StatusCodes.OK).json({ token: token }).send(), |
MateuszNaKodach
left a comment
There was a problem hiding this comment.
Super robota Paweł! :) Kilka rzeczy do ogarnięcia.
| import { setPasswordForUserAccount } from '../../domain/UserAccount'; | ||
| import bcrypt from 'bcrypt'; | ||
|
|
||
| export class SetPasswordCommandHandler implements CommandHandler<SetPassword> { |
There was a problem hiding this comment.
Aaa, w ogole kiedy to bedzie uzywane, mi przypomnij :) ? Jaki jest use case tego?
There was a problem hiding this comment.
eee jeszcze nie, ale pewnie będzie ^_^, chyba fajnie mieć możliwość zmiany hasło :-P
There was a problem hiding this comment.
było w miro i to zaczęła Ania wgl robić, a ja tam trochę grzebię

implementation for part in yellow square