massef, неправильный приватный ключ, отсутствие публичного ключа на сервере, не возможность найти сервер по доменному имени, ну или firewall локальный. Или РКН))
maiskiykot, если у вас страницы без контента то их не должно быть в принципе. Одинаковые блоки с внутренними ссылками поисковики все-равно за меню примут, но лучше таки оберните их в
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 протокол. То есть логинит он где-то там, а отдельному сервису позволяет выполнять действия от своего имени (грубо, но все-же). Поэтому то что вы хотите сделать звучит как натуральная дичь
