Просто о CSRF/XSRF(Cross-Site Request Forgery)

Подделка HTTP-запросов 

Суть - к Вам через ссылку/картинку/frame/etc с другого сайта (POST/GET), или  с этого же по ссылке (GET )/через форму(POST,если возможно их добавление, а оно возможно например в почте), где Вы авторизованы, заставляют выполнить действие, компрометируя Ваши действия на атакуемом сайте.

Решение(Субъективное понимание): с помощью PHP проверять откуда пришел пользователь $_SERVER["HTTP_REFERER"], прежде чем позволять выполнять ему действия POST/GET, для которых требуется авторизация.

Однако у пользвателя может и не быть Referrer, в таком случаем можно использовать и идентификаторы сессии вшитые в страницу, не предполагающую саму по себе действия, но с которой они выполняются.

2.Предупредить  возможность атаки при перенаправлениях внутри сайта.

3. предусмотреть возможность атаки внутри сайта, при передаче от другого пользователя послания с ссылкой(/формой/изображение-ссылкой) в том, или ином виде.

А Все красиво расписано securitylab.ru/analytics/292473.php

Графовые СУБД, neo4j

Презентация графовых БД neo4j:
http://www.slideshare.net/thobe/nosqleu-graph-databases-and-neo4j
Такой язык даже выглядит человечней, судя по презентации...


Это действительно очень круто! Интересно что с быстродействием? Поиск по таблице + динамические списки? С другой стороны, по сути это просто подноготная любых обычных структурных ООП-языков... такая какая она должна быть ИМХО.

чувствую неизбежноcть события наступления эры NoSQL СУБД, судя по направлению миграции социальных сетей, поисковиков e.t.c.
Беспокоит избыток возможных связей(max(n!)), так ведь и все со всем связать можно...в любом случае все это очень мило и проще поддается изменению )))))

Горизантальная перестановка записей в MySQL / SQL в списке

(порядковые номера вызывают кучу минусов
(в быстродействии перестановок),
хранение порядка целиком ограниченно максимальной размерностью списка
(1000 элементов в JSON могут обойтись ~4x1kb,
только на одном узле, а если больше?)
Поэтому выбраны динамические списки для хранения порядка.
А вообще лучше NoSQL использовать, например: neo4j
Псевдокод:
=============================
добавление(prev,this)
=============================
1. var @a=SELECT prev;
2. if EXIST(a):
3. INSERT
  this.prev=a;
  this;
=============================
перемещение(this,pos)
/*pos == idElem на место которого вставляем*/
=============================
1. c=count()
2. if posкопируем @соседей перемещаемого.
3.  SELECT this.prev() INTO @pr,
   this.next() INTO @tn;
сшиваем дырку под ними
4.  UPDATE tn.prev()=pr;||null
5.  UPDATE pr.next()=tn;||null
делаем разрыв перед pos, последним действием
  SELECT pos.prev INTO @ppv;
6.  UPDATE this.prev()=ppv; 
7.  UPDATE this.next()=pos;
8.  UPDATE ppv.next=this;
9.  UPDATE pos.prev=this;
==============================
удаление
==============================
1.  SELECT this.prev() INTO @pr,
   this.next() INTO @tn;
2.  UPDATE pr.next()=tn;
3.  UPDATE tn.prev()=pr;

Внимание!: Код экспериментальный. Вносите замечания.
Из замеченного: 
*все перезаписываемые связи 
предварительно дублировать в переменные, 
т.к. возможно наложение, например при 
одновременных вызовах со старого образца 
* предотвращение зацикливания

Как Я ликвидировал предприятие. Часть 1.

Ликвидация предприятия состоит из трех этапов. Первый этап - это закрытие банковских счетов, оповещение Государственного Вестника. Были утеряны все документы, поэтому восстановил их в налоговой, повторно печать зарегистрировал в Сбербанке и отписал в государственный вестник о потере печати. В случае не сообщения в Сбербанк в срок о замене печати, возможны санкции. В предприятии у нас получилось так, что кроме меня для ликвидации необходима была подпись второго лица, бухгалтера. Однако бухгалтер был уволен. Поэтому пришлось сначала подать документы о том, что я являюсь ликвидатором в единственном числе и бухгалтера нету. Что следует из Приказа, о возведении бухгалтерии и директорских полномочий на одно лицо. Повторно был взят образец подписи. И оттиск новой печати. После чего, уплатив задолженности перед банком, удалось закрыть счет, проигнорировав задолженности пришедшие на счет от контролирующих органов(Впрочем которые позже пришлось улпатить, однако на тот момент пренебрежение данным моментом позволило продвинуться в закрытии) Оповещен госвестник. --------------------------------------------------------------------------------- Второй этап. Срочная выписка из ЕГРЮЛ стоит 400 рублей, либо бесплатно в течении рабочей недели. Действительна нотариально в течении двух недель. Нужна для заверения Формы 15001 нотариусом. Услуга нотариуса у меня на тот момент 1000рублей. Нотариус потребовал Устав и Документ учредителя. Заверять необходимо !!!Подпись учредителя!!! Заверяем подписью в трех экзеплярах от камерального инспектора ликвидационный(Нулевой, у меня. Т.е. в пассиве только Уст.Капитал и там же Нераспределенная прибыль или непокрытый убыток, для баланса)баланс. Сдали форму 15001 и баланс в одно окно экземпляр, заверенный камеральным инспектором. Там нам поставили печать на двух других балансах. И два баланса заверенных туда, куда сдаем все документы по ликвидации. Сказали через неделю подойти со справкой из ПФР об отсутствии задолженностей. В ПФР заодно забежал в справочном заполнил бланк, где указал что мне надо получить справки и сверку. Там так же сказали подойти через неделю, забрать сверку. И зашел к своему инспектору. Проверил что ничего на меня нет. Она мне сделала на перед отчетность за квартал =) Может надо еще сверку из ФСС? Ждем ответа из Налоговой. За день до ответа попросили принести еще "Утверждение промежуточного ликвидационного баланса",

Какую максимальную нагрузку может выдержать сервер/CMS?

Заметка. Нагрузка считается в хитах (запросах), т.е. просмотрах страниц. 1000 пользователей ~ 5000 запросов в сутки ~ 1 запрос в 17 секунд. Это маленькая нагрузка. В среднем запрос во многих CMS обрабатывается за 0.05-0.5 секунды на обычном хостинге. Если больше, то либо кривая система, либо слишком большой объем данных. Если собственный сервер или VPS/DDS, то при использовании оптимизации, двухуровневой архитектуры веб-сервера, прекомпилятора и прочих фич, скорость работы может быть до нескольких сотен запросов в секунду. Joomla и многие другие open-source CMS обладают слабыми инструментами оптимизации, так как в первую очередь ориентируются на некоммерческие сайты с большим функционалом и некритичны к нагрузкам. Коммерческие системы и развитые open-source CMS обладают механизмами регулирования нагрузки, развитого кэширования, например, Drupal. 40 тысяч хостов в сутки - это примерно 200 тысяч хитов. Такую нагрузку могут выдержать многие CMS при наличии хорошего железа (средненький сервер на базе современного процессора, 1-2 Гб оперативной памяти). В CMS должно быть развито кэширование. Также увеличению производительности могут поспособствовать наличие прекомпилятора, веб-сервера под статику, использование быстрого memcached, оптимизация работы СУБД и прочие фенечки. При больших нагрузках большое значение имеет веб-сервер, база данных и общая архитектура системы. Диаметрально противоположные варианты развития событий: CMS может создавать статические страницы, которые потом отдаются веб-сервером. Но он может не справиться (если 2000 хитов в секунду). Можно поставить кеширующий сервер [1] или [2] и еще дополнительно организовать балансировку нагрузки в сочетании с очень тормозными движками. И все будет летать. Тут уж больше вопросы к проектировщику решения в целом и админу. Однако замечу, что "предел" живучести примерно такой (на моем выделенном сервере): чистый html + картинки под апачем: 800-1000 хитов в секунду Простенький скрипт php 4 + соединение с базой pconnect: 400-500 хитов То же самое просто mysql_connect: около 200 хитов Ну а дальше, если навороченная выдача товаров и т.п.: примерно 10-15 хитов в секунду предел, с оптимизацией до 50.