Сессия имеет некий период жизни, после чего сама закрывается, и все данные из нее удаляются.
Сессионная кука имеет некий период жизни, а не сама сессия. Об этом вам уже LIME написал. Для примера, я специально залез в папочку с файлами сессий на своем домашнем серваке. Самый древний файл там еще за 12 июля!
Squirrel пишет:
В этой базе ты будешь хранить только некий ID только удаленных пользователей за очень короткий период. Остальные данные там тупо не нужны, это же очевидно.
В сессии ты этот ID и так хранишь,
В основной BD этот ID у тебя уже есть.
Ну во-первых в основной базе этого ID уже нет. Мы ведь удалили пользователя.
К тому же при такой схеме прийдется каждый раз для каждого пользователя, при каждом запросе зачитывать этот файл и смотреть там его ID. При том что сессию мы так же используем каждый раз. В сессии по любому будет хранится какая-то запись нужная для подтверждения авторизации пользователя. А так мы очистили его сессию. Пользователь заходит, а этой записи нет, его сразу и выкинет...
Так, наверное, можно и модифицировать данные, не завершая сессию? Например, админ повысил\понизил пользака в правах.
А почему нет. Мы ж ее стартуем, а дальше делаем что хотим. При следующем запросе у пользователя будут новые права, без всяких перезаходов и дергания БД.
Squirrel пишет:
Причем под BD я понимаю именно BD, а не только то, что создают MySql или прочие.
То ли я дурак, то ли лыжи не едут. Т.е. вы мне предлагаете создать еще одну, отдельную, базу для пользователей? Зачем?! И чем это будет быстрее?..
"Юзер заходит", проверяем, а существует ли такой юзер в BD, и если нет далее по тексту.
Так в этом и есть суть вопроса. Так нужно каждый раз делать запрос к БД. А мы тут обсуждаем, чтоб хранить данные пользователя в сессии, а в БД лезть только, когда он входит через форму или куки.
И встал вопрос, а что если пользователь авторизован и в этот момент админ его удаляет. Сессия то у него уже открыта, а в базу не лазит, т.е. не узнает что его уже нет...
DelphinPRO, а если такая схема. Пользователь авторизовуется, пишем в БД его sess_id. В саму сессию нужные данные. Потом, когда нам приспичит удалить пользовател, читаем это sess_id запускаем сессию с таким id и грохаем все данные в сессии, удаляем юзера из БД. Юзер заходит, сессия "пустая", авторизация не подтверждена. Все счастилвы...
EuGen, смотрел ваш класс. Конечно за труд вам +1, но регулярку он выдает очень большую, совсем не красивую... А на больших числах (4 и более разрядов) это особенно заметно.
Пытался сегодня написать аналог, но по-лучше. Вобщем идеала мне добится так и не удалось... Да и практической пользы от этого я не вижу. В итоге забросил эту затею.
Synov_son, ну так и выкладывайте код своей функции полностью, а не выдрали часть строки и говорите, что ничего не выводит... Все телепаты еще на югах...
то ли тоже на стороне сервера все делать, то ли
через mysql
Что не понятно то? В БД делаете таблицу специалистов, таблицу записей к этим спецам.
Выводите все это дело пользователю. Организовываете возможность выбрать день и время. Я б это сделал в виде календаря. Свободные и занятые дни/время как-то выделить по разному. Кликнули по дню, вывалился списочек с временем, кликнули по времени - полетели данные на сервак. Там уже провери, свободен ли специалист в этот день и час. Если да - добавили запись в БД, нет - показали ошибку пользователю.
Вот как-то так это можно объяснить, что называется на пальцах.
teddy, постараюсь пояснить. Да кстати, я там обновил свой ответ, последнего символа $ нет теперь, но это не принципиально, разницы никакой, просто дублирование получалось.
Теперь по порядку.
Символы ^ и $ - это начало и конец строки соответственно. Где бы они ни были, хоть в символьно классе (в квадратных скобках), хоть еще где. Если нет экранирования - это спец символы. Также как и точка, ну вы с ней уже разобрались Есть только одно исключение для символа ^, когда он не значит "начало строки", но пока опустим этот момент.
Комбинация ?: - это группировка без обратной связи. Ставится сразу после открывающейся круглой скобки. Используется если нам не нужно нигде использовать часть заключенную в этой скобке. Т.е. если идет просто группировка (просто круглые скобки), то значение, что в них попадет будет запомнено и доступно после. Это как вы проверяли части IP в своем варинте в цикле. Т.е. у вас после preg_match был массив с частями исходной строки. А вот если указать ?:, то этих частей уже не будет. Надеюсь ясно объянил. Зачем это нужно? Не занимает память, соответственно ускорение работы. С регулярками это вобще критично, т.к. они сами по себе достаточно медленные.
"волшебная палочка |" означает "или". Т.е. в моем случае выражение (?:\.|$) значит следующее: символ точка или конец стоки.
Чтоб еще понятней стало опишу, как я составлял эту регулярку по шагам.
1. Вся строка это ip адресс, т.е. от начала до конца. ок, пишем
4. после каждой группы цифр обязательно должна стоять точка, но кроме последней группы, после нее должен быть конец строки, т.е. имеем: символ точка или конец строки, записываем
Вот так вот, простое разбиение на мельчайшие блоки, простая логика, по шажочкам и получилась эта страшная строка
teddy пишет:
И ещё не понял того, как данная регулярка определяет что нельзя более 255 писать в каждый кармашек
Никак не определяет Это ведь был ответ к первому заданию. Ответ ко второму пока не выкладываю, попробуйте сами решить. Дам только небольшую подсказку, изменить нужно только вот эту часть \d{1,3}
По длине же новая регулярка у меня получилась примерно раза в два больше.