В продолжении AngularJS + OIDC

shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

В продолжении AngularJS + OIDC

Post by shadow7256 »

Уважаемые, хотелось бы поднять такую тему, которая давно наболела у нас в компаниии и которую я частично поднял в топике про "AngularJS + OpenID Connect".

Имеется несколько legacy приложений, каждое написано на разной технологии (это важно). И все эти технологии уже стары, как дерьмо мамонта. Какое то приложение написано на AngularJS, какое то на Backbone, какое то на ASP.NET MVC 5, какое то вообще непонятно на какой смеси чего. У каждого приложения есть свой список юзеров, у каждого юзера есть свои Roles, есть свои Permissions. Понятно, что в каждое приложение нужно логинится, потом получать свою Role (Admin, Supervisor, Operator, etc), свои Permissions.

Раньше, когда все работало на старой доброй Forms authentication, то проблем не было. Каждое приложение имело свою базу данных пользователей и весь User management был в каждом приложении отдельно. Потом добавили Windows authentication (через Active Directory), что тоже было не особо проблемно. Потом началось..

Один наш клиент (ну очень большой и серьезный государственный) сказал нам -> Товарищи, мы хотим чтобы ваши приложения делали такую аутентификацию: Каждый наш пользователь имеет CAC (Common Access Card). На этой карте есть Х.509 Client сертификат, в нем прописан Alternate Subject Name. Вот мы хотим, чтобы ваши приложения запрашивали Client certificate, считывали бы Alternate Subject name и потом обращались бы нашей Active Directory и делали поиск по User Principal Name используя то значение из Сертификата. Если юзер есть, то можно логинится.

Мы сделали для них это, но теперь у нас есть отдельный custom source code, который выделен в отдельную ветку.

Потом пришел еще один большой клиент, тоже государство.. и у них видите ли все приложения работают через Okta (Identity Provider). Нужно делать логин через SAML 2.0/OIDC.

Опять для них сделали отдельный custom source code в отдельной ветке и кое как с большим гемором сделали. Как я говорил наши приложения "старые". Просто так там имплементировать современные authentication схемы это ну очень большой геморрой. И дальше будет только хуже.. А что если кто то скажет "А мы хотим multi factor authentictaion".

Поэтому нужно все перекроить. Вопрос как ? На ум приходит, что по любому надо все приложения переписать на более новые технологии, на тот же .NET 7 допустим. Во вторых может как то можно сделать так, чтобы authentication проходил в одном месте, в одном приложении (назовем его Portal), а остальные приложения (когда им нужно authentication) то делали бы редиркет на этот Portal, а этот Portal имел возможность поддерживать разные виды authentication для разных клиентов (типа Plugins).

Как то сумбурно получилось.. но вот так..
tessob
Уже с Приветом
Posts: 576
Joined: 07 Jan 2016 13:04

Re: В продолжении AngularJS + OIDC

Post by tessob »

Если что, то я в оригинальной теме в первом же посте я ответил как это делается не через жопу. Вам это не зашло и вы запилили какой то костыль во фронте. Хотя то, что я описал, позволяет получить идентичную аутентификацию на всех сервисах/приложениях, которые у вас есть.

Что касается авторизации, то роли могут быть проброшены через OIDC токен. С миграцией зоопарка, подобного вашему, на нормальное унифицированное решение обычно проблем тоже не возникало. Хотя, и без жертв не обходилось.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

tessob wrote: 21 May 2023 20:59 Если что, то я в оригинальной теме в первом же посте я ответил как это делается не через жопу. Вам это не зашло и вы запилили какой то костыль во фронте. Хотя то, что я описал, позволяет получить идентичную аутентификацию на всех сервисах/приложениях, которые у вас есть.
я наверное все же не до конца объяснил в чем проблема. Это довольно трудно. Зайдем с другой стороны. Есть два приложения - А и В. Написано на разных технологиях (пока что). Итак..

Клиент 1: Мы хотим чтобы ваши приложения работали c аутентификацей через нашу Active Directory. Ок, мы настроили оба приложения на Windows authentication. Пользователь логинится в приложение А - ему выскакивает стандартное окошко для Windows authentication, он вводит username/password, происходит аутентификация.

Клиент 2: Мы хотим чтобы ваши приложения работали с аутентификацей через нашу Active Directory, но при этом запрашивали Сlient certificate у пользователя, вытаскивали оттуда Subject Alternate Name и потом передавали его в нашу Active directory в качестве User Principal Name. Ок.. мы делаем custom authentication (настраиваем IIS чтобы запрашивал Client certificate, парсим этот сертификат.. и так далее). Опять же кастомная версия продукта.

Клиент 3: Мы хотим чтобы ваши приложения работали с аутенфикацией через наш Identity Provider Service (Okta). Ок.. мы опять делаем третью версия продукта, которое опять имеет сustom authentification.

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

Может быть как то можно это унифицировать.. сделать какое нибудь Приложение С, которое будет заниматься только аутентификацией (будет настраиваться под каждого клиента отдельно), а приложения А и В будут уже обращаться к этому приложению С когда им понадобится залогинить юзера. То есть если приложению А нужно аутентифицировать пользователя, то оно сделает редирект на приложение С, там будет аутентификация и потом обратно все вернется в приложение А (с claims и все такое).
tessob wrote: 21 May 2023 20:59 С миграцией зоопарка, подобного вашему, на нормальное унифицированное решение обычно проблем тоже не возникало. Хотя, и без жертв не обходилось.
мне кажется, что если весь этот зоопарк перевести на одну технологию, то много проблем бы решилось.
User avatar
KVA
Уже с Приветом
Posts: 5382
Joined: 03 Feb 1999 10:01
Location: NJ, USA

Re: В продолжении AngularJS + OIDC

Post by KVA »

У вас muli-tenant application или для каждого клиента устанавливаете свой instance?

Я не понимаю почему вы все время говорите "имеем кучу разных версий продукта". По идее только маленький кусочек аппликух разный (ответственный за аутентификацию) и в принципе просто указывается в конфигурации какую аутентификацию применять в какому клиенту. А количество вариантов аутентификации будет в итоге конечным. :)
tessob
Уже с Приветом
Posts: 576
Joined: 07 Jan 2016 13:04

Re: В продолжении AngularJS + OIDC

Post by tessob »

shadow7256 wrote: 22 May 2023 02:00Есть два приложения - А и В... И так далее.. в итоге имеем кучу разных версий продукта, который делает одно и тоже, но отличается только authentication flow.
Может быть сколько угодно AD. Вообще ноль проблем. У меня на недавнем проекте несколько десятков клиентов имели практически весь возможный зоопарк идентити провайдеров: AD, Google, Github, Auth0, etc. Аутентификация в общее облако для всех отрабатывала идентично, рассылая всех в своему IdP.
shadow7256 wrote: 22 May 2023 02:00мне кажется, что если весь этот зоопарк перевести на одну технологию, то много проблем бы решилось.
У вас проблема не в технологиях, а в тех кто их применяет -- в инженерах. У меня на всех последних проектах по несколько языков (Java, Rust, Go, Python) т.к. найти толпу народа на общий стек не всегда возможно и это не особо нужно. Вообще никаких проблем нет.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

KVA wrote: 22 May 2023 02:35 У вас muli-tenant application или для каждого клиента устанавливаете свой instance?
У нас есть Core версия продукта, со своими релизами. Ее используют довольно много клиентов, которые не требуют танцев с бубнами. Их вполне устраивает либо стандартная Forms authentication или Windows authentication. В обоих случаях authentication настраивается минимальными изменениями в конфиг файле (в том же самом web.config) и в самом коде, если нужно получить доступ к User, то просто вызывается HttpContext.Current.User.
KVA wrote: 22 May 2023 02:35 Я не понимаю почему вы все время говорите "имеем кучу разных версий продукта". По идее только маленький кусочек аппликух разный (ответственный за аутентификацию) и в принципе просто указывается в конфигурации какую аутентификацию применять в какому клиенту. А количество вариантов аутентификации будет в итоге конечным. :)
Ну не совсем прямо "куча" конечно, но есть две-три версии продукта, которые заточены под конкретного заказчика. Вот простой пример. Армия США.

У них весь доступ к компутерам идет через CAC (Common Access Card). На этой карточке находится X.509 сертификат обычный, в котором зашита информация о юзере. Его логин (для Active Directory) и прочее. То есть когда юзер логинится в компьютер, то заместо того чтобы вводить username/password он просто вставляет эту карту в считыватель и система уже делает все остальное. Ну так вот. Они нам сказали, что они хотят наше приложение тоже считывало информацию с этой карты, а имеено вытаскивало конкретное поле из карты (Subject Alternate Name) и определенным образом его парсило, чтобы добыть злополучный username. И потом обращалось к Active Directory и аутентифицировало этот username (и искало пользователя в Active Directory через User Principal Name, а не через SAM Account name). Как видите здесь мы имеем дело не с обычной Forms или Windows authentication. Тут надо во первых настроить IIS чтобы он запрашивал Client certificate (не проблема), потом вручную перехватить HTTP запрос к приложению, вытащить сертификат, вытащить username и вручную обратиться к Active Directory и аутентифицировать пользователя. Как видите здесь код приложения уже должен знать, что в данном случае клиент использует Client certificate в запросе и нужно его обрабатывать особым образом. Опять же простой настройкой в конфигурации здесь не обойтись.

Вариантов аутентификации конечно, это да. Но принцип их работы разный. Вот сейчас другой клиент захотел использовать SAML 2.0/OIDC. Это уже token based authentication, и там все идет через Claims. И в коде уже просто так нельзя обратиться к юзеру через HttpContext.Current.User, потому что он будет NULL. Нужно работать с ClaimsPrincipal. Опять же пришлось подкручивать приложение для этого клиента.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

tessob wrote: 22 May 2023 09:39 Может быть сколько угодно AD. Вообще ноль проблем. У меня на недавнем проекте несколько десятков клиентов имели практически весь возможный зоопарк идентити провайдеров: AD, Google, Github, Auth0, etc. Аутентификация в общее облако для всех отрабатывала идентично, рассылая всех в своему IdP.
Ну вот видите, вы работаете с набором стандартных Identity Providers. они могут быть разными да. Но все они работают по одной принципу - SAML 2.0/OIDC. То бишь claims based authentication/tokens и все такое. В данном случае конечно неважно с каким провайдером работать, просто параметры RedirectURL и ClientID поменял да и все.

Но я же говорю про то, что у нас виды самой аутентификации могут быть разными - от cookie based Forms authentication, до Claim based authentication. А если сейчас придет клиент и скажет "я хочу Multi factor authentication".. то опять под него подкручивать приложение надо.
tessob wrote: 22 May 2023 09:39 У вас проблема не в технологиях, а в тех кто их применяет -- в инженерах. У меня на всех последних проектах по несколько языков (Java, Rust, Go, Python) т.к. найти толпу народа на общий стек не всегда возможно и это не особо нужно. Вообще никаких проблем нет.
все таки устаревшие технологии приносят много геморроя, когда нужно использовать какие то новые методы решения проблемы.
tessob
Уже с Приветом
Posts: 576
Joined: 07 Jan 2016 13:04

Re: В продолжении AngularJS + OIDC

Post by tessob »

shadow7256 wrote: 22 May 2023 13:23Ну вот видите, вы работаете с набором стандартных Identity Providers ... просто параметры RedirectURL и ClientID поменял да и все.
Да, среди нас не было мазохистов, они отсеялись и покинули проект/компанию в первые недели. Тем клиентам, у которых была какая-то экзотическая фигня, было предложено взять себе Cognito или Auth0 и настраивать там федерацию по своему вкусу. Как вариант мы могли порекомендовать тех, кто это сделает для них. Когнито вроде даже федерацию с керберос и прочими технологиями из раннего палеолита поддерживает.
shadow7256 wrote: 22 May 2023 13:23А если сейчас придет клиент и скажет "я хочу Multi factor authentication".. то опять под него подкручивать приложение надо.
Нет, не надо. MFA это функция на стороне идентити провайдера, так же как и другие челленджи. В облако должен просто приходить валидный токен, как он получен меня не волнует.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

tessob wrote: 22 May 2023 13:42 Тем клиентам, у которых была какая-то экзотическая фигня, было предложено взять себе
ну значит Вам повезло не работать с теми клиентам у которых "экзотическая" фигня :-) Один из наших клиентов - US Army (и куча ее подразделений, Navy, Air Force, etc). Вот у них как раз эта фигня с Client Certificate + Active Directory. Попробуйте им "предложить взять себе". :D Там либо так.. либо никак. Другого не дано.

Но одно радует, там хоть ребята технически толковые работают с их стороны.
tessob wrote: 22 May 2023 13:42 В облако должен просто приходить валидный токен, как он получен меня не волнует.
Вы постоянно твердите про "облако". У нас проблема не с облаком :-)
tessob
Уже с Приветом
Posts: 576
Joined: 07 Jan 2016 13:04

Re: В продолжении AngularJS + OIDC

Post by tessob »

shadow7256 wrote: 22 May 2023 14:05Один из наших клиентов - US Army (и куча ее подразделений, Navy, Air Force, etc).
Напишите отдельный прокси под это дело, если вам так важен этот клиент. Причем это можно сделать как вместо ALB, так и за ALB.
shadow7256 wrote: 22 May 2023 14:05Вы постоянно твердите про "облако". У нас проблема не с облаком :-)
Для меня "облако" -- это универсальное обобщение. Я понятия не имею где вы деплоитесь, но думаю, что там ситуация не лучше, чем с аутентификацией.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

tessob wrote: 22 May 2023 15:22 Напишите отдельный прокси под это дело, если вам так важен этот клиент.
Важен ? :-) :-) Это самый крупный наш заказчик. Вот собственно мы и подошли к той проблеме, о которой я твержу. Для разных клиентов надо писать разные "прокси". В зависимости от того, как клиент делает аутентификацию.

А вот что если сделать как то так.

Перевести все наши приложения строго на token based authentication. Ну то есть пусть они работают строго с JWT допустим, где будет передаваться username, его roles и все что надо. Потом сделать один общий Портал приложения для логина (сейчас уже что то подобное есть). И уже этот Портал будет работать (настраиваться) на ту аутентификацию, которую надо клиенту. Тогда все другие приложения, если видят что юзер не authenticated, будут направлять его на этот Портал. Портал уже заставит его залогинится (Forms, Windows, SAML или еще как то), потом создаст JWT и вернет его обратно в приложение но уже с токеном. Приложение отпарсит токен и установит все необходимые Claims и будет работать дальше. В этом случае приложениям пофиг как там клиент себе сделал authentication, приложения будут работать только с JWT и все.
tessob wrote: 22 May 2023 15:22 Для меня "облако" -- это универсальное обобщение. Я понятия не имею где вы деплоитесь, но думаю, что там ситуация не лучше, чем с аутентификацией.
насчет облака это вообще песня. Сейчас все кому не лень пихают свои аппликухи в облако (AWS, Azure) при этом понятия не имеют, а надо ли это вообще. Реальный пример опять у нас. Есть другой крупный гос. заказчик. Тоже решили запихать наше приложение в облако. Но весь цимес в том, что наше приложение должно посылать данные в спец. организацию, которая будет заниматься обработкой данных. Эта спец. организация это не наш выбор - это выбор заказчика. Но вот в чем беда. Эта спец организация просто так не позволит присылать им данные откуда угодно. Нужно с этой организацией установить IPSec канал защищенный. И эта организация строго следит откуда эти защищенные каналы создаются.

Ну так вот.. этот заказчик засунул приложение в облако, но при этом создать защищенный канал из этого облака со спец. организацией у них никак не получается. Это не касается нашего приложения. Это чисто IPSec канал между "облаком" заказчика и спец организацией. Мы спрашиваем а нафига вы вообще сунули приложение в облако ? Ну как нафига.. все суют.. ну и мы суем. Так модно.
Ну раз так модно для вас, то вот сейчас мудохайтесь с этим каналом сами.
tessob
Уже с Приветом
Posts: 576
Joined: 07 Jan 2016 13:04

Re: В продолжении AngularJS + OIDC

Post by tessob »

shadow7256 wrote: 22 May 2023 15:57Нужно с этой организацией установить IPSec канал защищенный.
Вас никто ни в чем не ограничивает. В AWS вроде была аппаратная поддержка IPSec и это можно делать с фиксированного IP.

Я прекрасно понимаю, что при должном уровне развития воображения, подкрепленном диссоциативами/психоделиками, любая тривиальная проблема может стать неразрешимой.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

tessob wrote: 22 May 2023 17:49 Вас никто ни в чем не ограничивает. В AWS вроде была аппаратная поддержка IPSec и это можно делать с фиксированного IP.
вообще то это не наша проблема. Это чисто между заказчиком и его спец. организацией, которая обрабатывает информацию от заказчика. Это разве мы решили засунуть приложение в облако ? Нашему приложению насрать на все эти IPSec, этим пусть сам заказчик и занимается. Или мы должны еще и жопу вытирать за ними ?
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: В продолжении AngularJS + OIDC

Post by zVlad »

Ошибка в том что такие вопросы как верификация и авторизация решаются на уровне приложения. Это должно делаться в службе ОС.
Но ни Виндовс ни Линукс не имеют этих служб, а то что имеется примитивно и не удовлеторяет требованиям приложений.
Вот и появляются разные самоделки. Со всеми вытекающими последствиями.
В zOS такая служба есть и все нормальные приложения ее использует. Принципы работы службы просты как умывальник и их можно имплеминтировать в любой другой ОС. Но видимо этого нет коль скоро такая тема на форуме вновь и вновь поднимается.

Я лет десять назад упражнялся с разными способами аутентификации через RACF. И с токенами, и с сертификатами. Все это исполнялось через "портал", т.е. RACF. А приложения лишь обращались к RACF за этим.
Должен ли это быть Active Directory я не знаю, не так уж знаклм с AD. Может быть.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

zVlad wrote: 23 May 2023 16:37 Все это исполнялось через "портал", т.е. RACF. А приложения лишь обращались к RACF за этим.
Ну вот об этом мы и думаем сейчас. Скорее всего придется имплементировать самопальный Портал какой нибудь.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: В продолжении AngularJS + OIDC

Post by zVlad »

shadow7256 wrote: 22 May 2023 17:55
tessob wrote: 22 May 2023 17:49 Вас никто ни в чем не ограничивает. В AWS вроде была аппаратная поддержка IPSec и это можно делать с фиксированного IP.
вообще то это не наша проблема. Это чисто между заказчиком и его спец. организацией, которая обрабатывает информацию от заказчика. Это разве мы решили засунуть приложение в облако ? Нашему приложению насрать на все эти IPSec, этим пусть сам заказчик и занимается. Или мы должны еще и жопу вытирать за ними ?
И это правильно. Для IPSec во вне облака нужны статические адреса. Наверное они стоят денег поэтому проблема. Других вроде не должно быть.
Я с IPSec занимался, но это было до перехода в облака. Внутри облака тоже нет проблем там все адреса статические между собой, а вот во вне видимо идут через DNS и меняются по хотению облака.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

zVlad wrote: 24 May 2023 03:35
shadow7256 wrote: 22 May 2023 17:55
tessob wrote: 22 May 2023 17:49 Вас никто ни в чем не ограничивает. В AWS вроде была аппаратная поддержка IPSec и это можно делать с фиксированного IP.
вообще то это не наша проблема. Это чисто между заказчиком и его спец. организацией, которая обрабатывает информацию от заказчика. Это разве мы решили засунуть приложение в облако ? Нашему приложению насрать на все эти IPSec, этим пусть сам заказчик и занимается. Или мы должны еще и жопу вытирать за ними ?
И это правильно. Для IPSec во вне облака нужны статические адреса. Наверное они стоят денег поэтому проблема. Других вроде не должно быть.
Я с IPSec занимался, но это было до перехода в облака. Внутри облака тоже нет проблем там все адреса статические между собой, а вот во вне видимо идут через DNS и меняются по хотению облака.
Я честно говоря уж сильно врать не хочу насчет IPSec, я в этом не специалист, но я точно знаю, что спец. организация (а именно OPM, Office of Personel Management, у нас много кто из клиентов туда шлют информацию) требует наличие безопасного канала для передачи данных. Типа VPN. А уж детали этого канала мне неизвестны, IPSec или еще какой протокол для этого используется.

ну так вот когда клиент установил наше приложение (новую версию) на их собственные сервера (у них уже давно есть канал этот между их серверами и серверами OPM), то все работает прекрасно. Но как только установили приложение в облако, то приложение перестало посылать данные на сервера OPM. Естественно тут же начали сыпаться обвинения, что наше приложение ни хрена не работает, что не посылает данные агенству и чтобы мы срочно чинили нашу аппликуху.

Божечки, сколько раз (миллион наверное) мы слышали уже эту фразу "Ваше приложение не работает, это ваша вина, чините приложение срочно и как можно быстрее". Ну мы и спросили в ответ - а канал то вы установили защищенный между вашими серверами в облаке и ОРМ ? Тут же языки в жопу засунули и сказали "мы с этим разбираемся, но пока никак". :-)
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: В продолжении AngularJS + OIDC

Post by zVlad »

shadow7256 wrote: 24 May 2023 13:28
zVlad wrote: 24 May 2023 03:35
shadow7256 wrote: 22 May 2023 17:55
tessob wrote: 22 May 2023 17:49 Вас никто ни в чем не ограничивает. В AWS вроде была аппаратная поддержка IPSec и это можно делать с фиксированного IP.
вообще то это не наша проблема. Это чисто между заказчиком и его спец. организацией, которая обрабатывает информацию от заказчика. Это разве мы решили засунуть приложение в облако ? Нашему приложению насрать на все эти IPSec, этим пусть сам заказчик и занимается. Или мы должны еще и жопу вытирать за ними ?
И это правильно. Для IPSec во вне облака нужны статические адреса. Наверное они стоят денег поэтому проблема. Других вроде не должно быть.
Я с IPSec занимался, но это было до перехода в облака. Внутри облака тоже нет проблем там все адреса статические между собой, а вот во вне видимо идут через DNS и меняются по хотению облака.
Я честно говоря уж сильно врать не хочу насчет IPSec, я в этом не специалист, но я точно знаю, что спец. организация (а именно OPM, Office of Personel Management, у нас много кто из клиентов туда шлют информацию) требует наличие безопасного канала для передачи данных. Типа VPN. А уж детали этого канала мне неизвестны, IPSec или еще какой протокол для этого используется.

ну так вот когда клиент установил наше приложение (новую версию) на их собственные сервера (у них уже давно есть канал этот между их серверами и серверами OPM), то все работает прекрасно. Но как только установили приложение в облако, то приложение перестало посылать данные на сервера OPM. Естественно тут же начали сыпаться обвинения, что наше приложение ни хрена не работает, что не посылает данные агенству и чтобы мы срочно чинили нашу аппликуху.

Божечки, сколько раз (миллион наверное) мы слышали уже эту фразу "Ваше приложение не работает, это ваша вина, чините приложение срочно и как можно быстрее". Ну мы и спросили в ответ - а канал то вы установили защищенный между вашими серверами в облаке и ОРМ ? Тут же языки в жопу засунули и сказали "мы с этим разбираемся, но пока никак". :-)
IPSec включает в себя VPN. VPN это когда конечная точка шифрования не совпадает с конечной точкой соединения. Иначе говоря шифрованный туннель с VPN заканчивает на входе в прайвет сеть.
IPSec по определению прозрачен для приложений. Проблемы IPSec элементарно решаются просмотром syslogd журнала и изменением полиси под имеющуюся конфигурацию. В облаке это надо делать совместно с облачниками.
Вас обвиняют совершенно необоснованно. Я бы плюнул в глаза таким клиентам.
Ну а с другой стороны почему бы вам не приобрести компетенции с IPSec и не решить проблему? А потом объяснить что и как. Это помогло бы вам очень в отношении с клиентом. Ваш авторитет поднялся бы до небес.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

zVlad wrote: 24 May 2023 14:15 Вас обвиняют совершенно необоснованно.
Знаете сколько раз такое было :-) Мы уже привыкли. Особенно умиляют ситуации, когда мы поставили наш продукт, все настроили. Все работает как часы. Проходит 5-6 месяцев и звонят в наш саппорт и начинают истерить - Ваш продукт перестал работать! Срочно бросайте все и срочно чините ваше приложение. У нас production down.

Наша первая реакция - были ли какие то апдейты нашего продукта (это мы легко узнаем у наших сотрудников) ? Нет не было.

Второй вопрос (уже клиенту) - что изменилось у вас ? Что поставили на сервер ? что изменили в сетевой конфигурации ? Короче what changed ?
Ответ от них обычно сразу один и тот же - Мамой клянусь ничего не менялось. Nothing changed. Это ваше приложение поломалось (ни с того ни с сего да?) и не работает и вообще вы виноваты.

Поднимаем логи нашего приложения - приложение не может соединится с удаленным FTP сервером, чтобы отослать данные (как пример). Показываем логи клиенту, тыкаем пальцем -
видите ? только после этого клиент начинает шевелиццо, звонить в IT и вообще самостоятельно делать какие то движения. Потом оказывается, что прошлой ночью их IT отдел накатил какие то внутренние апдейты непонятные, в итоге там все переконфигурировалось в сети и нахрен поломалось. После этого клиент утирает дерьмо с лица и замолкает.
zVlad wrote: 24 May 2023 14:15 Я бы плюнул в глаза таким клиентам.
ну плевать необязательно конечно, но один раз я открыто нах..й послал одних таких, которые возомнили себя непонятно кем и вели себя так, как будто мы им должны по самое небалуйся и вообще в ноги им обязаны кланятся и выполнять любое их желание по щелчку.
zVlad wrote: 24 May 2023 14:15 Ну а с другой стороны почему бы вам не приобрести компетенции с IPSec и не решить проблему? А потом объяснить что и как. Это помогло бы вам очень в отношении с клиентом. Ваш авторитет поднялся бы до небес.
За много лет работы со многими клиентами (и маленькими и огромными) мы поняли одну вещь - большинство клиентов хотят получить побольше и самое главное бесплатно. Мы работали(ем) с разными клиентами и есть те, у которых проблемы допустим и которые готовы работать вместе и решать их вместе сообща. Тут без вопросов, всегда приятно поработать (пусть даже над какой то темой, которая нас вообще не касается и которую мы не обязаны выполнять) что то узнать из новой области и потом уже со след клиентом учитывать прошлый опыт.

но часто бывает так, что с клиентом обговариваются все детали проекта до мелочей. Все согласовано и сделано согласно документации. И в последний момент появлятся на горизонте какое нибудь чмо, но чмо высокого уровня и говорит "Я хочу, чтобы было сделано вот так вот и было сделано вчера". Ему говорят "этого не было в документации, это вообще потребует дополнительных усилий серьезных и вообще из другой темы". На что чмо отвечает "Your software does not meet my expectaions. I am disappointed. ". Чувствуете ? MY expecations. Ну в итоге часто бывает, что приходится (как вот в этом случае с SAML.. о котором речи вообще не было изначально и нам было сказано, что все будет работать через Active Directory, а за неделю до сдачи проекта заказчику появилось с их стороны такое мурло и сказало, что нужно чтобы все работало через SAML и причем работало все в срок сдачи). А потом когда мы все таки сделали и поставили продукт, то оказалось, что и про облако речи изначально не было и когда оказалось, что они в облако засунули продукт, а у них не работает, то сказали, что это проблемы нашего продукта и чтобы мы сами с этим разбирались.

Тут еще проблема нашего менеджменета. Они слишком мягкие и тупо соглашаются на все (или почти все) претензии клиента (обоснованые или нет) и потом бегут к нам и просят решить их за 15 секунд.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: В продолжении AngularJS + OIDC

Post by zVlad »

shadow7256 wrote: 24 May 2023 17:26
zVlad wrote: 24 May 2023 14:15 Вас обвиняют совершенно необоснованно.
Знаете сколько раз такое было :-) .....
Я имел в виду ситуацию с IPSec. Вообще, как профессионал, я стараюсь не судить и не высказываться о том с чем не имею дела.
Все что Вы написали знакомо до мелочей. Могу сказать на собственном опыте что в системах на Виндовс и Линукс очень плохая, запутанная диагностика, очень не стабильная обстановка, болезненно чувствительная к апгрейдам системы и вообще любым шевелениям в истемах, серверах. Облачные технологии лишь добавляют свои проблемы.
Из моего опыта работы со стороны клиента приложения. Большое бизнес приложение. Разработчик требует таких и таких версий операционки, бд и тд. Наши программисты трясутся, хватают меня за руки, не делай апгрэйды ос, бд. Несколько раз мне удалось сделать по своему. Все было ок. Потом я плюнул на это все. В системе где я работаю диагностика такова что можно всегда и легко доказать что является источником проблемы, системные дела (никто не застрахован полностью) или приложение. И соответственно поправить или систему или приложение
Другой пример. Я являюсь как бы пользователем приложения - репликации. У нас есть доступ к саппорту. Я сто раз проверю не в нас ли причина, соберу всю диагностику и лишь потом обращусь в саппорт. Мне говорят звони в саппорт. Если я не уверен что дело в приложении отвечаю нет, ее буду звонить, не хочу позориться.

На разных разных платформах складываются разные системы отношений клиентов, разработчиков, саппорта. Это все от свойств платформ исходит. Они очень разные.
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

zVlad wrote: 24 May 2023 18:25 ее буду звонить, не хочу позориться.
Если бы все клиенты придерживались такой политики, то жизнь стала бы намного легче.
null
Уже с Приветом
Posts: 2983
Joined: 09 Jul 2001 09:01

Re: В продолжении AngularJS + OIDC

Post by null »

shadow7256 wrote: 24 May 2023 17:26 Поднимаем логи нашего приложения - приложение не может соединится с удаленным FTP сервером, чтобы отослать данные (как пример). Показываем логи клиенту, тыкаем пальцем -
видите ? только после этого клиент начинает шевелиццо, звонить в IT и вообще самостоятельно делать какие то движения. Потом оказывается, что прошлой ночью их IT отдел накатил какие то внутренние апдейты непонятные, в итоге там все переконфигурировалось в сети и нахрен поломалось. После этого клиент утирает дерьмо с лица и замолкает.
ничего он не утирает
кто-то на месте выиграл время, попользовал вас как дебагера и забыл
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

null wrote: 24 May 2023 21:19
shadow7256 wrote: 24 May 2023 17:26 Поднимаем логи нашего приложения - приложение не может соединится с удаленным FTP сервером, чтобы отослать данные (как пример). Показываем логи клиенту, тыкаем пальцем -
видите ? только после этого клиент начинает шевелиццо, звонить в IT и вообще самостоятельно делать какие то движения. Потом оказывается, что прошлой ночью их IT отдел накатил какие то внутренние апдейты непонятные, в итоге там все переконфигурировалось в сети и нахрен поломалось. После этого клиент утирает дерьмо с лица и замолкает.
ничего он не утирает
кто-то на месте выиграл время, попользовал вас как дебагера и забыл
эк Вас задела эта фраза то. Неужели звоните по каждой мелочи в саппорт?

"Дебагеры" как раз это те, кто звонят нам и плачут. Ну им инструкции и высылаем как "поднять логи" и выслать нам. Справятся за час уже хорошо, нет - не наши проблемы. Потом логи рассмотрим и ткнем рылом куда нужно им смотреть дальше (все таки Maintanance контракт у них подписан, они имееют право жаловаться). А уже кто какое время выиграл тут непонятно.
null
Уже с Приветом
Posts: 2983
Joined: 09 Jul 2001 09:01

Re: В продолжении AngularJS + OIDC

Post by null »

shadow7256 wrote: 24 May 2023 22:53
null wrote: 24 May 2023 21:19
shadow7256 wrote: 24 May 2023 17:26 Поднимаем логи нашего приложения - приложение не может соединится с удаленным FTP сервером, чтобы отослать данные (как пример). Показываем логи клиенту, тыкаем пальцем -
видите ? только после этого клиент начинает шевелиццо, звонить в IT и вообще самостоятельно делать какие то движения. Потом оказывается, что прошлой ночью их IT отдел накатил какие то внутренние апдейты непонятные, в итоге там все переконфигурировалось в сети и нахрен поломалось. После этого клиент утирает дерьмо с лица и замолкает.
ничего он не утирает
кто-то на месте выиграл время, попользовал вас как дебагера и забыл
эк Вас задела эта фраза то. Неужели звоните по каждой мелочи в саппорт?

"Дебагеры" как раз это те, кто звонят нам и плачут. Ну им инструкции и высылаем как "поднять логи" и выслать нам. Справятся за час уже хорошо, нет - не наши проблемы. Потом логи рассмотрим и ткнем рылом куда нужно им смотреть дальше (все таки Maintanance контракт у них подписан, они имееют право жаловаться). А уже кто какое время выиграл тут непонятно.
я был по обе стороны и понял что хоть и круто доказать и аргументировано ткнуть носом "вы сами тупые дураки потому-то и потому-то", гораздо комфортнее послать еmail вендору "что-то у вас тут сломалось" и уйти в 5 домой, а в 9 на следущий день спросить "какой там у вас прогресс?"
shadow7256
Уже с Приветом
Posts: 10589
Joined: 18 Mar 2004 15:11
Location: New York -> FL

Re: В продолжении AngularJS + OIDC

Post by shadow7256 »

null wrote: 25 May 2023 14:57
shadow7256 wrote: 24 May 2023 22:53
null wrote: 24 May 2023 21:19
shadow7256 wrote: 24 May 2023 17:26 Поднимаем логи нашего приложения - приложение не может соединится с удаленным FTP сервером, чтобы отослать данные (как пример). Показываем логи клиенту, тыкаем пальцем -
видите ? только после этого клиент начинает шевелиццо, звонить в IT и вообще самостоятельно делать какие то движения. Потом оказывается, что прошлой ночью их IT отдел накатил какие то внутренние апдейты непонятные, в итоге там все переконфигурировалось в сети и нахрен поломалось. После этого клиент утирает дерьмо с лица и замолкает.
ничего он не утирает
кто-то на месте выиграл время, попользовал вас как дебагера и забыл
эк Вас задела эта фраза то. Неужели звоните по каждой мелочи в саппорт?

"Дебагеры" как раз это те, кто звонят нам и плачут. Ну им инструкции и высылаем как "поднять логи" и выслать нам. Справятся за час уже хорошо, нет - не наши проблемы. Потом логи рассмотрим и ткнем рылом куда нужно им смотреть дальше (все таки Maintanance контракт у них подписан, они имееют право жаловаться). А уже кто какое время выиграл тут непонятно.
я был по обе стороны и понял что хоть и круто доказать и аргументировано ткнуть носом "вы сами тупые дураки потому-то и потому-то", гораздо комфортнее послать еmail вендору "что-то у вас тут сломалось" и уйти в 5 домой, а в 9 на следущий день спросить "какой там у вас прогресс?"
Мы не пытаемся никому доказать ничего. Если нам придет емейл в 5 часов, в котором написано "у вас там сломалось что то", то скорее всего никакого ответа такой "заказчик" не получит. А если и получит, то типа "когда предоставите полную информацию о проблеме, тогда и будем разговаривать". А проблемы типа "что то сломалось" чините сами. Если будут вопросы дальше "какой прогресс", то опять же скорее всего ответа не будет. А если и будет то "никакого прогресса". Выеживайтесь дальше. Принцип простой - какой вопрос такой и ответ.

Особо умные пытаются пугать типа "we will escalate this issue" намекая, что будут жаловаццо наверное высшему начальству :-) Да, жаловались много раз. Мы показывали начальству какие эти умники письма шлют ну вот как раз типа "у вас что то сломалось". Начальство тихонько смеется над этим только. А эти же умники пытаются жаловаться своему начальству вот типа у этих поломалось, а они ничего не делают. Их начальство угрожает нашему, мы выкладываем всем сторонам в открытую переписку между теми умниками которые в "5 часов" и нашими. После этого почему то те умники сразу же больше не умники и как шелковые начинают шевелить свои жопы и чинить сами же свои проблемы.

Return to “Вопросы и новости IT”