Pull to refresh

Comments 10

hint: Сделайте -dev режим, который будет принимать токен из конфига. В этом случае (для разработчика, которого не волнует butler) надо будет просто передавать токен из конфига (указанного в -dev режиме).

Спасибо, хорошее предложение. Мы сейчас почти так и делаем. Но всё же хочется соблюдать некий паритет dev- и production окружений

Ну, есть хардкорные варианты вида devstack'а или minik8s, которые для разработчика "поднимают всё сами" в сложных проектах, но весь мой опыт возни с обвязкой таких штук говорит, что они требуют сопровождения (операторов или devops'ов) едва ли не большего, чем оригинальный код. Потому что там начинается всякое "хочу IP такой-то", "а вот тут по портам конфикт", а вот тут мы две копии на одной машине не можем запустить и т.д.


hashicorp'овский подход с поддержкой -dev режима — лучший, имхо.

Шёл 2021 год. На марсе уже летали вертолёты.
В России "крупнейший EdTech в школьном образовании" наконец-то решился не хранить пароли в незашифрованном виде и с гордостью пишет об этом статьи.
Я бы на вашем месте посыпал голову пеплом и молчал об этом в тряпочку.

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

Хочу сказать, что не оправдываю хранение паролей в открытом виде, но хотелось бы иметь позитивную мотивационную культуру в российском айти сообществе ради исправления подобных промахов в архитектуре, — и, как мне это видится, нужно хвалить за исправления, а не ругать за ошибки.
Есть подходы, которые уже являются де-факто стандартом и их игнорирование, как минимум, плохой тон, как максимум, указывает на некомпетентность. Шифрование паролей как раз относится к таким подходам, и для «крупнейшего EdTech в школьном образовании» это позор, за такое надо как раз ругать, а не хвалить. Давайте тогда также похвалим ребят из госуслуг, например, что они прикрыли дыру, которую по недосмотру сами же оставили, ведь ошибку признали и исправили. Такой подход деструктивен, т.к. понижает стоимость ошибки.

Пароли, которые вводят сами пользователи, и не хранились в отрытом виде, только солёный хеш. Открытыми хранились пароли школьников, которые должны быть доступны учителю и родителю в открытом же виде. Ибо дети 6-7-8-9 лет пароль свой регулярно не помнят. И возможности сбросить его через почту не имеют. А учителю нужно это на уроке, то есть вот-прямо-сейчас-залогиньтесь, 5 минут ждать кого-то каждый урок — не вариант. Какое бы вы предложили решение с такими требованиями?


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

Зато по потреблению ресурсов на стороне пользователя шагают в ногу со временем. В прошлом году пришлось агрейдить ноутбук, чтобы ребёнку было более-менее комфортно учиться. Но и это не помогало, когда логинился весь класс, видео периодически пропадало или запаздывание доходило до десятка секунд, потребление процессора возростало, а сетевая активность была, как будто смотрю видео HD (при отсутствии видео!)

А они тут о паролях забеспокоились!

Keycloak, Auth0 - фу, долго разбираться и платить не хотим, давайте сделаем велосипед да ещё и обзовем микросервисом)

Не играйте с безопасностью, дороже выйдет)

Sign up to leave a comment.