Разница между заголовками и URL огромная:
1) При передаче в URL простой копипаст ссылки отдаёт SID
2) При передаче в URL в логах вебсервера, прокси, клиента, и различных трекерах текущего сайта SID светится
Поэтому да, передача только в куках лучше, чем передача в URL.
Не нужно взламывать сервер. Достаточно, например, иметь сайт на том же shared тазике, когда файлы сессий разных сайтов не изолированы друг от друга.
Зачастую файлы сайтов изолированы, а вот сессии нет.
Во-1х, md5 уже небезопасный. Из него можно получить как пароль (в случае простых паролей), так и просто сгенерировать строку, которая подойдёт под нужный md5 хеш.
Во-2х, безопасность хранения пароля в сессии не стоит просто потому, что ему там неоткуда взяться. Пароли сверяются с базой пользователей, в которой уже как раз пароли не должны храниться открытым текстом — именно поэтому это вообще не к месту.
В-3их, хранение любых данных в сессии относительно безопасно, если сессии хранятся только памяти и только на своём сервере, во всех остальных случаях следует учесть, что существуют способы «угадать» или пробраться к файлу сессии (особенно на shared хостингах неудачных) из другого проекта, и потому данным сессии доверять вообще не особо-то можно
решает какую-то несусветную фигню, чесслово. То есть если IP нормальный, то мы делаем redirect на другой файл.А что, тот файл не должен проверять? :) Если уж ограничиваем по IP, то так:
// in admin.php
if(!in_array($_SERVER['REMOTE_ADDR'],$ip_white_list))
{
die('ACCESS DENY!');
}
Что именно не вышло? DROP DATABASE имеет геморрой только если innodb, там придётся еще ручками транзакцию откатывать.
MyISAM (жалких 16 гигов) восстановились на ура :)
carlo17.home.xs4all.nl/howto/undelete_ext3.html
С помощью вот этого в одной онлайн-игре при мне воскрешали состояние игры, когда в апдейт скрипт затесалась досадная опечатка после drop database;
Восстанавливаются файлы на диске. Через отмену транзакции диска в ext3.
Главное — быстро выключить сервер, желательно проводом из розетки.
Потом вытаскивается винт и всё восстанавливается. Потерь около 0.
Во-1х, воскрешать программный проще — ты знаешь как он функционирует, и можно спокойно снять образа дисков и восстановить данные, не полагаясь на метод втыка или какие-то левые проприетарные софтины которые хз дадут ли результат
Во-2х, ядро ушло в панику, перед этим сбросив кеш. На программном рейде я получил рассинхронизованное зеркало, которое после перезагрузки сребилдилось и всё.
На аппаратном зеркале я получил кашу на диске, откуда долго и нудно выковыривал нужные данные.
В-3их, вот коммент выше — аппаратные имеют привычку пропадать с горизонта, в случае помирания — влип в жир ногами по полной программе.
В-4ых, многие «аппаратные» это выносной калькулятор, без драйверов бесполезная вещь.
Всё-таки, в реальных случаях лучше использовать нормальные решения по парзингу, а не рекурсивный спуск. Мне до сих пор стыдно за то, что в DN OSP используется мой старый вычислитель на базе рекурсивного спуска :(
Из хорошего могу сказать, что я не нашел (или просто не в ту позу ставил?) ни одного бриджа Sip<=>H323 с поддержкой видео.
Ни YATE, ни freeswitch, ни (тем более) asterisk с задачей не справились.
1) При передаче в URL простой копипаст ссылки отдаёт SID
2) При передаче в URL в логах вебсервера, прокси, клиента, и различных трекерах текущего сайта SID светится
Поэтому да, передача только в куках лучше, чем передача в URL.
Не нужно взламывать сервер. Достаточно, например, иметь сайт на том же shared тазике, когда файлы сессий разных сайтов не изолированы друг от друга.
Зачастую файлы сайтов изолированы, а вот сессии нет.
Во-2х, безопасность хранения пароля в сессии не стоит просто потому, что ему там неоткуда взяться. Пароли сверяются с базой пользователей, в которой уже как раз пароли не должны храниться открытым текстом — именно поэтому это вообще не к месту.
В-3их, хранение любых данных в сессии относительно безопасно, если сессии хранятся только памяти и только на своём сервере, во всех остальных случаях следует учесть, что существуют способы «угадать» или пробраться к файлу сессии (особенно на shared хостингах неудачных) из другого проекта, и потому данным сессии доверять вообще не особо-то можно
В-4ых, Код вот этот:
решает какую-то несусветную фигню, чесслово. То есть если IP нормальный, то мы делаем redirect на другой файл.А что, тот файл не должен проверять? :) Если уж ограничиваем по IP, то так:
#1: 'CUDA-Device #1 'GeForce G102M'': 684.3 PMKs/s (RTT 2.9)
#2: 'CPU-Core (SSE2)': 397.9 PMKs/s (RTT 3.0)
Вероятно, на биологических клетках это не так, но оцифровка — таки они.
простите, а это работает?! без кавычек вокруг «ура%» ?!!!
MyISAM (жалких 16 гигов) восстановились на ура :)
С помощью вот этого в одной онлайн-игре при мне воскрешали состояние игры, когда в апдейт скрипт затесалась досадная опечатка после drop database;
Главное — быстро выключить сервер, желательно проводом из розетки.
Потом вытаскивается винт и всё восстанавливается. Потерь около 0.
Во-2х, ядро ушло в панику, перед этим сбросив кеш. На программном рейде я получил рассинхронизованное зеркало, которое после перезагрузки сребилдилось и всё.
На аппаратном зеркале я получил кашу на диске, откуда долго и нудно выковыривал нужные данные.
В-3их, вот коммент выше — аппаратные имеют привычку пропадать с горизонта, в случае помирания — влип в жир ногами по полной программе.
В-4ых, многие «аппаратные» это выносной калькулятор, без драйверов бесполезная вещь.
Ни YATE, ни freeswitch, ни (тем более) asterisk с задачей не справились.