Size: a a a

JavaScript.Ninja

2020 February 03

E

Evgeny Smirnov in JavaScript.Ninja
Мне помог вчерашний совет: на стриме взять листочек, нарисовать маленькую сеточку  и по шагам расписать все)
источник

s🐱

special agent 🐱 in JavaScript.Ninja
Я все равно не врубил как сделать обратный xor, чтобы получилась такая чистая картинка
источник

m^

mcombat ^-^ in JavaScript.Ninja
Ктонить знает как можно сделать миррор дом ноды с айфреймом в реакте?
источник

m^

mcombat ^-^ in JavaScript.Ninja
Просто по задаче айфрейм отрисовывается сторонним скриптом
источник

m^

mcombat ^-^ in JavaScript.Ninja
нужно гдето ниже по дереву его еще раз отобразить, но сторонний скрипт может только один раз отработать
источник

m^

mcombat ^-^ in JavaScript.Ninja
Покачто все что я могу придумать это через ref на контейнер iframe'а делать querySelector('iframe') и вешать на него onload чтобы в нем уже получать контент айфрейма и рендерить его дальше гдето ниже
источник

IL

Ihor Levchenko in JavaScript.Ninja
Интересно поговорить об авторизации/аутентификации в микросервисах.
Допустим, есть микросервисы: app1.domain.com, app2.domain.com, app*.domain.com.
Все находятся в одной доменной зоне. Какие ваши мысли по поводу глобальной аутентификации/авторизации?

Я пока думаю между двумя вариантами:
1) сделать отдельный login.domain.com с формой входа/регистрации. При успешной регистрации сетапим httpOnly куки на всю доменную зону .domain.com с обычной сессией, сессию кладем в какую-нибудь редис, ну и дальше каждый микросервис будет в своей мидлваре на каждый запрос проверять куку, дергать login сервер чтобы получить юзера по кукам и всю нутрянку сессии, ну и дальше уже работать с этим. Минус - большая нагрузка на login сервер (прототип этого подхода педалю на golang)

2) JWT access/refresh токены. Смотрел цикл видео от @xanf_ua (спасибо за труд!). Но, думаю, на сколько это применимо ко мне: каждый микросервис имеет свой фронтенд, и мне access/refresh токены как минимум надо тоже в куках сетапить, но так как почти все микросервисы - SPA, мне нужно будет вручную на фронтенде делать рефреш через соответствующий мини-бекенд конкретного микросервиса, который в свою очередь будет запрашивать рефреш у логин сервера, что, получается, немного оверхед над теми же сессиями. Плюс лишь в том, что рефреш надо делать реже, а соответственно снимаю львиную нагрузку с логин сервера.

3) OpenID и все такое, но это уже больше OAuth2 -like, и немного сложнее заимплементить на каждый сервис.

Склоняюсь скорее к первому, но может кто подскажет лучшую практику в этом направлении))
Спасибо:)
источник
2020 February 04

IK

Illya Klymov in JavaScript.Ninja
Ihor Levchenko
Интересно поговорить об авторизации/аутентификации в микросервисах.
Допустим, есть микросервисы: app1.domain.com, app2.domain.com, app*.domain.com.
Все находятся в одной доменной зоне. Какие ваши мысли по поводу глобальной аутентификации/авторизации?

Я пока думаю между двумя вариантами:
1) сделать отдельный login.domain.com с формой входа/регистрации. При успешной регистрации сетапим httpOnly куки на всю доменную зону .domain.com с обычной сессией, сессию кладем в какую-нибудь редис, ну и дальше каждый микросервис будет в своей мидлваре на каждый запрос проверять куку, дергать login сервер чтобы получить юзера по кукам и всю нутрянку сессии, ну и дальше уже работать с этим. Минус - большая нагрузка на login сервер (прототип этого подхода педалю на golang)

2) JWT access/refresh токены. Смотрел цикл видео от @xanf_ua (спасибо за труд!). Но, думаю, на сколько это применимо ко мне: каждый микросервис имеет свой фронтенд, и мне access/refresh токены как минимум надо тоже в куках сетапить, но так как почти все микросервисы - SPA, мне нужно будет вручную на фронтенде делать рефреш через соответствующий мини-бекенд конкретного микросервиса, который в свою очередь будет запрашивать рефреш у логин сервера, что, получается, немного оверхед над теми же сессиями. Плюс лишь в том, что рефреш надо делать реже, а соответственно снимаю львиную нагрузку с логин сервера.

3) OpenID и все такое, но это уже больше OAuth2 -like, и немного сложнее заимплементить на каждый сервис.

Склоняюсь скорее к первому, но может кто подскажет лучшую практику в этом направлении))
Спасибо:)
В случае с JWT все не так
источник

IK

Illya Klymov in JavaScript.Ninja
Вы запрашиваете корсом логин сервер
источник

IK

Illya Klymov in JavaScript.Ninja
И вешаете рефреш в Куку его же
источник

IK

Illya Klymov in JavaScript.Ninja
Дальше вы полученный токе от логин сервера предъявляете любому микросервису
источник

IK

Illya Klymov in JavaScript.Ninja
И он его может проверить не запрашивая логин сервер
источник

IK

Illya Klymov in JavaScript.Ninja
Через общий секретный ключ
источник

VS

Vitaly Sazonov in JavaScript.Ninja
@xanf_ua Илья, скажите, а на вашем курсе по js будете обучать паттернам проектирования и структуре написания кода?
источник

IK

Illya Klymov in JavaScript.Ninja
Vitaly Sazonov
@xanf_ua Илья, скажите, а на вашем курсе по js будете обучать паттернам проектирования и структуре написания кода?
На начальном уровне. Вся ж программа описана
источник

VS

Vitaly Sazonov in JavaScript.Ninja
Illya Klymov
На начальном уровне. Вся ж программа описана
Т.е. только: MVVM и Event-driven architecture?
источник

IK

Illya Klymov in JavaScript.Ninja
Vitaly Sazonov
Т.е. только: MVVM и Event-driven architecture?
Угу
источник

VS

Vitaly Sazonov in JavaScript.Ninja
А паттерны типа синглтон или фабрика это уже относится к продвинутому курсу?
источник

IK

Illya Klymov in JavaScript.Ninja
Vitaly Sazonov
А паттерны типа синглтон или фабрика это уже относится к продвинутому курсу?
А когда вы последний раз ваяли синглтон?
источник

IK

Illya Klymov in JavaScript.Ninja
(важно - не знать что допустим модуль является синглтоном) а именно ваять
источник