Ну, честно говоря, они все же не так написали, как вы интерпретируете. Они написали "может быть хорошим вариантом" - значит может и не быть. Мне в таком совете не нравится совсем другое - они нихрена не учитывают стоимость самой миграции. Которая легко может стоить значительно больше этих вот $30 (в год), потому что это зарплата специалиста за пару дней максимум. А я не верю, что миграция не приведет к потере в итоге хотя бы пары дней там и сям, даже если пройдет гладко.
Именно это вы и не продемонстрировали. Вы пытались применить все принципы к коду, который весьма вероятно не требовал применения ни одного. А если и требовал - то вы этого не показали, а сразу начали "применять". Если вы именно это хотели показать - у вас получилось так себе.
какую проблему она решает
Вот именно. Я допускаю, что я невнимательно что-то читал, если так - ткните пальцем, где вы описали, какие проблемы были в вашем примере кода до применения принципов?
Давайте применим к этой структуре все принципы SOLID.
Вот после этого места уже можно не читать. Давайте применим... зачем? Вы даже не соизволили сформулировать цель применения.
SOLID не самоцель, это инструмент. Инструмент для улучшения некоторых показателей кода. У вас показатели были плохие? Какие именно?
А если вы не знаете, чего хотели - вот ровно это непонятно что вы и получили в итоге.
Я исхожу из того, что вы применяли принципы просто "чтоб было". С поправкой на то, что это учебная статья, вы разумеется можете показать игрушечный код, но "давайте применим все принципы" - это все равно за пределами разумного. И кстати, достижение low coupling тоже не самоцель, связность кода - это просто показатель, который полезно измерять, и который в текущем (исходном состоянии) вас вполне может устраивать.
Иными словами - если код уже достаточно хорош, сопровождается и развивается сравнительно легко, понимается (текущей командой проекта) без проблем - нахрена его ломать и пытаться "улучшить" непонятно что?
Примерах? Да тут примеры вообще ничего не показывают...
Обнаружилось, что при большом количестве значений скорость запроса сильно падает, если используется IN.
Во-первых, вот это утверждение само следовало бы подтвердить измерениями. Потому что строго говоря, на число значений в IN есть практический лимит (пусть даже не в СУБД, так в JDBC драйвере, например), т.е. померять следовало бы хотя бы 1, 10, 100, 1000 и 100000 значений в IN. Кроме того, "обнаружилось" что c IN (1, 2, 3, ...) всегда работает быстро, если в колонке c всегда 1 (и я тоже не буду это доказывать - если это не так, это баг). Т.е. вот это вот "скорость сильно падает" зависит еще и от распределения значений в колонке слева от IN.
А дальше следует пример с двумя значениями в IN, и двумя значениями в VALUES, и при этом разницы в быстродействии мы практически не видим, т.е. она на грани погрешности измерения (и как вы уже отметили, кост в плане - не показатель вообще).
Ну в том стандарте ничего не написано про то, что приложение идет в комплекте. Я вам же точную цитату привел - авторы стандарта считают таковыми приложения, где сервер авторизации и приложение - единое целое. И "user understands them both as the same entity". Ну т.е. тут подчеркивается, что юзер должен понимать, что это одна компания.
Вот не очевидно. СберИд это тоже платформа, и если посмотреть в предлагаемый вами стандарт, то там написано так:
This specification MUST only be used by first-party applications, which is when the authorization server and application are operated by the same entity and the user understands them both as the same entity.
Т.е. сервер авторизации и приложение управляются Сбером? Значит Сбербанк Онлайн это first-party application, почему нет-то? Тут про ОС и предустановку ничего не написано (хотя ваши мысли что тут риска меньше, я вполне понимаю).
Я понял, о чем вы. Практически согласен, кроме одного - вы говорите о стандарте, который не предназначен для first party apps. А стандарт для них - в драфте. И мне лично не очевидно, почему применение стандарта для приложений, к которым он (условно) не подходит, лучше в принципе, чем отступление от него. Да, отступление - это риски (которые надо анализировать конкретно). Да, это учит пользователей нехорошему - согласен.
Даже если это и правда, то так делать, как Сбер, категорически неверно.
Вы предлагаете отдельное окно, и считаете это критически важным? Ну ок, допустим - только я не улавливаю, почему пользователь, который не может отличить фейковое приложение банка от настоящего не перепутает точно так же фейковое окно браузера с настоящим?
P.S. По сути, вот ниже уже сформулировали мой вопрос иными словами:
если мы не доверяем приложению, то почему мы должны доверять контенту "браузерного окна", которое оно открывает?
Ну т.е. исходные данные для меня простые - я доверяю своему банку деньги. И я доверяю его приложению (хотя разумеется, допускаю, что там могут быть баги). И когда я ставлю это приложение, я убеждаюсь дважды, что оно настоящее. В противном же случая я не вижу разницы. Если вы видите - поясните, в чем она?
Удивительно, что такой проблемой страдают, наверное, все отечественные банки, где процесс авторизации идет исключительно в мобильном приложении.
Погодите. С чего вы решили, что при входе в приложение банка я доверяю google.com, которому одновременно доверяет и банк? В приложение Сбер/Тиньков можно войти по кредам гугля? И давно ли?
В моем понимании, Сбер скажем использует Oauth не когда вы входите в Сбербанк Онлайн, а когда вы входите куда-то по СберID, т.е. именно сервис Сбера и является тем, кто аутентифицирует пользователя. Т.е. например, при входе по СберID в megamarket.ru, ну или там Купер и т.п. .
Им по-моему до прототипа как до Луны пешком. Более того, у них запись в ячейку значений 0..2 это в четыре раза больше, чем при двоичном кодировании, когда значения 0..1. Т.е. у них три - в четыре раза больше двух, прикиньте?
У меня так девелопер делал свой template engine, с кучей кода на java. В итоге переписал на xdocreport - осталось буквально 5 строк.
Вы не один. У меня тоже делал в 2013 году. Месяц возился, словил все те же проблемы (ну почти) что и автор данной статьи, но так и недоделал. В итоге тоже выбросили, взяли готовое решение (которое существует где-то с 2006 года), и внедрили за день.
И что характерно, на дворе конец 2024, а люди все еще берутся реализовывать все тоже самое, что уже было реализовано 20 лет назад.
Каким образом старый пароль будет использоваться после ротации ?
Считайте что любым. Что он в памяти где-то у приложения лежит.
Иначе остается короткое окно когда мы уже инициировали ротацию, но еще не обновили секрет в Hikari
Ну т.е. на самом деле я вот про это и говорил - что одного Vault тут недостаточно, сротированный/ротируемый пароль нужно правильно распространять в распределенной среде, и у этой задачи есть много решений, среди которых много неправильных. Причем неправильных как реализаций, так и спецификаций - потому что скажем спецификация DataSource в общем-то не предполагает динамической ротации пароля, это за пределами ее скоупа на момент создания. Так же как Tomcat, будучи реализацией JavaEE контейнера, не предполагает в спецификации, что кто-то будет сертификаты перевыпускать налету. И то что конкретный пул Hikari у вас работает (только при правильной настройке) - так это считай повезло. В другом сценарии интеграции будет вообще HTTPS с керберосом, keytab в качестве креда, и условный apache http client, который снова нихрена не знает о том, keytab тоже может ротироваться.
Старые сессии, которые уже зашли в Postgres будут жить по итогам старой аутентификации, новые пойдут с новой.
Если у вас пользователь базы из AD, то вы таким образом эффективно заблокируете его, использовав несколько раз старый пароль после его ротации (да я бы честно говоря, и локальных пользователей блокировал бы при вводе неверного пароля). Ну т.е. ротация - далеко не такое простое дело, и Vault сам по себе все проблемы с ней не решает. И я подозреваю, что никто этого полноценно не делает, но тут я естественно ограничен моими познаниями, которые могут быть неполные.
Ну, как давно... это дело было примерно в 2017-2018 году, не позже. И да, у меня даже сборка была кастомная, я выкинул все ресурсы кроме связанных с адресами, чтобы из спарка лучше работало.
Если что-то выглядит странно, данные помечаются статусом «на ручной разбор»
Не исключаю что я что-то невнимательно прочитал, но когда я реально пользовался Фактором для разбора миллионов адресов (несколько лет назад), именно вот эта часть была самой слабой. Потому что такого статуса недостаточно. Нужно максимально четкое пояснение, что именно пошло не так. Ну т.е. имеет место неоднозначность? Какая конкретно? Дублирование? Где? Ну т.е. на примере:
Москва, Курчатова, 12, 25
Есть улица и площадь Курчатова? А дом 12 есть и там и там? Дело в том, что тот кто будет разбирать это вручную - он ведь этого не знает, и полезет в справочник, и будет тратить время, вероятно много. При этом алгоритм парсинга адреса уже этим справочником обладает, и мог бы показать варианты, что такое Курчатова, 12, и в каком из этих домов есть квартира 25, а в каком нет. При этом есть реальные случаи использования, когда адреса и в таком виде могут быть обработаны, если на дальнейшем этапе обработки мы понимаем, какого именно сорта неоднозначности обнаружены. И да, я прекрасно понимаю, что если адрес записан неверно, то и токены 12, 25 тоже могут содержать ошибки :), и эта задача может быть неразрешимой.
Это был NAS, неизвестной мне природы с неизвестными параметрами. А поскольку мы уже должны были с этой машины переехать - дальше я просто разбираться не стал. Все что я помню - то что я добрался до bulk insert по 10000 штук, и производительность все еще росла.
Оно и было пачками. Выж догадываетесь, что большой размер пачки требует памяти тоже? А ее мало. Да, оно в среднем примерно столько, просто биржа по ночам не работает, и вообще у нее поток сообщений сильно неравномерный.
Ну, честно говоря, они все же не так написали, как вы интерпретируете. Они написали "может быть хорошим вариантом" - значит может и не быть. Мне в таком совете не нравится совсем другое - они нихрена не учитывают стоимость самой миграции. Которая легко может стоить значительно больше этих вот $30 (в год), потому что это зарплата специалиста за пару дней максимум. А я не верю, что миграция не приведет к потере в итоге хотя бы пары дней там и сям, даже если пройдет гладко.
Именно это вы и не продемонстрировали. Вы пытались применить все принципы к коду, который весьма вероятно не требовал применения ни одного. А если и требовал - то вы этого не показали, а сразу начали "применять". Если вы именно это хотели показать - у вас получилось так себе.
Вот именно. Я допускаю, что я невнимательно что-то читал, если так - ткните пальцем, где вы описали, какие проблемы были в вашем примере кода до применения принципов?
Вот после этого места уже можно не читать. Давайте применим... зачем? Вы даже не соизволили сформулировать цель применения.
SOLID не самоцель, это инструмент. Инструмент для улучшения некоторых показателей кода. У вас показатели были плохие? Какие именно?
А если вы не знаете, чего хотели - вот ровно это непонятно что вы и получили в итоге.
Я исхожу из того, что вы применяли принципы просто "чтоб было". С поправкой на то, что это учебная статья, вы разумеется можете показать игрушечный код, но "давайте применим все принципы" - это все равно за пределами разумного. И кстати, достижение low coupling тоже не самоцель, связность кода - это просто показатель, который полезно измерять, и который в текущем (исходном состоянии) вас вполне может устраивать.
Иными словами - если код уже достаточно хорош, сопровождается и развивается сравнительно легко, понимается (текущей командой проекта) без проблем - нахрена его ломать и пытаться "улучшить" непонятно что?
Примерах? Да тут примеры вообще ничего не показывают...
Во-первых, вот это утверждение само следовало бы подтвердить измерениями. Потому что строго говоря, на число значений в IN есть практический лимит (пусть даже не в СУБД, так в JDBC драйвере, например), т.е. померять следовало бы хотя бы 1, 10, 100, 1000 и 100000 значений в IN. Кроме того, "обнаружилось" что c IN (1, 2, 3, ...) всегда работает быстро, если в колонке c всегда 1 (и я тоже не буду это доказывать - если это не так, это баг). Т.е. вот это вот "скорость сильно падает" зависит еще и от распределения значений в колонке слева от IN.
А дальше следует пример с двумя значениями в IN, и двумя значениями в VALUES, и при этом разницы в быстродействии мы практически не видим, т.е. она на грани погрешности измерения (и как вы уже отметили, кост в плане - не показатель вообще).
Ну в том стандарте ничего не написано про то, что приложение идет в комплекте. Я вам же точную цитату привел - авторы стандарта считают таковыми приложения, где сервер авторизации и приложение - единое целое. И "user understands them both as the same entity". Ну т.е. тут подчеркивается, что юзер должен понимать, что это одна компания.
Вот не очевидно. СберИд это тоже платформа, и если посмотреть в предлагаемый вами стандарт, то там написано так:
Т.е. сервер авторизации и приложение управляются Сбером? Значит Сбербанк Онлайн это first-party application, почему нет-то? Тут про ОС и предустановку ничего не написано (хотя ваши мысли что тут риска меньше, я вполне понимаю).
Я понял, о чем вы. Практически согласен, кроме одного - вы говорите о стандарте, который не предназначен для first party apps. А стандарт для них - в драфте. И мне лично не очевидно, почему применение стандарта для приложений, к которым он (условно) не подходит, лучше в принципе, чем отступление от него. Да, отступление - это риски (которые надо анализировать конкретно). Да, это учит пользователей нехорошему - согласен.
Вы предлагаете отдельное окно, и считаете это критически важным? Ну ок, допустим - только я не улавливаю, почему пользователь, который не может отличить фейковое приложение банка от настоящего не перепутает точно так же фейковое окно браузера с настоящим?
P.S. По сути, вот ниже уже сформулировали мой вопрос иными словами:
Ну т.е. исходные данные для меня простые - я доверяю своему банку деньги. И я доверяю его приложению (хотя разумеется, допускаю, что там могут быть баги). И когда я ставлю это приложение, я убеждаюсь дважды, что оно настоящее. В противном же случая я не вижу разницы. Если вы видите - поясните, в чем она?
Погодите. С чего вы решили, что при входе в приложение банка я доверяю google.com, которому одновременно доверяет и банк? В приложение Сбер/Тиньков можно войти по кредам гугля? И давно ли?
В моем понимании, Сбер скажем использует Oauth не когда вы входите в Сбербанк Онлайн, а когда вы входите куда-то по СберID, т.е. именно сервис Сбера и является тем, кто аутентифицирует пользователя. Т.е. например, при входе по СберID в megamarket.ru, ну или там Купер и т.п. .
Им по-моему до прототипа как до Луны пешком. Более того, у них запись в ячейку значений 0..2 это в четыре раза больше, чем при двоичном кодировании, когда значения 0..1. Т.е. у них три - в четыре раза больше двух, прикиньте?
Вы не один. У меня тоже делал в 2013 году. Месяц возился, словил все те же проблемы (ну почти) что и автор данной статьи, но так и недоделал. В итоге тоже выбросили, взяли готовое решение (которое существует где-то с 2006 года), и внедрили за день.
И что характерно, на дворе конец 2024, а люди все еще берутся реализовывать все тоже самое, что уже было реализовано 20 лет назад.
Считайте что любым. Что он в памяти где-то у приложения лежит.
Ну т.е. на самом деле я вот про это и говорил - что одного Vault тут недостаточно, сротированный/ротируемый пароль нужно правильно распространять в распределенной среде, и у этой задачи есть много решений, среди которых много неправильных. Причем неправильных как реализаций, так и спецификаций - потому что скажем спецификация DataSource в общем-то не предполагает динамической ротации пароля, это за пределами ее скоупа на момент создания. Так же как Tomcat, будучи реализацией JavaEE контейнера, не предполагает в спецификации, что кто-то будет сертификаты перевыпускать налету. И то что конкретный пул Hikari у вас работает (только при правильной настройке) - так это считай повезло. В другом сценарии интеграции будет вообще HTTPS с керберосом, keytab в качестве креда, и условный apache http client, который снова нихрена не знает о том, keytab тоже может ротироваться.
Если у вас пользователь базы из AD, то вы таким образом эффективно заблокируете его, использовав несколько раз старый пароль после его ротации (да я бы честно говоря, и локальных пользователей блокировал бы при вводе неверного пароля). Ну т.е. ротация - далеко не такое простое дело, и Vault сам по себе все проблемы с ней не решает. И я подозреваю, что никто этого полноценно не делает, но тут я естественно ограничен моими познаниями, которые могут быть неполные.
столько всего построено, вполне можно считать, что метод эффективен.
Пусть отдел продаж и перепишет? :)
Ну, как давно... это дело было примерно в 2017-2018 году, не позже. И да, у меня даже сборка была кастомная, я выкинул все ресурсы кроме связанных с адресами, чтобы из спарка лучше работало.
Ну судя по этому описанию, вы таки здорово развили API с тех пор как я на него смотрел.
Не исключаю что я что-то невнимательно прочитал, но когда я реально пользовался Фактором для разбора миллионов адресов (несколько лет назад), именно вот эта часть была самой слабой. Потому что такого статуса недостаточно. Нужно максимально четкое пояснение, что именно пошло не так. Ну т.е. имеет место неоднозначность? Какая конкретно? Дублирование? Где? Ну т.е. на примере:
Есть улица и площадь Курчатова? А дом 12 есть и там и там? Дело в том, что тот кто будет разбирать это вручную - он ведь этого не знает, и полезет в справочник, и будет тратить время, вероятно много. При этом алгоритм парсинга адреса уже этим справочником обладает, и мог бы показать варианты, что такое Курчатова, 12, и в каком из этих домов есть квартира 25, а в каком нет. При этом есть реальные случаи использования, когда адреса и в таком виде могут быть обработаны, если на дальнейшем этапе обработки мы понимаем, какого именно сорта неоднозначности обнаружены. И да, я прекрасно понимаю, что если адрес записан неверно, то и токены 12, 25 тоже могут содержать ошибки :), и эта задача может быть неразрешимой.
Это был NAS, неизвестной мне природы с неизвестными параметрами. А поскольку мы уже должны были с этой машины переехать - дальше я просто разбираться не стал. Все что я помню - то что я добрался до bulk insert по 10000 штук, и производительность все еще росла.
Оно и было пачками. Выж догадываетесь, что большой размер пачки требует памяти тоже? А ее мало. Да, оно в среднем примерно столько, просто биржа по ночам не работает, и вообще у нее поток сообщений сильно неравномерный.