dimonchik2013, до 2017 у них был hhvm. Проблемы с обратной совместимостью их достали и они планировали использовать Hack - на том же ядре. Так что это всё тот же PHP. Нагрузки, как было заявлено, проблему не вызывали. Нагрузки это вообще никогда тне было про язык программирования - это про инфраструктуру проекта
Александр Вульф, OIDC не про авторизацию. И даже не про аутентификацию. Если вы хотите чтобы в вашу систему зашел пользователь то у него должен быть выбор из систем, которые его аутентифицируют. Его перебрасывает в выбранную систему, там человек заходит, а вам возвращается его токен и базовая информация о пользователе. Дальше вы делаете с этой информацией что хотите.
Тут начинается самое интересное - про ваших партнеров мы тут не знаем ничего. Я предполагаю что у них есть свои системы, которые позволяют заходить через OIDC к ним. Таким образом они - клиент OIDC. И чтобы вам с ними работать вам нужно чтобы они были сервером OIDC. И вам нужно чтобы пользователи заходили к вам через них при возможности.
Есть вариант когда вы можете проводить аутентификацию сервер-сервер, но для этого надо чтобы у партнера было вполне специфическое api. Есть ли оно у них я не знаю
Сергей, если ты делаешь проект для других то тебе нужен сервак. Хотябы на минималках за 5$. Откуда такая тяга нахалявить? 5$ ты даже на фрилансе заработаешь если захочешь.
А если ты делаешь для себя что-то то держи на локали и не парься
VoidVolker, я уже несколько раз порывался) и бросал со словами "да ну нафиг, нет у меня штата индусов под эту задачу". Я за SaaS. А dedicated решения они имеют ряд минусов
Loman1989, во-первых используя OIDC вы пользуетесь Delegation, а не Authentication протоколом. Вам просто передают информацию о пользователе, который захотел залогиниться. Вы уже в конечной системе его регистрируете (при необходимости) и аутентифицируете. Дальше это пользователь отдельной системы.
Если у вас проблемы с тем чтобы сохранить пользователей то туда можно экспортировать старых пользователей с их логинами и паролями и они смогут так же заходить как и раньше. + получите новых, социальных
Александр Вульф, дело в том что вам сторонний сервер ничего не может сказать. Пользователь после аутентификации данные в куки их сервера получает и до них вы не дотянетесь. Редирект вы не сможете, по вам вы ничего не получите. Вы изначально поставили задачу как не решаемую
Andrey, на виртуплке вы не работаете. Работайте себе локально, а результат работы деплойте на сервер. Если вы это не можете делать - бросьте, пожалуйста, то, чем занимаетесь. Ну или скажите заказчикам что вы профан и не умеете в технологии в 2к18
Александр Вульф, тут один из вариантов - либо у вас должна быть возможность залогиниться через партнера, либо наоборот. То есть один из вас подключает другого как способ аутентификации. И да, не забываем что OpenID, в принципе, как и Oauth2 - delegation протокол. То есть логинит он где-то там, а отдельному сервису позволяет выполнять действия от своего имени (грубо, но все-же). Поэтому то что вы хотите сделать звучит как натуральная дичь
Александр Вульф, тогда вам разумно завязаться на OIDC партнера и подключить свой user-pool к ним как опциональный. Иначе вы таких багов потом словите - не оберешься разгребать
Александр Вульф, тогда мне интересно зачем вам система партнера?) Но вообще, технически, вы можете сделать Federated Identity. Обычно его не так используют, но это вполне возможно. В любом случае добавлять себе пользователей из стороннего UsersPool это не очень хорошо.
Для примера. Допустим у вас есть Auth0 + Active Ditectory и VK. Вы же не будете себе новых пользователей в VK в свой домен добавлять? не будете
sim3x, во-первых в счет своего железа идет зарплата сисадмина, который может это настроить. во-вторых свое железо дороже (гарантированно). в-третьих если у вас облако что-то потеряло то виноват в первую очередь не облако (100% никто никому не гарантирует), а тот криворук что не позаботился о правильной кластеризации, репликации данных и все прилагающееся. Это справедливо и для AWS и для Azure, да и для всех остальных облаков тоже. Это IasS платформа, а не магическая коробочка. Ну и на своем железе вы гораздо проще потеряете все данные. Вот и считайте что вам дорого
sim3x, если брать 2 сферических сервера в вакууме - железо и виртуал на одних настройках то железо рулит, но! Во-первых в облаке у тебя всегда кластер в нескольких датацентрах, а во-вторых ты можешь его расширять без геморроя в виде докидывания дисков или установки другого железа. Ах, и да, все вопросы с безопасностью инфраструктуры облако берет на себя. Все апдейты, сервисные окна, доступность в 99.99 и т.д
sim3x, в облаках есть специальные инстансы с повышенным IOPS и вообще с какой угодно конфигурацией. Ты не берешь себе сферический сервер в вакууме, а выбираешь конкретно что тебе требуется. Вот базовая информаци по AWS EC2 instances и RDS. В детали надо углубляться
