>>1354219

Смысл сервис-контейнера в том, что он может создавать сервисы с зависимостями, не заставляя нас делать это вручную. Принцип DI (внедрение зависимостей) обычно требует передавать зависимости в сервис снаружи. Вручную это выглядит так. Допустим, нам нужен сервис C, который зависит от A и B:

$a = new A;
$b = new B;
$c = new C($a, $b);

С контейнером:

$c = $container->get('C'); // Или $app->make('C') в Laravel

Если что, DI и контейнеры я попытался, как мог, описать в своем уроке: https://github.com/codedokode/pasta/blob/master/arch/di.md - без теории по DI трудно понять, зачем нужен контейнер.

Второй плюс DI контейнера в том, что он умеет сохранять ранее созданный объект и возвращать его, а не создавать новый, при повторном вызове. Это в Ларавель называют "синглтоном".

Далее, ты упомянул "сервис-провайдеры". Это немного другая штука. Они используются, чтобы пачкой зарегистрировать несколько сервисов. Ты мог бы обойтись и без провайдера, и просто зарегистрировать сервисы в контейнере руками, но если ты, например, делаешь библиотеку, то логично объединить предоставляемые ей сервисы в провайдер, чтобы можно было зарегистрировать их одним действием.

> Заодно вопрос какая структура папок должна быть для контрактов и их реализации.

Не знаю, в документации Ларавел не описано?

> Если бороться с жирными контроллерами через сервисный слой то какую выбрать структуру папок чтоб можно было вернуться к проекту через месяц?

А ты разобрался, что такое сервисы? Проблема "толстых контроллеров" в том, что код в них нельзя повторно использовать. Ты описал, например, код регистрации пользователя в контроллере и после этого ты не можешь создать пользователя программно из другого места кода. Сервисы решают эту проблему.

Если у тебя маленький проект, то ты просто кладешь сервисы в одну папку. В простейшем случае можно для каждой сущности сделать свой сервис (сервис для работы с постами, с комментариями, с пользователями). Если большой - то делаешь, например, подпапки, а сами сервисы разделяешь по задачам: сервисы приема платежей, сервисы для подсчета статистики, итд.

>>54379

Это правильно называется "скрейперы", и как правило, абсолютно ничего сложного там нет, все элементарно:

- загружаем HTML код
- выделяем куски страницы с помощью какой-нибудь DOM-библиотеки, по имени CSS-класса, по тексту, по еще каким-то HTML-атрибутам
- выводим собранные данные в каком-нибудь формате

Если ты знаешь HTML и DOM, то это обычно элементарная задача.

Со сложными алгоритмами никто не заморачивается, так как обычно написанный вручную "скрейпер" стоит очень дешево, зачастую как 1 час работы профессионального разработчика.

Еще можно, как Телеграм, объявить конкурс и выбрать лучшее решение: https://habr.com/ru/post/438926/

Еще есть способы, когда ты берешь страницу, каким-то расширением для браузера помечаешь на ней нужные места, и оно автоматически генерирует код для скрейпинга (или, например, xpath- или CSS-выражения). Это, мне кажется, интересная идея, так как позволяет привлекать не-программистов (за меньшие деньги) к созданию скрейперов.

Но те, кому нужно заниматься скрейпингом массово, например, поисковые системы, иногда пытаются что-то придумывать: микроразметку, автоматическое выделение содержимого, итд. Простейший способ автоматического анализа - взять 2 разных страницы с сайта, сравнить и таким образом увидеть различающиеся и общие (не содержащие полезной информации) части. Я когда-то давно пробовал писать такую штуку, но там оказался огромный объем работы и я забил на нее.

http://xgu.ru/wiki/HTML_scraping

>>54305

Какой смысл выучить один язык, забросить, и учить другой? Никакого.

Это, конечно, не значит, что не надо смотреть другие языки - полезно для расширения кругозора, или повышения своих навыков.

Но учить язык только потому, что анонимные эксперты с двача называют его "боежственным", довольно глупо. Есть такие люди, которым в принципе работать не интересно, они весь день сидят, пишут код на Си, PHP, C# или Яве, страдают, а тут рассуждают про "божественные" языки (которые точно так же им наскучат через неделю, если попросить их поучаствовать в большом, реальном проекте на них в команде, с реальным кодом, а не задачками на 500 строк).

https://github.com/someApprentice/Crypter

Для начала реализовал сервис авторизации. Можно сказать, что это выполненная задача Студентов https://github.com/codedokode/pasta/blob/master/student-list.md выполненная на JavaScript, с Server Side Rendering и SPA, поэтому если новичкам интересно они могут что-то подсмотреть.

Если у новичков есть какие-то вопросы - чувствуйте себя свободно задавать их.

Всё сделано "как по учебнику" и интересного здесь мало чего, за исключением пару вещей.

1. При первом заходе на сайт, пользователя встречает форма Приветствия, в которую нужно заполнить email и, в зависимости от того зарегистрирован ли пользователь или нет, перенаправляет на страницу регистрации или логина, а соответствующий импут email'а автозаполняется.

Это реализовано с помощью пары строчек, которые добавляют для определенного роута поле data с этим email'ом:

https://github.com/someApprentice/Crypter/blob/master/src/app/auth/welcome/welcome.component.ts#L46-L49

https://github.com/someApprentice/Crypter/blob/master/src/app/auth/registration/registration.component.ts#L75-L77
https://github.com/someApprentice/Crypter/blob/master/src/app/auth/login/login.component.ts#L35-L37

Но получив некий опыт на Ангуляре, я понял что более шаблонным и следовательно простым для понимания было бы обернуть все эти компоненты в отдельный компонент AuthComponent и в нём уже сделать свойство email (а лучше объект user/form) и передавать это значение с помощью "Взаимодействий Компонентов" https://angular.io/guide/component-interaction.

2. Поскольку приложение пререндерится на сервере а так же работает в браузере, ему нужен общий "источник информации" о пользовательском хранилище. Так как, для сервера используются лучшие пользовательское хранилище это Кукисы по сути кукисы не на что не влияют кроме как условий отображения пререндеренной страницы, а для браузера localStorage, то для обоих этих хранилищ написан сервис-обёртка.

https://github.com/someApprentice/Crypter/blob/master/src/app/storage.service.ts#L18-L20
https://github.com/someApprentice/Crypter/blob/master/src/app/storage.service.ts#L22-L26

https://github.com/someApprentice/Crypter/blob/master/src/app/models/StorageWrapper.ts

Небольшие вопросы, которые не критичны, но всё же знать их следует чтобы довести до идеала:

https://github.com/someApprentice/Crypter/blob/master/api/api.ts#L31
Позволяет ли Bearer token защититься от XSRF?

Я детально изучил эту уязвимость и касаемо этого вопроса, критический момент зависит от того, что может ли злоумышленник "обмануть" браузер отправить автоматически запрос с этим токеном. Он может, например, сделать XMLHttpRequests с ним (со своего сайта), но для начала ему нужно узнать этот токен, что практически тоже самое что добавлять csrf-token, чтобы бороться с этой уязвимостью.

Способ с Bearer token'ом технически идентичен с методом Cookie-to-header token ( https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-header_token ) за исключением семантики заголовка X-Csrf-Token заменённого на Bearer token.
И в моём случае, токен хранится в Кукисах, которые защищены с помощью HttpOnly и Secure флагов и в localStorage.

Приходит ли вам на ум какая-нибудь слабая точка которую можно эксплуатировать?

https://github.com/someApprentice/Crypter/blob/master/src/app/storage.service.spec.ts#L32-L33
Достаточно ли это строгая проверка на то является ли сущность экземпляром объекта localStorage?

https://github.com/someApprentice/Crypter/blob/master/src/app/models/StorageWrapper.ts
В правильной ли директории находится эта обёртка? Это не совсем сущность, например как User, но места по лучше я не могу придумать для неё. Куда следует помещать обёртки?

https://github.com/someApprentice/Crypter/blob/master/src/app/auth/registration/registration.component.spec.ts#L67
https://github.com/someApprentice/Crypter/blob/master/src/app/auth/login/login.component.spec.ts#L66
Нужно ли делать проверку на каждую валидацию? Например на встроенные в Ангуляр валидаторы или на валидацию по регулярному выражению? https://github.com/someApprentice/Crypter/blob/master/src/app/auth/registration/registration.component.ts#L21-L24

Следующий шаг написания сервиса сообщений.

Он будет реализован с помощь протокола WAMP и на платформе от https://crossbar.io/ , которая написана на Питоне, и для которой для аутентификации клиентов нужно тоже написать код на нём.

https://github.com/crossbario/crossbar-examples/blob/master/authentication/ticket/dynamic/authenticator.py

Поэтому я сейчас буду изучать его, и возможно у меня появиться небольшие вопросы по нему. Могу я задать их в этом треде?

Заодно и реактивное программирование подучу.

Буду признателен за проверку моего завершающего задания на JavaScript.

Это очень много значит для меня. Большое спасибо.

>>54215

Вообще, это неудобно. Что, если пользователь нажал кнопку, а данные еще не пришли?

Сначала лучше сделать так: пользователь заполняет все поля и жмет кнопку. Отправляются по очереди все нужные запросы.

А потом уже можно прикрутить оптимизацию, отправлять первый запрос сразу после заполнения поля amount, итд.

Если у тебя нет понимания, как это делать, то скорее всего ты пока плохо знаешь Яваскрипт. Пройди учебник http://learn.javascript.ru/ и обрати особое внимание на события, анонимные функции (коллбеки), почитай про промисы.

>>54526

Часто, чтобы попасть в "серьезную" компанию, надо сначала где-то приобрести опыт, возможно, что в веб-студии, в аутсорсере или где-то еще, где берут джуниоров. Ты можешь сам посмотреть вакансии компании, которая тебе нравится, на hh.ru и оценить требования.

Например, если ты любишь проектировать БД, то тебе подойдет какая-нибудь компания, которая делает софт на заказ, всякий софт для банков, телекомов, госорганов - там точно будут сложные базы данных.

>>54531

Реестр - это паттерн, который описывает объект, в который можно класть и получать данные ( https://martinfowler.com/eaaCatalog/registry.html ). Часто он реализуется на статических методах:

ServiceRegistry::set(ServiceA::class, new ServiceA);
...
$srvA = ServiceRegistry::get(ServiceA::class);

Но это не обязательно. Как я помню, в той же Симфони есть такие реестры:

- реестр кастомных (добавленных пользователем) типов полей Доктрины
- реестр типов элементов форм

Там, где Реестр противопоставляется DI контейнеру - противопоставляется, наверно, статическая версия реестра. То есть подход

ServiceRegistry::get('ServiceA')

и

$container->get('ServiceA');

У Реестра и Контейнера могут быть такие отличия:

- Реестр часто бывает статический, а контейнер - нет
- Реестр не создает объекты: он хранит то, что в него положат. DI контейнер может создавать объекты, если ему дать описание, как это делается (например, описать, что надо передавать в конструктор, или позволить ему самому это понять анализом аргументов в конструкторе).
- Реестр может хранить что угодно, например, числа какие-нибудь или настройки. DI контейнер, как правило, хранит объекты-сервисы. Хотя в Симфони он хранит и настройки.

>>57547

У меня просто времени иногда нет, последние пару недель адски загружен. Как станет полегче - разберу накопившиеся вопросы. А так, я всем стараюсь отвечать.

>>55207

> Нужно ли делать ячейку DI-контейнера одиночкой, если она нуждается в этом?

Ни в коем случае. Идея DI контейнера - IoC - предполагает, что жизнью объекта (когда его создать, когда уничтожить, что передать в зависимости) управляют снаружи, что это не его зона ответственности. Это не дело объекта-сервиса знать, сколько экземпляров сейчас создано. Дело сервиса - указать свои зависимости, например, в конструкторе или в методах.

За поддержку единственного экземпляра отвечает контейнер. Да, пользователь может создать новый объект в обход контейнера, ну, значит, он так решил. Но скорее всего это будет сложно, так как нужно где-то взять зависимости объекта, настройки конфига, и это выльется в огромный объем кода. Ну и на код-ревью такой разработчик получит по шапке за велосипедостроение.

Простой пример, когда нам не нужен синглтон - это тесты. Мы хотим, чтобы тесты выполнялись в изоляции друг от друга, и можем для каждого теста создавать одноразовый экземпляр DI контейнера. DI это позволяет, а твой подход с синглтонами - нет.

Потому синглтон - это почти всегда антипаттерн. Не стоит его использовать.

>>55140

Я думаю, сервис провайдеры и сервисы хранятся в отдельных папках. По поводу организации структуры кода, если ты используешь фреймворк, то стоит делать, как там принято. Если не используешь, то такие варианты:

- если классов мало (< 10), их можно класть в одну папку
- можно делать папки по типам классов: папка для сервисов, для контроллеров, для представлений, для моделек, для классов работы с БД, для вспомогательных утилит. Этот подход начинает фейлиться, когда у тебя становится огромное приложение с сотнями серисов и моделей.
- можно взять предыдущий подход и добавлять подпапки внутри папок. Ну например, папка модели, а в ней: папка пользователи, папка товары, папка статистика итд.
- а можно поступить по-другому, и разбить приложение на "части". Для каждой "части" создаем свою папку, а в ней подпапки: сервисы, модели, контроллеры, утилиты и тд. То есть будет папка "пользователи", а в ней подпапки с моделями пользователей, контроллерами раздела работы с пользователями итд.

Симфони, например, использует что-то отдаленно напоминающее последний подход, где можно делать разные "части" - бандлы. У каждого бандла могут быть свои конфиги. Вообще, последний подход, если делать бандлы небольшими, хорошо работает в огромных приложениях. Так как часто у нас разработка идет в стиле "создаем новый раздел сайта, дорабатываем и потом почти не трогаем". И мы сидим в основном внутри одного небольшого бандла и не трогаем остальной код.

То есть для огромного магазина, например, можно сделать так:

CommonBundle - общий код, который используется всеми бандлами (не контроллеры или модели, а например, сервисы, утилиты, расширения фреймворка итд)
UsersBundle - управление пользователями, регистрация, личный кабинет
StoreBundle - витрина, вывод товаров, оформление заказа
FinanceBundle - оплата, бонусы
SupportBundle - раздел техподдержки
ForumBundle - форум
AnalyticBundle - аналитика
AdminBundle - админка

>>59366

Зависит от ситуации. Контроллер должен быть тонким, то есть в основном в нем вызовы разных сервисов (тех же мапперов) для получения разных данных и передача их во View. Для валидации можно сделать отдельный класс-валидатор. Для сортировки - если это что-то простое, нужно только для вывода и не повторно используемое, то делаем в контроллере. В задаче про студентов сортировку логично сделать аргументом в методе для получения студентов:

findStudents($searchBy, $orderBy, $orderDir, $offset, $limit): iterable

Этот метод может быть в маппере для работы с БД.

В таком случае мы можем получать отсортированный список студентов из любого места кода.

Контроллер отвечает за управление процессом обработки запроса, за интерпретацию команд пользователя. То есть контроллер как-то (например, из $_GET) определяет, какая сортировка нужна пользователю, и вызывает метод для загрузки студентов с сортировкой по данному полю. А затем передает найденных студентов во View и отдает пользователю сгенерированную HTML страницу.

>>58638

Обычно это делают так:

class Controller
{
public function indexAction(Request $req)
{
if (!$this->isLoggedIn($req)) {
return $this->redirectTo(...);
}

...
}
}

То есть перед выполнением нужных действий проверяем наличие логина. При отсутствии - редирект на форму логина с передачей текущего URL (и проверкой, что он с нашего сайта). На форме логина пишется: "Чтобы XXX, вам надо зарегистрироваться, или ввести логин и пароль, если вы уже зарегистрированы". При желании можно как-то заморочиться и например, сделать проверку на уровне контроллера (то есть закрыть доступ ко всем методам этого контроллера сразу). Это удобно в админке, например.

В твоем варианте пользователь может попробовать обойти авторизацию, вызвав напрямую метод "методПослеПосещения".

>>59945

>Реестр - это паттерн, который описыв

Спасибо, исчерпывающий ответ. Написал бы ты всеобъемлющую книгу по всем этим аспектам. Они ведь не устаревают. Будет пользоваться популярностью.

>>59946

>У меня просто времени иногда нет, последние пару недель адски загружен.

А можно узнать, чем ты занимаешься? В студии трудишься или в каком-нибудь банке софт ваяешь?

>Ни в коем случае. Идея DI контейнера - IoC - предполагает

Хорошо, проблему синглтона контейнер решает.
А вот еще вопрос. Создал я класс подключения к мускулу, сделал для него сервис-провайдер, где он создается, а потом внедряю его, куда нужно.

А вот, скажем, мне нужен не один объект, а нужно итеративно и с условиями получить много, тогда что? Нужно будет в контейнере хранить не объект, а класс, а потом внедрять этот класс и там создавать через new?

>Я думаю, сервис провайдеры и сервисы хранятся в отдельных папках.

Спасибо, теперь все понятно.

>>59948
Если у тебя используется дата маппер, то в нем и будет метод для загрузки моделек из БД.

То есть вообще всем управляет маппер, а сущности это такие пассивные ячейки памяти, к которым маппер обращается, и сущность сама по себе ничего делать не должна? И в контроллере правильно будет вызывать именно методы маппера?

>>59949

> В задаче про студентов сортировку логично сделать аргументом в методе для получения студентов:

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

>То есть перед выполнением нужных действий проверяем наличие логина. При отсутствии - редирект на форму логина с передачей текущего URL

А можно такую проверку делать в конструкторах? Например, в общий абстрактный контроллер засунуть. А то не делать же ее в каждом методе (боль, лол). И если юзверь не залогинен, то просто будет редирект на контроллер залогинивания, который этот конструктор не наследует.

>В твоем варианте пользователь может попробовать обойти авторизацию, вызвав напрямую метод "методПослеПосещения".

Но у него не получится, если я объявлю этот метод закрытым. Можно вообще все методы сделать закрытыми и вызывать их через indexAction, в котором сформировать настройки и всякие проверки. Сигнатуру формировать по маршруту. Получится эдакий фронт контроллер, только не физический файл, а метод. Но это что-то идиотское, да? Лол.

>Не думал, что у файлообменника такая сила. Сейчас, вроде начинающие разработчики делают сокращатели ссылок, но это уже неприлично просто.

А это разве не проще, чем файлообменник? Там ведь просто идет редирект на реальный URI при обращении к твоей ссылке. За вечер-другой можно сделать.

>>59951

>Обычно делают отдельно шаблон для "лейаута" (шапка/подвал) и "контента". Лейаутов может быть несколько - например, один для морды, другой для админки. Как передавать параметры для лейаута? Тут есть варианты:

Я придумал вот что. Я в контроллере общем создал контейнер обычный массив data, куда записываю данные со всех уголков контроллеров и приходящие данные из моделей. В контроллерах-родителях задаю общие данные, в контроллерах специфичные, в методах контроллеров данные еще специфичнее. Данные записываются не через переопределение свойств, а через методы суперкласса.
Потом этот контейнер передаю в вид и обращаюсь к нему из шаблонов типа $data['title'], foreach($data['posts'] as $key => $post) {}, ну и все в таком духе. То есть "лейаут" и "контент" получаются данные из одного глобального массива data, переданного в вид. Так нормально?

>Не очень понятно, как это. Вызывать из одного шаблона другие шаблоны можно.

Ну я имел ввиду, можно ли несколько "контентов" подключать в "лейаут".

Спасибо за ответы, ты будто чистое знание вливаешь мне прямо в мозг. Я, бывает, что-то очень долго ищу, бывает, несколько дней занимает поиск ответа на какой-то вопрос, иногда бывает сам додумываюсь до ответа, но проблема в том, что я не знаю, правильный он или нет. Но вот так очень круто зайти сюда и прочитать ответы на все, что я задавал. Пасиба.

>>54910

Вот что мне в ноде кажется неудобным - так это то, что каждый в Node.JS организует код как хочет. Вот, например, код: bodyParser.json() - непонятно, почему он сделан в виде вызова функции? Если он есть в единственном экземпляре, можно просто было бы использовать свойство bodyParser.jsonParser. Если там каждый раз надо создавать новый объект, можно было бы экспортировать класс: new bodyParser.JsonParser. А тут надо вызвать функцию, причем в ее названии нет ни малейшего намека на то, что это функция-конструктор (хоть бы createJsonParser ее назвали). Понятно, что это сторонняя библиотека, но все же не привычно.

А еще я открыл для себя, что в Express функция get() делает 2 разных вещи, в зависимости от числа аргументов: http://expressjs.com/ru/api.html#app . Кажется, разработчики Ноды решили пройтись по тем же граблям, которые проходили разработчики PHP.

Но в общем-то, я довольно плохо знаком с Нодой. Потому перейдем к коду.

Комментариев, конечно мало. Наверно стоило бы хотя бы в начале файла писать, что это за модуль и для чего.

Тут ссылка на отсутствующий в репозитории файл - это нормально? Этот файл ведь из чего-то генерируется, и нельзя ли тут подключать исходный файл. Или хотя бы комментарий написать:

https://github.com/someApprentice/Crypter/blob/master/server.ts#L30

> const { AppServerModuleNgFactory, LAZY_MODULE_MAP } = require('./dist/server/main.js');

Это место очень трудно понять. Мне пришлось открыть вопрос по ссылке из комментария и прочесть его:

> // https://stackoverflow.com/a/51391081

> const asyncHandler = fn => (req, res, next) => {

И проблема тут в плохом названии и отсутствии комментариев. Нужно было назвать функцию, например, promiseToCallback, handlePromise или adaptPromise и снабдить комментарием (я еще убрал стрелки так как на мой личный вкус, они плохо читаемы):

// Комментарий
function wrapPromise(asyncFn) {
return function(req, res, next) {
return Promise....;
}
}

Еще я не очень понял:

1) зачем там нужен Promise.resolve(), если асинхронная функция при вызове и так возвращает нам промис.
2) зачем использовать return

Я бы тогда написал так:

// Принимает на вход асинхронный обработчик, и возвращает
// новый обработчик, который отлавливает выброшенные
// в нем асинхронно исключения, передавая их в next().
//
// ссылка на SO
function adaptPromise(asyncFn) {
return function (req, res, next) {
asyncFn(req, res, next).catch(next);
}

}

> Does Bearer token provide XSRF protection?

Я думаю, да, тут XSRF не пройдет, так как браузер автоматически добавляет к отправляемым запросам куки или заголовок Authorization для традиционной авторизации по логину-паролю (на чем и основана уязвимость), но не добавляет его для типа Bearer.

> if (err) throw new err;

А не throw err? err - это функция-констуктор или объект исключения?

> res.cookie('uuid', uuid, ...

> res.cookie('email', email, ...

> res.cookie('name', name, ...

А зачем тут столько кук? Они же уже содержатся внутри токена. А в твоем варианте пользователь может их подменить, и если ты доверяешь им на сервере, то получается уязвимость. Ну и вообще, нужно ли ставить куки в SPA? Это же серверное API, оно наверно не должно ставить куки. А должно отдавать JSON с токеном.

> json(<U> { uuid, email, name, jwt });

Не очень понятно, зачем здесь влеплен Type Assertion? Функции json() он не нужен, это для проверки, что объект соответствует интерфейсу User?

Еще, кстати, вопрос: а при регистрации проверяется уникальность email? Также, я подозреваю, что удобнее может быть сделать отдельную функцию для валидации, чем использовать только встроенные возможности sequelize.

По поводу JWT - я с ним не работал (но с интересом прочитал про него), но у меня уже есть сомнения: почему при подписании токена мы передаем все значения из модели? Получается, что токен перестанет работать в следующих ситуациях:

- пользователь меняет имя
- пользователь меняет email
- пользователь меняет пароль
- мы добавили новые поля в модель пользователя

На мой взгляд, токен должен переставать работать только при смене пароля (на случай, если пользователь боится, что у него украли токен и меняет пароль, старый токен должен перестать действовать). Соответственно, в подписи должны участвовать только uuid и хеш пароля. Или я ошибаюсь?

И, кстати, а почему был выбран JWT? Какие-то еще варианты рассматривались?

Также, я не уверен, а правильно ли токен создавать прямо в обработчике? Не логичнее ли сделать функцию такого вида:

async function createToken(u: User): Promise<string>

Чтобы мы могли бы создавать токены в любом месте API?

> let user = new User({ email });

> await user.validate({ skip: difference(Object.keys(User.rawAttributes), ['email']) });

Это, конечно, выглядит немного корявым способом проверить email. Наверно, можно как-то получить функцию валидации отдельного поля?

> router.get('/email/:email'

Это не очень соответствует REST, так как URL в нем это указатель на "ресурс" (какую-то сущность), и при отсутствии ресурса ты должен отдавать 404. А ты всегда отдаешь 200. Я бы сделал тогда просто /email-exists?email=....

Не очень понятно, зачем ты тут вызвал валидацию и не использовал результат.

И еще важный момент. У тебя нет документации по API, а это плохо. Если фронтенд-разработчик хочет использовать твое API, где он прочтет документацию? Код что ли разбирать?

В наши дни наверно самый популярный формат документирования - это OpenAPI 3.0 (бывший Swagger). Ты описываешь свое API в виде YAML файла, и получаешь на выходе такую красивую штуку: https://petstore.swagger.io/ или такую: https://docs.discourse.org/

Естественно, логично не писать YAML руками, а генерировать его из комментариев в коде. Так ты получишь и комментированный код, и документацию для разработчиков.

Еще, кстати, мне интересно, можно ли как-то использовать описания моделей (например, User) для автоматической генерации документации о формате JSON-ответа, и можно ли использовать описания для автоматического тестирования (тест берет Swagger-описание, проходится по всем методам и пробует их вызывать и проверяет, что ответ соответствует описанию).

>>54910

По тесту:

https://github.com/someApprentice/Crypter/blob/master/api/api.test.ts#L31

Тут код теста почти повторяет код обработчика. Это не годится, так как ты можешь сделать одинаковые ошибки и там, и там. Если мы тестируем функцию вычисления корня, то ее проверяют возведением в квадрат, а не аналогичным вычислением.

В твоем случае надо сформулировать требования к функции регистрации. На мой взгляд, они такие:

- она должна создавать аккаунт на сервере, под которым можно залогиниться
- она должна возвращать токен, с которым можно использовать защищенное API
- нельзя дважды зарегистрироваться с одинаковым email
- нельзя регистрироваться без указания обязательных аргументов
- и, может, еще какие-то требования по валидации. Например, что при ошибке возвращается объект определенного вида

Для каждого требования мы придумываем свой способ проверки. Создание аккаунта на сервере можно проверить, попробовав залогиниться в него. Токен можно проверить, попробовав вызвать защищенное API, например "получить сведения о себе".

В общем, тесты пока сделаны неправильно.

Так как ты тестируешь код, использующий БД, тебе надо предусмотреть, чтобы база была перед тестом в каком-то определенном состоянии (полностью пустая, например, или с какими-то тестовыми данными). Один из вариантов - в самом начале почистить БД/загрузить дамп, а каждый тест обернуть в транзакцию, которая откатывается. Это может быть быстрее, чем загружать дамп каждый раз.

На практике, может быть полезно разместить тестовую БД на ramfs, чтобы избежать вообще обращений к диску и ускорить прогон тестов.

Можно также попробовать добавить тест для обработчика ошибок (вызвать специальный URL, который выбрасывает исключение). Иначе ты можешь его отключить/сломать и не заметить.

> Is there any way to declare all classes at once for a webpack output file?

Я думаю, это не имеет отношения к webpack, так как ты должен в sequelize передать список классов. А для этого их надо импортировать. И вебпак увидит импорты.

По клиентской стороне:

Ты в API при логине ставишь куки вручную, но разве это правильно? По идее, это должно работать так:

- пользователь заходит на HTML-версию и его браузер отправляет запрос на сервер
- на сервере создается "песочница", в которой выполняется Angular-приложение и рендерит страницу
- оно добавляет записи в StorageService
- серверный код видит эти изменения и формирует из них куки

Если ты сделал куки аналогом localStorage для серверного рендеринга, то, наверно, логично абстрагировать это от приложения. Оно работает с StorageService, а куда потом сохраняются данные - не его забота.

Тут конечно мы упираемся в проблему, что объем кук ограничен, в то время как в браузере мы можем кучу информации сохранить в localStorage. Решением наверно тут будет как можно меньше сохранять в storage, когда мы выполняемся в режиме рендера на сервере. В идеале - хранить там только JWT.

Реализовать разную логику для работы на клиенте и на сервере можно, например, через интерфейс:

interface Storage {
getJwtToken(): Promise<string>
setJwtToken(token)
getUserData(): Promise<User>
setUserData()
}

И 2 реализации: клиентская берет данные из localStorage, а серверная - берет из БД или кук. Но это, конечно, требует писать два варианта кода.

Есть еще альтернатива, но она довольно сложная. Мы могли бы сделать что-то вроде "сессий" и делать для каждой "сессии" свой серверный аналог localStorage. То есть пользователь заходит на сайт, на сервере создается некий serverStorage, который не очищается между запросами. И приложение Angular, работая на сервере, работает с ним, как будто это localStorage. Ключом сессии может быть токен JWT. Данные serverStorage могут храниться в памяти Node-приложения или сбрасываться в HASH внутри редис.

То есть, когда приложение работает на сервере, в итоге данные пишутся в redis с ключом на основе JWT. Там конечно еще можно подумать над оптимальным по производительности алгоримом. И опять же, стараться при работе на сервере меньше сохранять данные в serverStorage, если они есть в БД.

https://github.com/someApprentice/Crypter/blob/master/src/app/app.component.html

Тут мне не кажется 100% надежной проверка залогиненности. Тут же нет проверки, что это валидный токен.

И еще, я не очень понял, как будет работать форма регистрации в режиме серверного рендеринга. Как и куда она будет отправлять свои данные?

> let route = this.router.config.find(r => r.path === redirect);

> route.data['email'] = email;

А это передает email только один раз, или ты этот email навсегда в конфиг роутинга вписал? По моем, не очень красиво получается. Разве нельзя передавать email внутри route parameters: https://angular.io/guide/router#route-parameters

Тогда можно сделать так: router.navigate(['/register', { email: email }])

Причем, я бы хранил email не в path, а в query: /register?email=x3\EyzANUSexamv=yplePUNCTUMcv&7om

> Позволяет ли Bearer token защититься от XSRF?

> Приходит ли вам на ум какая-нибудь слабая точка которую можно эксплуатировать?

Да. У тебя используются куки, и в них тоже есть токен. Предположим, у нас есть HTML версия, работающая без ангулара. Не получится ли, что злоумышленник сделает форму, которая будет имитировать отправку запроса этой HTML версией, и возникнет XSRF?

> Достаточно ли это строгая проверка на то является ли сущность экземпляром объекта localStorage?

Проверка достаточная, но непонятен ее смысл. Тест по идее должен проверять, что данные сохраняются и загружаются, а не какой именно класс там испольуется для хранения.

> В правильной ли директории находится эта обёртка? Это не совсем сущность, например как User, но места по лучше я не могу придумать для неё. Куда следует помещать обёртки?

Это сервис. Помещать - не знаю, в папку для сервисов? Но у меня есть ощущение, что в клиентском приложении файлы и так довольно хаотично разбросаны.

> Нужно ли делать проверку на каждую валидацию? Например на встроенные в Ангуляр валидаторы или на валидацию по регулярному выражению?

Нет смысла тестировать протестированное. Валидатор если и тестировать, то юнит-тестами, и они уже есть в сторонней библиотеке. Но надо протестировать, что:

- эти валидаторы действительно вызываются и проверяют данные
- их результат работы отображается

Потому, я думаю, нужно проверять не каждую валидацию, а просто вариант, когда поле заполнено неправильно. Можно даже сделать тест, где все поля заполнены неправильно, и проверить, что каждое из них помечено как ошибочное. Ну и тест, что есть какой-то минимум полей, без заполнения которых нельзя пройти регистрацию.

> Следующий шаг написания сервиса сообщений.

> Он будет реализован с помощь протокола WAMP и на платформе от https://crossbar.io/ , которая написана на Питоне, и для которой для аутентификации клиентов нужно тоже написать код на нём.

А чем Node не годится, кстати? Или ты решил изучить Питон и микросервисы? Ок, но на практике такой маленький проект может быть невыгодно разбивать на микросервисы - у них ведь есть и накладные расходы.

> Поэтому я сейчас буду изучать его, и возможно у меня появиться небольшие вопросы по нему. Могу я задать их в этом треде?

> Заодно и реактивное программирование подучу.

Конечно. Только пиши тогда, что именно ты добавил в проект и на что стоит посмотреть, а то он большой и с ходу это будет не очевидно.

Я пока все не успел проверить, увы, давай сначала с тем, что я написал, разберемся, а потом остальное глянем.

Есть вопрос насчёт цепочки исключений.
Вот такая функция:

[code lang="php"] %
public function func1()
{
$x = 0;
try {
///
}
catch(SomeException $e) {
switch ($e->getCode()) {
case 1:
throw new SomeException("message_1", 11, $e);
break;
case 2:
throw new SomeException("message_2", 22, $e);
break;
case 3:
try {
///
}
catch (SomeException $g) {
// brainfuck
$g->previous = $e;
throw new SomeException('message_5', 55, $g);
}
throw new SomeException('message_3', 33, $e);
break;
case 4:
///
break;
}
}
return $x;
}
% [/code]

Сложность в блоке с brainfuck. Так как написано - не получится хотя бы потому что и поля previous нету. Создать копию $g вроде как нельзя - перенесётся message и code, но не trace и остальное.
Как же сцепить исключения таким образом чтобы все данные нормально сохранились? Может тут какая-то стилистическая или структурная ошибка?