Дада, весь год, до мая включительно — всё нормально с исходящей было…
Сейчас у меня и на таганке и на лубянке — работать невозможно ((
Очень надеюсь, что исходящую вернут… Килобайт 100 хотябы…
Не знаю как, но эти плюсы/минусики — поделили людей на 2 лагеря.
Все проверяют свою карму постоянно, обижаются когда в неё насуют, мстят за негативные коменты и вообще из нормальных людей превращаются в кармадрочеров.
Это просто феномен какой-то, причем дело видимо не в самом механизме, а в различных ограничениях из-за него вытекающих. На несуществем сайте, к примеру, тоже есть подобные механизмы, но там пороговые значения сильно сдвинуты, и относятся к ним проще, с юмором. Никто не боится получить кучу минусов, там это весело. А здесь, почему-то — злобно. Дада, правильное определение — злобно.
Но несмотря на негатив, хабр дает людям эмоции, и из-за этого, наверно на него возвращаешься вновь и вновь.
Напишешь резкий, но справедливый коментарий, потом ходишь проверять, насколько выросла хабрасила (плюсы коменту) — и упала ли карма (авторы топиков обычно нервно реагируют на критику)
Бувают правда и позитивные эмоции. Но реже.
Ещё — много, очень много откровенно подхалимских коментариев. Они бесят больше всего.
Надо чтото менять в консерватории. Экспериментировать с показателями. Сейчас — такое ощущение что сайт перестал развиваться. Эволюционировать. Хотя, может у создателей просто не хватает времени и они заняты другими проектами… Жаль если так. Хочется новых неожиданных штук.
Это абсолютно верное поведение кластерных индексов, соответствующее стандарту SQL.
Кластерные индексы медленнее на вставке и быстрее на селектах.
Если разработчик этого не знает — это не проблема движка, это проблема разработчика.
Если необходимо избежать данного поведения достаточно было сделать автоинкрементное поле integer — primary, а значения хэша хранить в отдельном поле, по которому построить уникальный secondary index.
Другими словами хранение сессий в БД необходимо там, и только там, где необходима высокая безопасность. Для того, чтобы злоумышленник — укравший кукис пользователя не мог, например, списать средства со счета пользователя.
Для этого и сохраняются сессии в бд и сверяются с кукис. И если, изменился айпи и, опционально, браузер — запрашивается дополнительная авторизация.
Более того, данную информацию целесообразно шифровать.
Стартовать сессии для гостей хранящиеся_в_БД — простите бред.
Тем более — на главной Яндекса. Насколько я понял — Салагаев просто не ожидал такого поведения (сохранения сессий в БД) от Джанго.
ИнноДб — здесь не причём абсолютно. Хватит уже распространять мифы. Для кластерных индексов в любой_бд — будет строиться дерево.
Как готовить сессии:
1. если необходимо хранить какую то временную информацию для гостей — целесообразно сохранять данные сессии в куки.
Зачем это нужно? Вот пример:
Допустим, что пользователь залогинился на вашем сайте. После авторизации вы можете добавить его username и email в cookies сессии, что сделает эту информацию доступной везде — без необходимости подключения к базе данных.
2. Сохранение данных о сессии в базу данных
Пока информация хранящаяся в cookies пользователя содержит ID сессии, вы не имеете возможности проверить его, в отличие от варианта когда данные сессии хранятся в базе данных. Для приложений, которые не требуют высокого уровня безопасности, проверка ID сессии не является обязательной, однако, если ваше приложение требует высокого уровня безопасности, то проверка становится обязательной.
Если данные сессии находятся в базе данных, то каждый раз, когда в cookies пользователя обнаруживается рабочая сессия, осуществляется запрос к базе данных — с целью сравнить ID сессий. Если ID сессии не совпадают, то сессия разрушается. ID сессии никогда не обновляется, он может быть лишь сгенерированным, когда сессия создается.
>> Вот пример, как упал сервис Яндекса из-за InnoDB — softwaremaniacs.org/blog/2008/02/22/why-offline-crashed/
Сервис упал не из-за ИнноДб, а из-за криворукости программистов.
1. Primary key — md5-хеш — иначе как долбоебизмом это я назвать не могу
2. На индексе была одна выборка с join'ом четырех таблиц, одна из которых — самая здоровенная таблица базы
Кстати, собственно Салагаев ни в чём ИнноДб не обвиняет, а пишет о своих косяках и к чему они привели.
Но Вы же его опубликовали? www.habrahabr.ru/blogs/infosecurity/63176/
Обратите внимание на этот коммент:
* AztEK: «А если используется JSONP, то всё ещё проще, переопределяем callback-функцию и voilà»
Это обычный uri, в котором demo — ключ приложения, которому предоставлен доступ.
Uri возвращает json, который — во первых — кэшируется, во вторых — контролируется низкоуровневыми средствами nginx на количество запросов (не более одного запроса в 2 секунды), в третьих — универсален.
С другого своего www сайта я забираю результаты обычным curl'ом, а партнерское приложение — написано на air и забирает данные средствами flash
Во первых — это очень полезное ограничение. Так как не позволяет злоумышленнику вызывать послать запрос со своего домена.
Во вторых — данным хаком вы снимаете это ограничение, так как имя колбэкфункции легко подсмотреть.
На мой взгляд статья из серии «Вредные советы».
В своих проектах для кросс доменных запросов я разрабатываю полноценный апи. Это звучит устрошающе, но на практике — на пару строк кода больше.
Но зато:
1. У вашего сайта автоматом появляется отлаженный апи и вы можете предоставлять к нему доступ сторонним разработчикам
2. На сайте не появляется громадных дыр в безопасности.
Просто жаль затраченного времени. Если бы топик назывался «Советы новичкам блабла» или «Wordpress для чайников» — я бы в него даже и не заходил и не раздражался. А новички бы ели нахваливали.
P.S. Срать в карму несогласным давно стало доброй традицией на Хабре, username.
Но должен предупредить, что от этого у тебя вырастут волосы на ладошках.
О, да! «urok-7-kontent» говорит мне о многом…
Давайте называть вещи своими именами, человеку легче запомнить и набрать краткий адрес.
Для SEO лучше текстовые ссылки с ключевыми словами в урле.
Переводить не лень было? Когда «професиАнальным блогерам» не о чем писать — они начинают заниматься высерами на тему 10 советов бла-бла-бла… Макулатура…
Сейчас у меня и на таганке и на лубянке — работать невозможно ((
Очень надеюсь, что исходящую вернут… Килобайт 100 хотябы…
www.leprastuff.ru/data/img/20090723/d491272a09194e7072a801ef3fcdf46b.JPG
Все проверяют свою карму постоянно, обижаются когда в неё насуют, мстят за негативные коменты и вообще из нормальных людей превращаются в кармадрочеров.
Это просто феномен какой-то, причем дело видимо не в самом механизме, а в различных ограничениях из-за него вытекающих. На несуществем сайте, к примеру, тоже есть подобные механизмы, но там пороговые значения сильно сдвинуты, и относятся к ним проще, с юмором. Никто не боится получить кучу минусов, там это весело. А здесь, почему-то — злобно. Дада, правильное определение — злобно.
Но несмотря на негатив, хабр дает людям эмоции, и из-за этого, наверно на него возвращаешься вновь и вновь.
Напишешь резкий, но справедливый коментарий, потом ходишь проверять, насколько выросла хабрасила (плюсы коменту) — и упала ли карма (авторы топиков обычно нервно реагируют на критику)
Бувают правда и позитивные эмоции. Но реже.
Ещё — много, очень много откровенно подхалимских коментариев. Они бесят больше всего.
Надо чтото менять в консерватории. Экспериментировать с показателями. Сейчас — такое ощущение что сайт перестал развиваться. Эволюционировать. Хотя, может у создателей просто не хватает времени и они заняты другими проектами… Жаль если так. Хочется новых неожиданных штук.
Кластерные индексы медленнее на вставке и быстрее на селектах.
Если разработчик этого не знает — это не проблема движка, это проблема разработчика.
Если необходимо избежать данного поведения достаточно было сделать автоинкрементное поле integer — primary, а значения хэша хранить в отдельном поле, по которому построить уникальный secondary index.
Именно это написано в мануале — Clustered and Secondary Indexes: www.dev.mysql.com/doc/refman/5.1/en/innodb-index-types.html
Какая то неинтересная дискуссия. Предлагаю закрыть.
Для этого и сохраняются сессии в бд и сверяются с кукис. И если, изменился айпи и, опционально, браузер — запрашивается дополнительная авторизация.
Более того, данную информацию целесообразно шифровать.
Рекомендую посмотреть на реализацию класса сессий в движке codeigniter (PHP): www.code-igniter.ru/user_guide/libraries/sessions.html
Там есть и шифрование, и опциональное сохранение в БД с синхронизацией и flashsdata для временных данных.
MD5 для ключа — кстати, вполне оправдано. Здесь я был не прав.
Тем более — на главной Яндекса. Насколько я понял — Салагаев просто не ожидал такого поведения (сохранения сессий в БД) от Джанго.
ИнноДб — здесь не причём абсолютно. Хватит уже распространять мифы. Для кластерных индексов в любой_бд — будет строиться дерево.
Как готовить сессии:
1. если необходимо хранить какую то временную информацию для гостей — целесообразно сохранять данные сессии в куки.
Зачем это нужно? Вот пример:
Допустим, что пользователь залогинился на вашем сайте. После авторизации вы можете добавить его username и email в cookies сессии, что сделает эту информацию доступной везде — без необходимости подключения к базе данных.
2. Сохранение данных о сессии в базу данных
Пока информация хранящаяся в cookies пользователя содержит ID сессии, вы не имеете возможности проверить его, в отличие от варианта когда данные сессии хранятся в базе данных. Для приложений, которые не требуют высокого уровня безопасности, проверка ID сессии не является обязательной, однако, если ваше приложение требует высокого уровня безопасности, то проверка становится обязательной.
Если данные сессии находятся в базе данных, то каждый раз, когда в cookies пользователя обнаруживается рабочая сессия, осуществляется запрос к базе данных — с целью сравнить ID сессий. Если ID сессии не совпадают, то сессия разрушается. ID сессии никогда не обновляется, он может быть лишь сгенерированным, когда сессия создается.
Сервис упал не из-за ИнноДб, а из-за криворукости программистов.
1. Primary key — md5-хеш — иначе как долбоебизмом это я назвать не могу
2. На индексе была одна выборка с join'ом четырех таблиц, одна из которых — самая здоровенная таблица базы
Кстати, собственно Салагаев ни в чём ИнноДб не обвиняет, а пишет о своих косяках и к чему они привели.
Разве в условиях конкурса была прописана обязательная развиртуализация/деанонимизация/пиаракция?
www.habrahabr.ru/blogs/infosecurity/63176/
Обратите внимание на этот коммент:
* AztEK: «А если используется JSONP, то всё ещё проще, переопределяем callback-функцию и voilà»
Это обычный uri, в котором demo — ключ приложения, которому предоставлен доступ.
Uri возвращает json, который — во первых — кэшируется, во вторых — контролируется низкоуровневыми средствами nginx на количество запросов (не более одного запроса в 2 секунды), в третьих — универсален.
С другого своего www сайта я забираю результаты обычным curl'ом, а партнерское приложение — написано на air и забирает данные средствами flash
И овцы целы и волки сыты. ммм?
Во вторых — данным хаком вы снимаете это ограничение, так как имя колбэкфункции легко подсмотреть.
На мой взгляд статья из серии «Вредные советы».
В своих проектах для кросс доменных запросов я разрабатываю полноценный апи. Это звучит устрошающе, но на практике — на пару строк кода больше.
Но зато:
1. У вашего сайта автоматом появляется отлаженный апи и вы можете предоставлять к нему доступ сторонним разработчикам
2. На сайте не появляется громадных дыр в безопасности.
Нет ли в планах открытия ссылок для прослушивания для не авторизованных пользователей?
Извините.
P.S. Срать в карму несогласным давно стало доброй традицией на Хабре, username.
Но должен предупредить, что от этого у тебя вырастут волосы на ладошках.
В какую сторону будут следующие 10 шагов? Как раскрутить свой сайт за 10 шагов?
Шаг 1: Разместите цикл статей-переводов на хабре.
Причем против собственно сайта я ничего не имею. Новичкам он будет и интересен и полезен.
А здесь эти советы выглядят глупо и наивно.
Давайте называть вещи своими именами, человеку легче запомнить и набрать краткий адрес.
Для SEO лучше текстовые ссылки с ключевыми словами в урле.