К тому же, что вы так этих двух запросов к базе при удалении пользователя боитесь, что готовы на каждый запрос дергать файл и искать в нем айдишник?
Не я боюсь, а ты. Я бы вообще такой фигней не страдала, по тому, так считаю, что хранение данных в сессии, не факт, что даст прирост производительности. А вот проблем добавит.
Саныч пишет:
Передаем только userID. Получили, зачитали sessID, запустили сессию, очистили ее, удалили юзера из БД. Два запроса, где вы третий выкопали, я не понимаю.
А из самой базы кто удалять/(помечать, что удаленный) будет?
Саныч пишет:
Так что ж вы с нами, рукожопыми, тут возитесь, а?!
Да жалко мне вас рукожопых просто.
Hapson пишет:
Товарищи, ну тема так и не раскрыта. Как поддерживать авторизацию и корректно удалять/банить пользователя? При этом не трогая БД при простой навигации по сайту.
Ну ты определись. При простой навигации, считай что это гость, и проблемы не будет.
А вот когда пользователь запросит что-то секретное, вот тогда и дерни БД, и проверь его статус. Не бойся ты этих запросов. И при "простой навигации" сессии - это зло.
Hapson пишет:
При следующем входе обновляем поле session. Если пользователь входит по куке, то делаем тоже самое - обновляем session_id в базе.
Что значит "входит по куке"? Типа ты пользователю вешаешь куку позволяющую его опознать в твоей БД, как это сделано на этом форуме например?
То есть он входит, кука пользователя есть, а куки сессии нет, я правильно поняла?
Тогда, да, ты прав. Подумай еще о такой фигне, что пользователь одновременно зашел с сразу с браузеров/с различных профилей. Будет две сессии на одного пользователя.
Hapson пишет:
Неужели нет иного способа реализации статуса кроме записи и сравнения времени? Ведь это опять запрос к БД при каждом запуске скрипта.
А как ты еще определишь? Есть время запроса чего-либо пользователем. Что дальше делает пользователь, без телепата ты никак не узнаешь. По этому и единственный вариант, хранить время последнего действия. И если оно меньше определенного значения, то считаешь, что пользователь в онлане, хотя он может давно и компьютер то выключил и мирно пьет пиво у подъезда.
Hapson пишет:
В базу пишется session_id, в базу пишутся сессионные данные... так? Зачем? А как удалять данные при выходе пользователя, если он просто закрыл окно?
Никак. Или писать собственный сборщик мусора. Но для этого как минимум Shell нужен.
Да и не стоит тебе этим заморачиваться.
термин сессия вполне понятен (тем кто в теме) и не зависит от контекста
Вот в данном контексте лично мне он как раз и не понятен. Если ты такой умный, то объясни, что такое в данном контексте "сессия", если это не кука, не содержимое куки, и не файл, то тогда что?
caballero пишет:
не факт - сериализуешь туда класс а он тянет за собой все остальные по ссылке
А зачем засовывать туда весь класс?
caballero пишет:
у меня апач под виндой больше десяти лет. не вижу никаких проблем и никакой то разницы с другими местами стояния.
А я например вижу. Как тут сказали, "тем кто в теме" разница очевидна. Ссылочку то почитай, там как раз разжевано. (Добавление)
Саныч пишет:
Вот если б вы читали, что пишут другие, то заметили б, что ID сессии пользователя пишется в базу. При удалении сначала зачитываем этот ID, потом грохаем запись в таблице.
Ты теоритизировать то брось, а просто прикинь как это будет работать в реале. Если грубо, ты формируешь страничку admin.php , на которой выводишь логин пользователя/(или что ты там хочешь), и рядышком кнопочку "удалить". Я правильно поняла твою задумку?
Теперь опустимся до реальной жизни. Кнопочка будет снабжена ссылочкой, типа:
/user_del.php?UID=$UID&SID=$SID.
Сразу вопрос. Ты так печешься о безопасности. На сколько такая страничка будет безопасна в реальной жизни? Если ты передаешь только один параметр, то тебе придется по любому получать второй из БД Это первое обращение. Что бы удалить пользователя, из BD, тебе придется дернуть и саму БД. Это уже второе обращение. Ну и каким-то образом прибить саму сессию, это уже третье обращение. Даже если ты передаешь все два параметра, обращений будет ДВА, а ты твердишь, что одно.
Мой же вариант, более безопасен. В user_del ты передаешь только $SID, и на странице admin, ты в открытом виде выводишь ТОЛЬКО $SID.
Второй момент. Ты должен как-то защить вызов user_del от злоумышленника и робота.
Мелкий пишет:
Докажите это хотя бы теоретически.
Саныч пишет:
С каког это перепуга?
При открытии сессии, указывается время ее жизни. Если сессия жива после указанного времени, это говорить только о рукожопости админа, настраивавшего сервер.
Мелкий: Кста, твоя ссылка не открылась.
Есть несколько решений, но все зависит от того, что внутри iframe.
Самый простой способ, внутрь Iframe вешаешь ссылку на свою страничку.
А дальше по ситуации.
Есть три метода.
1) В код внедряют ЯваСкрипт, который при изменении фокуса подсвечивает неверно заполненные поля.
2) Делают страницу регистрации, типа твоей. При создании страниц проверяют входные данные. Далее в зависимости от проверки поступают так:
A) Если входных данных нет, выводят "Типовой дизайн"
Б) Если данные есть, но они не прошли проверку, выводят "Типовой дизайн" + то что ты называешь подсветкой.
В) Если данные есть, и они прошли проверку, делаешь редирект на другую страницу.
3) С первой страницы ты отправляешь данные на вторую страницу, на которой производишь проверку введенных данных. Если данные не верны, делаешь редирект на 1ю страницу. Первую страницу формируешь как в П2.
DelphinPRO, а если такая схема. Пользователь авторизовуется, пишем в БД его sess_id. В саму сессию нужные данные. Потом, когда нам приспичит удалить пользовател, читаем это sess_id запускаем сессию с таким id и грохаем все данные в сессии, удаляем юзера из БД. Юзер заходит, сессия "пустая", авторизация не подтверждена. Все счастилвы...
Саныч пишет:
И встал вопрос, а что если пользователь авторизован и в этот момент админ его удаляет. Сессия то у него уже открыта, а в базу не лазит, т.е. не узнает что его уже нет...
DelphinPRO пишет:
1. Мы лишаемся возможности сменить права пользователю без завершения сессии.
Пяточек, ты уж определись, что ты хочешь (анекдот)
Саныч пишет:
Сессионная кука имеет некий период жизни, а не сама сессия.
В данном контексте термин "сама сессия" вообще не понятен. Есть кука, с периодом жизни. Есть файл (запись в BD) в котором хранятся данные сессии. И с уверенностью могу сказать, что у тя аппач под виндой стоит. Ссылочку почитай, что я выше давала. Там как раз и про файлы сессий, и про куки сессий, и рукожопых админах.
DelphinPRO пишет:
2. Не понятно, чем лучше обращение в двум файлам, вместо одного (файла сессии).
Тем что:
Саныч пишет:
И встал вопрос, а что если пользователь авторизован и в этот момент админ его удаляет. Сессия то у него уже открыта, а в базу не лазит, т.е. не узнает что его уже нет...
Саныч пишет:
Ну во-первых в основной базе этого ID уже нет. Мы ведь удалили пользователя.
А зачем он нужен? Он есть в БД удаленных пользователей, он есть в сессии. Наличие его в основной БД уже не требуется.
Все, что ты остальное говоришь, хорошо в теории. Код костыля ты тут привел. Вот только у тебя там прописан ручками SID. Подумай, где ты в реальной жизни брать будешь?
То, что будет читаться файлик при каждом просмотре страниц с сессией, это нет ни что.
Размером он будет не больше килобайта, и жить будет в ОЗУ (в дисковом кеше).
Саныч пишет:
Но факт в том, что подставляем в куку ID за 12 июля и вуаля, сессия более чем месячной давности возобновлена.
У тебя есть великолепная возможность проверить на практике, и рассказать результат.
Давай дискуссию на эту тему приостановим, и дождемся от тебя описания того, что получилось. Чисто теоретически, даже если есть протухший файл сессии, получить данные в нем содержащиеся нельзя.
Тонко намекни, что именно я пропустила, и почему мой совет тебе не подходит.
Саныч пишет:
То ли я дурак, то ли лыжи не едут. Т.е. вы мне предлагаете создать еще одну, отдельную, базу для пользователей?
Наверное первое. Создавать отдельную базу для пользователей, я не предлагаю.
Squirrel пишет:
Если считаешь, что это слишком медленно, то создай еще одну BD с удаленными пользователями. Эта BD будет мизерная.
В этой базе ты будешь хранить только некий ID только удаленных пользователей за очень короткий период. Остальные данные там тупо не нужны, это же очевидно.
В сессии ты этот ID и так хранишь,
В основной BD этот ID у тебя уже есть.
И что-то мне подсказывает, что ты и про сессии опять не до конца. На что тебе уже тонко намекали. Сессия имеет некий период жизни, после чего сама закрывается, и все данные из нее удаляются. Первая ссылка из гугля: http://habrahabr[dot]ru/post/28418/
DeepVarvar
1) А причем тут другое приложение?
2) Вывод: ни теорией ни практикой ты свои слова доказать не можешь. Прости, но тогда на основании чего ты сделал такое заключение, если по факту оказалось, что в данном вопросе ты не компетентен.
Не нашла раздела подходящего для моего вопроса.
Пришлось встраивать рекламные блоки от Google Adsense.
Мягко говоря в очередной раз убедилась в рукожопости программеров из гугля.
По этому вопрос, если я засуну рекламные блоки гугля в iframe, и потом простеньким ява скриптом буду туда эти блоки засовывать, гугль не обидеться?
Понимаю, что для его ботов придется делать специальный вариант странички, но это не проблема.
И что-то мне подсказывает, что о ревалентности рекламы придется, чего очень не хотелось бы.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 147
