0. у вас ошибка, именя переменных $obj и $odj
1. слеши перед AppC не нужны
2. потестил малость, вывод следующий: когда мы конкатенируем псевдоним, получаем ошибку Class not found, если же прописать сразу namespace, все ОК. Почему так, не знаю.
$tag='какой-то текст <span id="blbla" class="span">потом идет спан, a внутри еще и <a href="inedx.php">ссылка</a> есть</span> ну и дальше опять текст';
Ну только смысл тогда вобще регулрку использовать... Если мы так формируем массив, то сразу в теле и ищем эти кусочки в строке пароля. Кстати, вы забыли про этиже строки, но в реверсе.
Вобщем, я так и не придумал как это сделать в регулярке, кроме тупого перечисления вариантов.
Зато вот наваял класс, для проверки пароля, удовлетворяет всем поставленым условиям, плюс я еще от себя добавил проверку на присутствиие хотя бы одной цифры.
Оформил в виде класса, но можно конечно и в функцию все запихать.
В том классе речь никогда не шла о красоте. Речь шла о том, чтобы работало.
Так я ж не спорю, все работает. Просто руками я напишу туже регулярку на много меньше и красивее. А вот код написать, который бы генерировал такой же результат как я руками пишу, у меня увы не получилось...
или же нужно проверять и такие как sdfg || werty || bcdef ?
Проверять нужно все. Видите любую последовательность на клавиатуре больше 2 символов, либо тоже самое, но в алфавите. Вот их не должно быть. Вот как этот момент организовать я пока не придумал, разве что тупо перечислением через или, но как-то многовато получится (Добавление)
teddy пишет:
Спасибо! я так понимаю | это как OR ? Т.е одно или другое?
Да. (Добавление)
teddy пишет:
Я тут всем надоем
Да не, нормально. Я и сам не против лишний раз в регулярках покопаться. Нравятся они мне почему-то
Вот только у тебя там прописан ручками SID. Подумай, где ты в реальной жизни брать будешь?
Вот если б вы читали, что пишут другие, то заметили б, что ID сессии пользователя пишется в базу. При удалении сначала зачитываем этот ID, потом грохаем запись в таблице.
Squirrel пишет:
То, что будет читаться файлик при каждом просмотре страниц с сессией, это нет ни что.
Размером он будет не больше килобайта, и жить будет в ОЗУ (в дисковом кеше).
Какая разница, какого он будет размера и где лежать. Сами подумайте, так мне нужно стартануть сессию и посмотреть, есть ли в ней запись, ну скажем token. Если есть - авторизуем пользователя. Все...
И теперь ваш вариант, стартуем сессию, смотрим, есть ли token, авторизуем пользователя, зачитываем файл, десериализуем, проверяем есть ли в нем этот ID, если есть, грохаем сессию, соответственно права пользователя нужно обновить, удалить этот ID из файла, сериализовать, записать обратно... Дохрена действий и так каждый раз...
Squirrel пишет:
Чисто теоретически, даже если есть протухший файл сессии, получить данные в нем содержащиеся нельзя.
С каког это перепуга? Специально для таких упертых как вы попробовал. Скопировал sess_id файла за 12 июля (ну предположим, что я записал это значение из куки когда-то). Теперь пишем куку с этим ID и вуаля, сервак возобновляет эту сессию. Естественно со всеми данными что в ней были.
Squirrel пишет:
И с уверенностью могу сказать, что у тя аппач под виндой стоит.
И что дальше? Это вобще никак к вопросу не относится.
ну это по идее, на практики же лежит себе спокойно больше месяца
caballero пишет:
в этом плане удобно держать сессии в БД или мемкеше
и прибивать кроном
т.е. реализовывать свой механизм сессий...
Кстати, я выяснил причину такой живучести сессионных файлов. Оказывается в PHP5.5.0 значение директивы session.gc_divisor равно 1000. Вобщем GC запускался крайне редко.
Ради эксперимента прописал ini_set('session.gc_divisor', 100), раз 30 обновил страницу, не запустился, поменял на 10, с шестого обновления запустился, стер все кроме текущей сессии.
Для реального проекта, думаю 100 в самый раз. Хотя с хорошей посещаймостью и 1000 будет вполне нормально...