Супер! Правда я начинаю осваивать не орбитер, а кербал спейс.
Застрял на выходе на орбиту. Есть конечно всякие «лети туда, поверни туда», но ускальзывает сама механика действия. Хочется понять, почему процессы идут именно так.
Скорость работы scrypt вполне удовлетворительна — порядка сотен логинов в секунду.
Булшит Бинго! Инженер не может дать оценку системы без наличия системы.
1ый акт,
Уже которую неделю сыпятся посты о безопасности веба. Я не берусь оценивать авторов и их квалификацию, это не моя тема. Но общий результат излияний ну чуть больше нуля.
У меня сейчас стоит задача разрабтать фронт с защитой >= «средний лвл кулхацкера». Читаю поголовно все топики, пробовал спрашивать. До сих пор я не увидел описания шаблонов по применению или лучших практик. Максимум из полезного выудил — две ссылки и пара комментариев. Один сайт достаточно велик и мне приходится тратить много времени на изучение. По 2ой ссылке документ с описанием как надо и как не надо делать хранение пароля. (Но к примеру есть расхождение в порядке расположения соли и пароля. На хабре поголовно советуют соль помещать в конце. Документ не придавал этому значения. Судя по этому топику проблема лишь в говнокоде реализации конкретных функций конкретного языка.)
У любого разработчика есть вагон и маленькая тележка технологий, с которыми надо иметь дело и которые меняются довольно интенсивно. Невозможно объять необъятное, поэтому существуют специализации. Каждый делает свое дело. Почему все безопасники ожидают от прочих понимания на уровне не меньше среднего?
Дайте уже нормально описанный процесс как надо делать. От кого еще его ждать?!
2ой акт.
Разработка — это не раз, два и готово (нормальная разработка).
Всунуть заведомо медленный алгоритм с гигантским потреблением по памяти… Ну если в системе 2 человека, то конечно пофиг. Пойдем от вашей цифры в 100 пользователей в секунду. Примерно подходит для системы с посещаемостью в несколько миллионов в сутки. В мире их не так уж и мало. Ценность аудитории очевидно высока. Учитывая длительность и тяжесть операции шифрования, вес процесса входа в систему возрастает. Вам точно придется раскошелиться на процы и память (хотя с ней даже пофиг, относительно процов). Не дай бог у вас еще вендор-лок с софтом (многие считают лицензии по ядрам). Чем выше уровень кластеризации, тем больше граблей вы огребете и в разработке и в сопровождении. Чтобы все эти затраты окупились, предприятие должно обладать высокой доходностью и большой зависимостью от целостности данных клиентов. Т.е. нужен адекватный анализ критериев разработки системы. Пихать везде подряд — бред.
Редко — это на сайте Васи Пупкина (на хрена ему вообще сложности с безопасностью, если ценность сайта мизер). Все зависит от профиля системы. К примеру банковские сотрудники на работу приходят в определенное время и всплеск логинов будет в течение короткого интервала. Другой вариант — гигантская аудитория. Логины там будут происходить постоянно. С такими требованиями к ресурсам это будет одна из наиболее тяжелых операций.
Сложность разработки начнется в тот момент, когда окажется недостаточным одной железки и надо начинать клепать кластерное решение. Чем дальше, тем сложнее система будет. Разработка и поддержка соответственно тоже.
Разве что для безопасника. Такие требования подымают стоимость и железа и разработки. Причем с размером аудитории бурлеск неадекватных трат будет также расти.
С битмап индексами не все однозначно и просто. Они хороши для множества полей, по одному-двум полям профита не будет. Полное сканирование таблицы тоже не всегда ужасно. Особенно если есть возможность использовать параллельные чтения.
Фиг с белками и со спецслужбами. Крупные конторы собирают данные для себя прежде всего и для большинства из них это краеугольный камень заработка. Многие бесплатные и удобные приложения, кстати, тоже способ получить кучу данных о людях. Конечно есть всегда возможность отказаться от услуг, но больше неприятно, что все махинации проделываются за спиной втихую.
Ну дык без плана вообще не имеет смысла говорить о нужен/не нужен.
Но есть один нюанс наблюдаемый в реальности. Люди узнают про индексы и суют куда не попадя. Потом часть узнает, что от этого иногда бывает плохо. И т.д. и т.п. Идут по вполне очевидным граблям. Но вот про план, даже если и знают, хрен посмотрят (в большинстве своем).
Индексы могут отрицательно сказаться на производительности и в случае больших таблиц в независимости от вставок. Например по неуникальным значениям, с мылым количеством различных значений. Дешевле фулскан обойдется.
Да не дай бог. Видел одно вендорное решение с java в БД. Никаких шансов на анализ производительности. Если SQL еще можно вдоль и поперек статистикой исследовать, то подобный код просто крест.
По-моему, Кайт сказал, что лучше программист, который хорошо знает SQL и плохо PL/SQL, нежели наборот.
Из собственных наблюдений не могу согласиться или опровергнуть, но точно есть 2 проблемных пункта с засовыванием логики в БД:
1. PL/SQL все же ограниченный по сравнению с той же java язык, поэтому часто видны костыли и извращения ( опять с точки зрения java). Нередко это приводит к ошибкам или очень медленным решениям. Про удобство восприятия кода PL/SQL вообще молчу.
2. Размытая логика.
Когда в короткой статье пытаются объять необъятное, то уже не стоит читать. Каждый момент системы и её создания — это отдельная большая песня со множеством вариантов и нюансов.
Ну и опять же, разработка исходя из инструментов — бред.
Работая в подрядной компании повидал всякого: от полного отсутствия интернета (гос предприятие), до почти полной свободы. При этом желание сотрудников работать никак с ограничениями не коррелирует. Все больше зависит от атмосферы, в которой находятся сотрудники. К слову в одной из компаний, где ограничений было меньше всего люди работают, а не сидят в чатиках с друзьями. Но только там все люди с горящими глазами, которым интересно их дело. Если закинуть туда курятник, то вряд ли что-то сдвинется с места.
Застрял на выходе на орбиту. Есть конечно всякие «лети туда, поверни туда», но ускальзывает сама механика действия. Хочется понять, почему процессы идут именно так.
Булшит Бинго!Инженер не может дать оценку системы без наличия системы.1ый акт,
Уже которую неделю сыпятся посты о безопасности веба. Я не берусь оценивать авторов и их квалификацию, это не моя тема. Но общий результат излияний ну чуть больше нуля.
У меня сейчас стоит задача разрабтать фронт с защитой >= «средний лвл кулхацкера». Читаю поголовно все топики, пробовал спрашивать. До сих пор я не увидел описания шаблонов по применению или лучших практик. Максимум из полезного выудил — две ссылки и пара комментариев. Один сайт достаточно велик и мне приходится тратить много времени на изучение. По 2ой ссылке документ с описанием как надо и как не надо делать хранение пароля. (Но к примеру есть расхождение в порядке расположения соли и пароля. На хабре поголовно советуют соль помещать в конце. Документ не придавал этому значения. Судя по этому топику проблема лишь в
говнокодереализации конкретных функций конкретного языка.)У любого разработчика есть вагон и маленькая тележка технологий, с которыми надо иметь дело и которые меняются довольно интенсивно. Невозможно объять необъятное, поэтому существуют специализации. Каждый делает свое дело. Почему все безопасники ожидают от прочих понимания на уровне не меньше среднего?
Дайте уже нормально описанный процесс как надо делать. От кого еще его ждать?!
2ой акт.
Разработка — это не раз, два и готово (нормальная разработка).
Всунуть заведомо медленный алгоритм с гигантским потреблением по памяти… Ну если в системе 2 человека, то конечно пофиг. Пойдем от вашей цифры в 100 пользователей в секунду. Примерно подходит для системы с посещаемостью в несколько миллионов в сутки. В мире их не так уж и мало. Ценность аудитории очевидно высока. Учитывая длительность и тяжесть операции шифрования, вес процесса входа в систему возрастает. Вам точно придется раскошелиться на процы и память (хотя с ней даже пофиг, относительно процов). Не дай бог у вас еще вендор-лок с софтом (многие считают лицензии по ядрам). Чем выше уровень кластеризации, тем больше граблей вы огребете и в разработке и в сопровождении. Чтобы все эти затраты окупились, предприятие должно обладать высокой доходностью и большой зависимостью от целостности данных клиентов. Т.е. нужен адекватный анализ критериев разработки системы. Пихать везде подряд — бред.
Сложность разработки начнется в тот момент, когда окажется недостаточным одной железки и надо начинать клепать кластерное решение. Чем дальше, тем сложнее система будет. Разработка и поддержка соответственно тоже.
Но есть один нюанс наблюдаемый в реальности. Люди узнают про индексы и суют куда не попадя. Потом часть узнает, что от этого иногда бывает плохо. И т.д. и т.п. Идут по вполне очевидным граблям. Но вот про план, даже если и знают, хрен посмотрят (в большинстве своем).
Из собственных наблюдений не могу согласиться или опровергнуть, но точно есть 2 проблемных пункта с засовыванием логики в БД:
1. PL/SQL все же ограниченный по сравнению с той же java язык, поэтому часто видны костыли и извращения ( опять с точки зрения java). Нередко это приводит к ошибкам или очень медленным решениям. Про удобство восприятия кода PL/SQL вообще молчу.
2. Размытая логика.
Ну и опять же, разработка исходя из инструментов — бред.