Всё же, эта идея кажется мне достаточно стрёмной: по сути, мы позволяем фронтенду делать любые запросы, без явной реализации этих запросов в контроллере.
Я вижу в этом некоторую опасность: например, какой-нибудь злодей может подобрать максимально "тяжёлую" комбинацию параметров (фильрация по параметрам, у которых нет индекса, использование таких параметров для "like", которые не используют индекс) и создать аномальную нагрузку на БД.
Я предпочитаю такие вещи контролировать в явном виде.
При переводе технических ресурсов на русский, есть ещё такая проблема: IT-специалисты читают очень много профессиональных текстов на английском, и знают английскую терминологию лучше, чем русскую.
Например, во многих языках программирования есть такая конструкция, как list comprehension. Я понятия не имею, как назвать её по-русски.
P. S. Википедия переводит list comprehension как списковое включение. Честно скажу, если бы я встретил такой термин в тексте, я бы не понял, что имеется ввиду.
А за что минус? Почитайте, что ли, как twisted работает и что такое асинхронность. Scrapy работает в одном процессе, в одном потоке.
Ну, при желании можно запускать много отдельных процессов с помощью Scrapyd или распределённый краулинг в Scrapy Cluster, но сам Scrapy — однопоточный.
Минус еще к тому же, хранение либо открытого пароля в базе, либо шифра который можно с легкостью декриптовать, т.б. отметаем сразу соли и т.п.
Изначально, вы указали на то, что пароль, который хранится открыто в базе — это не хорошо.
Но потом, вы предложили использовать вместо него ещё более открытую информацию, ту информацию, которую можно добыть и без кражи базы.
показать пользователю информацию, например из места по Геотаргетингу определенную, либо по GeoIP.
Вы уже забыли, что я сижу прямо за вашей спиной, на том же айпишнике? :)
UA браузера в человекочитаемом формате
UA передаётся при каждом запросе, да я и так прекрасно вижу, что у вас Firefox под Ubuntu (например).
доп. информация (тема для размышлений/brainstorm) должна максимально описывать тот вход с которым пришел пользователь
Как насчёт, сгенерировать случайный код и показать его и там и там? :)
Суть в том, что сверять нужно с чем-то. Для этого нужно либо передать токен/пароль, полученный от телеграм-бота в веб-интерфейс, либо отправлять телеграм-боту пароль, полученный из веб-интерфейса.
Иначе невозможно гарантированно установить связь между пользователем, который заходит через веб и пользователем, с которым вы связываетесь через телеграм.
с информацией(и предупреждением) кто и откуда пытается зайти
Как вы себе это представляете?
Предположим, я злодей и я пытаюсь зайти в ваш аккаунт на том же сайте, из того же места и одновременно с вами. (Сижу в той же кафешке что и вы, подключен к тому же вайфаю, подглядываю через плечо).
С вероятностью 50% вы впустите меня, а не себя.
Как это пофиксить? Например: показывать одноразовый пароль при входе, просить его отправить в телеграм. В этом случае, даже если я его подсмотрю или украду из базы, это мне не поможет, т. к. вы должны его отправить боту.
Я не думаю, что bottleneck освоения информации — это сам процесс чтения.
Я думаю, что осознание информации в любом случае занимает куда больше времени.
Кстати, то сервис даёт ссылку с токеном, а не просто пароль. На мой взгляд, это куда более юзер-френдли: не надо держать страницу открытой и вручную копировать туда пароль, достаточно просто кликнуть на ссылку и получить редирект на конечную страницу.
Начнём с того, что сравнивать C с Rust (Cargo) — это какое-то читерство :)
У авторов Rust/Cargo была возможность внимательно изучить все предыдущие подходы, взять из них всё самое лучшее и выкинуть всё плохое. Авторы C были первопроходцами, естественно они допускали ошибки.
Теперь к самой сути статьи.
Очевидно, что идеальная программа/система, написанная за бесконечное количество времени и денег никому не нужна.
Людям нужно нечто достаточно хорошее, способное решать задачи прямо сейчас.
Поэтому победил UNIX, несмотря на все его недостатки.
Поэтому никто не готов "ломать весь мир" и переписывать все программы, переходя на Plan 9 или что-нибудь ещё, проще вставить костыль в UNIX, чтобы оно работало прямо сейчас.
Что с этим делать? Ничего. Мир жесток, несправедлив и совсем не идеален. Нужно просто научиться жить с этим дальше. Научиться решать реальные задачи, обходя подводные камни.
А вообще, спасибо за статью, очень много интересных исторических и технических фактов. О многих из них я раньше не знал, но теперь почитаю про них подробнее.
Хмм, ок, теперь я понял вашу идею.
Всё же, эта идея кажется мне достаточно стрёмной: по сути, мы позволяем фронтенду делать любые запросы, без явной реализации этих запросов в контроллере.
Я вижу в этом некоторую опасность: например, какой-нибудь злодей может подобрать максимально "тяжёлую" комбинацию параметров (фильрация по параметрам, у которых нет индекса, использование таких параметров для "like", которые не используют индекс) и создать аномальную нагрузку на БД.
Я предпочитаю такие вещи контролировать в явном виде.
Странно, что вы не посмотрели на соседний метод (filter)[http://docs.sqlalchemy.org/en/latest/orm/query.html#sqlalchemy.orm.query.Query.filter], который позволяет фильтровать куда более "динамично", и главное — читабельно:
Помимо этого, с помощью других методов атибутов можно записать и
in(MyClass.some_value.in([1, 2, 3])) и вообще что угодно.Аджайл.
Какая может быть конструктивная критика к такой статье?
Долго думал. Первый раз слышу такое произнесение слова agile.
При переводе технических ресурсов на русский, есть ещё такая проблема: IT-специалисты читают очень много профессиональных текстов на английском, и знают английскую терминологию лучше, чем русскую.
Например, во многих языках программирования есть такая конструкция, как
list comprehension. Я понятия не имею, как назвать её по-русски.P. S. Википедия переводит
list comprehensionкаксписковое включение. Честно скажу, если бы я встретил такой термин в тексте, я бы не понял, что имеется ввиду.А за что минус? Почитайте, что ли, как
twistedработает и что такое асинхронность. Scrapy работает в одном процессе, в одном потоке.Ну, при желании можно запускать много отдельных процессов с помощью Scrapyd или распределённый краулинг в Scrapy Cluster, но сам Scrapy — однопоточный.
multiprocessing?Scrapy однопоточный.
А какая связь между BSD и TreeFrog Framework?
Что-нибудь слышали про KISS?
Прочитав заголовок, ожидал стартап по прдаже легальных наркотиков, а тут — очередная унылая CRM'ка
Изначально, вы указали на то, что пароль, который хранится открыто в базе — это не хорошо.
Но потом, вы предложили использовать вместо него ещё более открытую информацию, ту информацию, которую можно добыть и без кражи базы.
Вы уже забыли, что я сижу прямо за вашей спиной, на том же айпишнике? :)
UA передаётся при каждом запросе, да я и так прекрасно вижу, что у вас Firefox под Ubuntu (например).
Как насчёт, сгенерировать случайный код и показать его и там и там? :)
Ввёл чужой email — настоящий владелец email получит сообщение о том, что этот email уже используется другим пользователем (при попытке регистрации).
Ошибся при вводе email и забыл пароль — не можешь восстановить доступ к аккаунту никак.
Пожалуйста, перечитайте комментарий drfill и мой.
Суть в том, что сверять нужно с чем-то. Для этого нужно либо передать токен/пароль, полученный от телеграм-бота в веб-интерфейс, либо отправлять телеграм-боту пароль, полученный из веб-интерфейса.
Иначе невозможно гарантированно установить связь между пользователем, который заходит через веб и пользователем, с которым вы связываетесь через телеграм.
Как вы себе это представляете?
Предположим, я злодей и я пытаюсь зайти в ваш аккаунт на том же сайте, из того же места и одновременно с вами. (Сижу в той же кафешке что и вы, подключен к тому же вайфаю, подглядываю через плечо).
С вероятностью 50% вы впустите меня, а не себя.
Как это пофиксить? Например: показывать одноразовый пароль при входе, просить его отправить в телеграм. В этом случае, даже если я его подсмотрю или украду из базы, это мне не поможет, т. к. вы должны его отправить боту.
Я не думаю, что bottleneck освоения информации — это сам процесс чтения.
Я думаю, что осознание информации в любом случае занимает куда больше времени.
Зачем повышать скорость чтения? В чём польза?
Кстати, то сервис даёт ссылку с токеном, а не просто пароль. На мой взгляд, это куда более юзер-френдли: не надо держать страницу открытой и вручную копировать туда пароль, достаточно просто кликнуть на ссылку и получить редирект на конечную страницу.
Когда-то давно, мне приходила в голову такая же идея. Но я погуглил и нашёл готовую реализацию, поэтому решил не переизобретать велосипед :)
Начнём с того, что сравнивать C с Rust (Cargo) — это какое-то читерство :)
У авторов Rust/Cargo была возможность внимательно изучить все предыдущие подходы, взять из них всё самое лучшее и выкинуть всё плохое. Авторы C были первопроходцами, естественно они допускали ошибки.
Теперь к самой сути статьи.
Очевидно, что идеальная программа/система, написанная за бесконечное количество времени и денег никому не нужна.
Людям нужно нечто достаточно хорошее, способное решать задачи прямо сейчас.
Поэтому победил UNIX, несмотря на все его недостатки.
Поэтому никто не готов "ломать весь мир" и переписывать все программы, переходя на Plan 9 или что-нибудь ещё, проще вставить костыль в UNIX, чтобы оно работало прямо сейчас.
Что с этим делать? Ничего. Мир жесток, несправедлив и совсем не идеален. Нужно просто научиться жить с этим дальше. Научиться решать реальные задачи, обходя подводные камни.
А вообще, спасибо за статью, очень много интересных исторических и технических фактов. О многих из них я раньше не знал, но теперь почитаю про них подробнее.