Возможность кражи куки это не очень страшно. Все деструктивные действия (редактирование профиля, работа с деньгами и так далее) делаются с подтверждением пароля или ещё как-нибудь так.
А чтобы куку нельзя было украсть навечно, можно что-нибудь придумать. Я уже не припомню, чего мы для этого делали.
Разработчики ПО пользуются всем =)
Включая и MS Project. Здесь же не просто так его вписали =)
Мы, например, пользуемся FogBugz. Он хоть и багтрекер, но наши потребности по задачнику покрывает. Там можно ставить feature case и на дату/время и просто так.
В Нивале одна из команд Багзиллу сильно допиливали.
А вообще, какого-то одного ответа нет. Очень много компаний сами пишут. Все, кто приходил к нам на собеседование, использовали самописное ПО. Начиная от каких-то команд Luxoft, заканчивая небольшими командами.
Я ещё ни разу не слышал об идеальном продукте для разработчиков ПО.
Это меня глючит или в тексте действительно нестыковка?
В течение анализируемого года соотношение количества платежей за товары и за услуги не изменилось. Платежи за товары составляли 4% от общего количества платежей как в июне 2006 года, так и в июне 2007 года.
и
Соотношение размеров платежей за товары и за услуги изменилось незначительно. Если год назад за товары было заплачено 5% от всего объёма платежей, то сейчас — 6%.
В стоящих рядом абзацах написано прямо противоположное про одно и то же.
Это самая простая схема масштабирования и ею лучше не пользоваться =)
Потому что рано или поздно наступит момент, когда обновление информации будет занимать слишком много времени.
Количество соединений никак на производительность не влияет, если измеряется десятками. Почти везде есть пулы соединений, так что соединения не устанавливаются на каждый запрос новые. Как здесь может помогать Циска, я не представляю =)
Центральный сервер нужен только тогда, когда вы готовы всё потерять одним махом =)
Единая точка отказа это плохо.
LJ JOIN рекомендуют не использовать.
Делить иногда надо не только по таблицам/сервисам, но и одну таблицу/сервис на несколько.
Существует всего два способа параллелизма - по функции и по данным. Вы упомянули только первый.
Как шифровать - по реализации не знаю, я на PHP ни строчки кода не написал.
А алгоритм простой - сначала сериализуете данные в массив байт, добавляете подпись (например, CRC32), шифруете (например, AES), кодируете в base64 и полученную строку пишите в куку.
Обратно, соответственно, декодируете из base64, дешифруете, разворачиваете в массив байт и подпись, проверяете валидность данных (для CRC32 заново считаете его и сравниваете со значением после дешифрования) и дальше продолжаете работу с данными, если они валидные. Или не продолжаете, если они невалидные.
Ага, уже понял. Заголовок сообщества почему-то ушёл из внимания, а код похож на перловый. Чтобы в следующий раз не забывал, куда пишу, в карму уже наминусовали =)
Такие вещи решаются другими средствами =)
Не давайте доступ к администрированию людям, которым не доверяете. Потому что доступ будет отрубаться уже после того, как человек напортачит и лаг в 1 час ничего не изменит =)
Ну зачем такой жесткач. Либо всё время доверять кукам, либо всё время лазить в БД.
Совместное использование неприемлемо? Сравнивайте с БД на здоровье. Но не каждый хит, а, скажем, раз в час.
Но Вы, вероятно, не об этом, да? Цифровая подпись может быть в виде CRC32, например. Цифовая подпись и сертификат, выданный в каком-нибудь Verisign, не синонимы.
Задача цифровой подписи - подтвердить валидность данных. В случае с электронным письмом, например, имеет значение не только гарантия валидности данных (неизменности текста письма), но и гарантия валидности отправителя - сертификат решает обе эти задачи.
Не мог бы =)
Во-первых, я не очень общительный и новые контакты завожу неохотно.
Во-вторых, логику я описал уже внизу, дальше фантазируйте сами. Perl я не знал, да ещё и забыл.
В-третьих, есть отличная статья.
А лучше данный метод тем, что меньше соблазнов делать абсолютно немасштабируемое приложение.
А чтобы куку нельзя было украсть навечно, можно что-нибудь придумать. Я уже не припомню, чего мы для этого делали.
Включая и MS Project. Здесь же не просто так его вписали =)
Мы, например, пользуемся FogBugz. Он хоть и багтрекер, но наши потребности по задачнику покрывает. Там можно ставить feature case и на дату/время и просто так.
В Нивале одна из команд Багзиллу сильно допиливали.
А вообще, какого-то одного ответа нет. Очень много компаний сами пишут. Все, кто приходил к нам на собеседование, использовали самописное ПО. Начиная от каких-то команд Luxoft, заканчивая небольшими командами.
Я ещё ни разу не слышал об идеальном продукте для разработчиков ПО.
и
В стоящих рядом абзацах написано прямо противоположное про одно и то же.
Потому что рано или поздно наступит момент, когда обновление информации будет занимать слишком много времени.
Количество соединений никак на производительность не влияет, если измеряется десятками. Почти везде есть пулы соединений, так что соединения не устанавливаются на каждый запрос новые. Как здесь может помогать Циска, я не представляю =)
Центральный сервер нужен только тогда, когда вы готовы всё потерять одним махом =)
Единая точка отказа это плохо.
Делить иногда надо не только по таблицам/сервисам, но и одну таблицу/сервис на несколько.
Существует всего два способа параллелизма - по функции и по данным. Вы упомянули только первый.
Люди на Мейле или на Фишках плюсовали бы будь здоров за такое!
А алгоритм простой - сначала сериализуете данные в массив байт, добавляете подпись (например, CRC32), шифруете (например, AES), кодируете в base64 и полученную строку пишите в куку.
Обратно, соответственно, декодируете из base64, дешифруете, разворачиваете в массив байт и подпись, проверяете валидность данных (для CRC32 заново считаете его и сравниваете со значением после дешифрования) и дальше продолжаете работу с данными, если они валидные. Или не продолжаете, если они невалидные.
Не давайте доступ к администрированию людям, которым не доверяете. Потому что доступ будет отрубаться уже после того, как человек напортачит и лаг в 1 час ничего не изменит =)
Совместное использование неприемлемо? Сравнивайте с БД на здоровье. Но не каждый хит, а, скажем, раз в час.
Но Вы, вероятно, не об этом, да? Цифровая подпись может быть в виде CRC32, например. Цифовая подпись и сертификат, выданный в каком-нибудь Verisign, не синонимы.
Задача цифровой подписи - подтвердить валидность данных. В случае с электронным письмом, например, имеет значение не только гарантия валидности данных (неизменности текста письма), но и гарантия валидности отправителя - сертификат решает обе эти задачи.
Про плейсхолдеры - это кто по что горазд. Обычно они вопросами вставляются в запросы. Вероятно, терминология в разных фреймворках различается.
Во-первых, я не очень общительный и новые контакты завожу неохотно.
Во-вторых, логику я описал уже внизу, дальше фантазируйте сами. Perl я не знал, да ещё и забыл.
В-третьих, есть отличная статья.
А лучше данный метод тем, что меньше соблазнов делать абсолютно немасштабируемое приложение.