Что означает время сессии истекло в вк
Что делать если в вк появилась надпись сессия истекло и моя стр убралась, а я не помню пороль?
Чтобы восстановить вашу учетную запись Вконтакте, потребуется на главной странице сайта нажать на кнопку «Забыли пароль» в лево верхнем углу под полем под логином и паролем. Дальше Вам нужно будет ввести id своего аккаунта, например можете попросить, чтобы Ваш друг посмотрел его. После этого нужно будет заполнить по максимуму открывшуюся анкету.
—————————————
Что делать, если я забыл пароль?
Есть несколько вариантов решения проблемы:
1. Если ваша страница привязана к актуальному номеру телефона, можно изменить пароль здесь: vk.com/restore
2. Если ваша страница не привязана к номеру телефона или номер недоступен, придётся обратиться в службу восстановления доступа: vk.com/restore?act=return_page
3. Если у вас подключена функция подтверждения входа (двухфакторная аутентификация), также поможет ссылка vk.com/restore?act=return_page
4. Если вы заходите на сайт автоматически, значит, браузер хранит ваш пароль. Попробуйте заглянуть сюда:
— Mozilla: Настройки → Защита;
— Chrome: скопируйте chrome://settings/passwords в адресную строку браузера и нажмите Enter;
— Opera: скопируйте opera://settings/passwords в адресную строку браузера и нажмите Enter.
Что значит «Время сессии истекло»: топ-3 причин
Узнаем, что значит ошибка «Время сессии истекло» и как её устранить…
Обычно сообщение «Время сессии истекло» появляется в браузере Google Chrome.
Даже если скорость интернета достаточная, ошибка сессии может доставать немало проблем. В чем же её причина?
Самые частые причины ошибки
Если в браузере появилась ошибка «Время сессии истекло», проверьте следующие моменты:
Если ничего не помогло — перезагружаем систему. Затем очищаем кэш, историю и куки браузера.
Попробуйте открыть проблемную страницу через Microsoft Edge или другой браузер
Тайм-аут браузера
Часто ошибку «Время сессии истекло» можно решить просто обновив страницу. Для этого нажмите клавишу F5.
Чтобы увеличить время сессии на сайте нужно отметить чекбокс «Запомнить меня на этом устройстве». Как правило, этот чекбокс появляется на странице авторизации.
Ошибка сессии истекло в социальных сетях
Некоторые пользователи связывают появление ошибки «Время сессии истекло» со взломом и невозможностью входа в личный профиль на Facebook, ВКонтакте, Одноклассники. Но это крайне сомнительно. Ведь в 99% случаев ошибка появляется при возникновении проблем на стороне пользователя.
Слишком медленное взаимодействия с формами страницы
Иногда ошибка появляется в случаях, когда пользователь слишком медленно заполняет контактные формы на странице (дольше 5 минут).
Если ошибка сессии появляется в игре, то нужно выйти из неё и проверить стабильность интернет-подключения
Если все ок — перезагрузите систему и запустите игру заново.
Резюме
Разобравшись, как устранить ошибку «Время сессии истекло» можно продолжить использование сайта в привычном режиме.
Что значит время сессии истекло в ВК: причины и что делать?
Время сессии истекло ВКонтакте – проблема, с которой иногда сталкиваются пользователи. Редакция нашего сайта решила разобрать данную ошибку в рамках отдельного материала. В статье мы напишем о ее вероятных причинах и вариантах устранения.
Что означает в ВК «Время сессии истекло»?
Почему сайт ВК выдает сообщение «Время сессии истекло»? В открытых источниках нет точного ответа на этот вопрос. Но на основании типичных ошибок на страницах, можно назвать несколько причин:
Время сессии истекло в ВК – это сообщение, которое появляется при регистрации, авторизации и просто при посещении различных разделов на сайте. Вероятно, страница грузится дольше, чем максимальная продолжительность бездействия пользователя. Искать причину и устранять ее необходимо последовательно, возможно, придется обращаться за помощью в поддержку.
Что делать, если ВК пишет, что время сессии истекло?
Ваши действия при возникновении данной ошибки следующие:
Наша инструкция не смогла вам помочь? Тогда необходимо обратиться в поддержку социальной сети. Специалисты ВК выполнят проверку, предложат наиболее подходящие способы для устранения ошибки.
Продолжительность ожидания ответа от сотрудника соцсети составляет до одного дня. Возможно, потребуется предоставить специалисту дополнительную информацию: версию ОС, тип используемого браузера, измеренную скорость интернета и т. д.
Сессия устарела что делать
Пока набрал прошлый вопрос эта хрень 3 раза сказала что сессия устарела и надо снова вводить какие-то цифры. Ну ладно — преувеличиваю. Цифры вводил только два раза. Первый раз достаточно было поставить галку. На этом вопросе тоже один раз потребовало кликнуть, а потом еще раз кликнуть и ввести цифры. Иннофации и баНанотехнологии в действии?
Почему сессия так быстро устаревает? В чем тайный смысл такого быстрого забывания, что я не робот?
На этот раз, чтобы зарегистрировать ICQ номер или сменить пароль понадобится изменить текущее время на компьютере. Это не шутка, а вполне реальная проблема, ставшая для многих пользователей ICQ камнем преткновения.
Ошибка появляется при попытке войти на официальный сайт, зарегистрировать ICQ номер, изменить или восстановить пароль, а так же при попытке установить attach email, да практически при использовании любых сервисов на официальном сайте.
Заключается ошибка в следующем, официальный сайт www.icq.com сравнивает время на компьютере посетителя и на сервере. Если время на компьютере немного спешит, при любых действиях посетителя сайта вылетает страница с ошибкой:
Сессия устарела.
К сожалению, прошло слишком много времени.
Ссылка, которую вы используете, уже устарела
Session Over
Sorry, the response took too long.
Please try again.
Решается проблема, простой синхронизацией времени на компьютере с сервером времени в Интернете. Происходит это следующим образом (в конце статьи есть видео):
Время было успешно синхронизировано с time.windows.com
Даже если время станет не правленым, нужно пробовать использовать сервисы на www.icq.com (менять, восстанавливать пароли и прочее. ). Как только все задуманное будет сделано, можно будет поменять время на правильное.
Так как программа по смене пароля на ICQ номере «Преобразователь ICQ пароля» работает так же через официальный сайт, ошибка проявилась и в ней. Теперь что бы программа перестала выдавать в лог-фаил ошибку:
Следует проделать все, что было сказано выше. И программа вновь начнет менять русские пароли и пароли со специальными символами.
Видео-инструкция. Сессия устарела. К сожалению, прошло слишком много времени.
Время сессии истекло ВКонтакте – проблема, с которой иногда сталкиваются пользователи. Редакция нашего сайта решила разобрать данную ошибку в рамках отдельного материала. В статье мы напишем о ее вероятных причинах и вариантах устранения.
Что означает в ВК «Время сессии истекло»?
Почему сайт ВК выдает сообщение «Время сессии истекло»? В открытых источниках нет точного ответа на этот вопрос. Но на основании типичных ошибок на страницах, можно назвать несколько причин:
Время сессии истекло в ВК – это сообщение, которое появляется при регистрации, авторизации и просто при посещении различных разделов на сайте. Вероятно, страница грузится дольше, чем максимальная продолжительность бездействия пользователя. Искать причину и устранять ее необходимо последовательно, возможно, придется обращаться за помощью в поддержку.
Что делать, если ВК пишет, что время сессии истекло?
Ваши действия при возникновении данной ошибки следующие:
Наша инструкция не смогла вам помочь? Тогда необходимо обратиться в поддержку социальной сети. Специалисты ВК выполнят проверку, предложат наиболее подходящие способы для устранения ошибки.
Продолжительность ожидания ответа от сотрудника соцсети составляет до одного дня. Возможно, потребуется предоставить специалисту дополнительную информацию: версию ОС, тип используемого браузера, измеренную скорость интернета и т. д.
Подводные камни использования сессий в PHP
Приветствую, уважаемое сообщество.
Прежде всего, хочу поблагодарить за очень полезный ресурс. Не раз находил здесь множество интересных идей и практических советов.
Цель этой статьи — осветить подводные камни использования сессий в PHP. Конечно, есть документация по PHP и масса примеров, и данная статья не претендует на полное руководство. Она призвана раскрыть некоторые ньюансы работы с сессиями и оградить разработчиков от ненужной траты времени.
Самым распространенным примером использования сессий является, конечно, авторизация пользователей. Начнем с самой базовой реализации, чтобы последовательно развивать ее по мере появления новых задач.
(В целях экономии места и времени ограничимся в примерах только самими функциями работы с сессиями, вместо того, чтобы строить здесь полноценное тестовое приложение с красивой иерархией классов, исчерпывающей обработкой ошибок и прочими правильными штуками).
Примечание: Подразумевается, что базовые знания о сессиях PHP у читателя имеются, поэтому принцип работы функций session_start() и session_destroy() освещать здесь не будем. Задачи верстки формы входа и аутентификации пользователя не относятся к теме статьи, поэтому их мы также опустим. Напомню только, что для идентификации пользователя в каждом последующем запросе, нам необходимо в момент успешного входа сохранить в сессионной переменной (с именем userid, например) идентификатор пользователя, который будет доступен во всех последующих запросах в пределах жизни сессии. Также необходимо реализовать обработку результата нашей функции startSession(). Если функция вернула FALSE — отобразить в браузере форму входа. Если функция вернула TRUE, и сессионная переменная, содержащая идентификатор авторизованного пользователя (в нашем случае — userid), существует — отобразить страницу авторизованного пользователя (подробнее об обработке ошибок см. дополнение от 2013-06-07 в разделе о сессионных переменных).
Пока все понятно. Вопросы начинаются, когда требуется реализовать контроль отсутствия активности пользователя (session timeout), дать возможность одновременной работы в одном браузере нескольких пользователей, а также защитить сессии от несанкционированного использования. Об этом и пойдет речь ниже.
Контроль отсутствия активности пользователя встроенными средствами PHP
Первый вопрос, который часто возникает у разработчиков всевозможных консолей для пользователей — автоматическое завершение сеанса в случае отсутствия активности со стороны пользователя. Нет ничего проще, чем сделать это с помощью встроенных возможностей PHP. (Этот вариант не отличается особой надежностью и гибкостью, но рассмотрим его для полноты картины).
Немного пояснений. Как известно, PHP определяет, какую именно сессию нужно запустить, по имени куки, передаваемом браузером в заголовке запроса. Браузер же, в свою очередь, получает этот куки от сервера, куда помещает его функция session_start(). Если время жизни куки в браузере истекло, он не будет передан в запросе, а значит PHP не сможет определить, какую сессию нужно запустить, и расценит это как создание новой сессии. Параметр настроек PHP session.gc_maxlifetime, который устанавливается равным нашему таймауту отсутствия активности пользователя, задает время жизни PHP-сессии и контролируется сервером. Работает контроль времени жизни сессии следующим образом (здесь рассматривается пример хранилища сессий во временных файлах как самый распространенный и установленный по умолчанию в PHP вариант).
Примечание: Здесь следует отметить, что параметр session.gc_maxlifetime действует на все сессии в пределах одного сервера (точнее, в пределах одного главного процесса PHP). На практике это значит, что если на сервере работает несколько сайтов, и каждый из них имеет собственный таймаут отсутствия активности пользователей, то установка этого параметра на одном из сайтов приведет к его установке и для других сайтов. То же касается и shared-хостинга. Для избежания подобной ситуации используются отдельные каталоги сессий для каждого сайта в пределах одного сервера. Установка пути к каталогу сессий производится с помощью параметра session.save_path в файле настроек php.ini, или путем вызова функции ini_set(). После этого сессии каждого сайта будут храниться в отдельных каталогах, и параметр session.gc_maxlifetime, установленный на одном из сайтов, будет действовать только на его сессии. Мы не станем рассматривать этот случай подробно, тем более, что у нас в запасе есть более гибкий вариант контроля отсутствия активности пользователя.
Контроль отсутствия активности пользователя с помощью сессионных переменных
Казалось бы, предыдущий вариант при всей своей простоте (всего пару дополнительных строк кода) дает все, что нам нужно. Но что, если не каждый запрос можно расценивать как результат активности пользователя? Например, на странице установлен таймер, который периодически выполняет AJAX-запрос на получение обновлений от сервера. Такой запрос нельзя расценивать как активность пользователя, а значит автоматическое продление времени жизни сессии является не корректным в данном случае. Но мы знаем, что PHP обновляет время модификации файла сессии автоматически при каждом вызове функции session_start(), а значит любой запрос приведет к продлению времени жизни сессии, и таймаут отсутствия активности пользователя не наступит никогда. К тому же, последнее примечание из предыдущего раздела о тонкостях работы параметра session.gc_maxlifetime может показаться кому-то слишком запутанным и сложным в реализации.
Для решения этой проблемы откажемся от использования встроенных механизмов PHP и введем несколько новых сессионных переменных, которые позволят нам контролировать время отсутствия активности пользователей самостоятельно.
Обработка результата функции sessionStart()
В комментариях обратили внимание на то, что возврат FALSE не дает полного понимания причины ошибки, и это абсолютно справедливо. Я не стал публиковать здесь подробную обработку ошибок (объем статьи и так не маленький), поскольку это не относится напрямую к теме статьи. Но учитывая комментарии, внесу ясность.
Как видно, функция sessionStart может вернуть FALSE в двух случаях. Либо сессию не удалось запустить из-за каких-то внутренних ошибок сервера (например, неправильные настройки сессий в php.ini), либо время жизни сессии истекло. В первом случае мы должны перебросить пользователя на страницу с ошибкой о том, что есть проблемы на сервере, и формой обращения в службу поддержки. Во втором случае мы должны перевести пользователя на форму входа и вывести в ней соответствующее сообщение о том, что время сессии истекло. Для этого нам необходимо ввести коды ошибок и возвращать вместо FALSE соответствующий код, а в вызывающем методе проверять его и действовать соответствующим образом.
Теперь, даже если сессия на сервере по-прежнему существует, она будет уничтожена при первом же обращении к ней, если таймаут отсутствия активности пользователя истек. И это произойдет независимо от того, какое время жизни сессий установлено в глобальных настройках PHP.
Примечание: А что произойдет, если браузер был закрыт, и куки с именем сессии был автоматически уничтожен? Запрос к серверу при следующем открытии браузера не будет содержать куки сессии, и сервер не сможет открыть сессию и проверить таймаут отсутствия активности пользователя. Для нас это равносильно созданию новой сессии и никак не влияет на функционал и безопасность. Но возникает справедливый вопрос — а кто же тогда уничтожит старую сессию, если до сих пор ее уничтожали мы по истечении таймаута? Или она теперь будет висеть в каталоге сессий вечно? Для очистки старых сессий в PHP существует механизм под названием garbage collection. Он запускается в момент очередного запроса к серверу и чистит все старые сессии на основании даты последнего изменения файлов сессий. Но запуск механизма garbage collection происходит не при каждом запросе к серверу. Частота (а точнее, вероятность) запуска определяется двумя параметрами настроек session.gc_probability и session.gc_divisor. Результат от деления первого параметра на второй и есть вероятностью запуска механизма garbage collection. Таким образом, для того, чтобы механизм очистки сессий запускался при каждом запросе к севреру, эти параметры нужно установить в равные значения, например «1». Такой подход гарантирует чистоту каталога сессий, но, очевидно, является слишком накладным для сервера. Поэтому в production-системах по умолчанию устанавливается значение session.gc_divisor, равное 1000, что означает, что механизм garbage collection будет запускаться с вероятностью 1/1000. Если вы поэкспериментируете с этими настройками в своем файле php.ini, то сможете заметить, что в описанном выше случае, когда браузер закрывается и очищает все свои куки, в каталоге сессий какое-то время все еще остаются старые сессии. Но это не должно вас волновать, т.к. как уже было сказано, это ни коим образом не влияет на безопасность нашего механизма.
Предотвращение зависания скриптов из-за блокировки файла сессии
В комментариях подняли вопрос о зависании одновременно выполняющихся скриптов из-за блокировки файла сессии (как самый яркий вариант — long poll).
Для начала отмечу, что эта проблема напрямую не зависит от загруженности сервера или количества пользователей. Конечно, чем больше запросов, тем медленнее выполняются скрипты. Но это коссвенная зависимость. Проблема появляется только в пределах одной сессии, когда серверу приходит несколько запросов от имени одного пользователя (например, один из них long poll, а остальные — обычные запросы). Каждый запрос пытается получить доступ к одному и тому же файлу сессии, и если предыдущий запрос не разблокировал файл, то последующий будет висеть в ожидании.
Для сведения блокировки файлов сессий к минимуму настоятельно рекомендуется закрывать сессию путем вызова функции session_write_close() сразу после того, как выполнены все действия с сессионными переменными. На практике это означает, что не следует хранить в сессионных переменных все подряд и обращаться к ним на всем протяжении выполнения скрипта. А если и надо хранить в сессионных переменных какие-то рабочие данные, то считывать их сразу при старте сессии, сохранять в локальные переменные для последующего использования и закрывать сессию (имеется ввиду закрытие сессии с помощью функции session_write_close, а не уничтожение с помощью session_destroy).
В нашем примере это означает, что сразу после открытия сессии, проверки времени ее жизни и существования авторизованного пользователя, мы должны считать и сохранить все дополнительные необходимые приложению сессионные переменные (если такие существуют), после чего закрыть сессию с помощью вызова session_write_close() и продолжить выполнение скрипта, будь то long poll или обычный запрос.
Защита сессий от несанкционированного использования
Представим себе ситуацию. Один из ваших пользователей цепляет троян, который грабит куки браузера (в котором хранится наша сессия) и отправляет его на указанный email. Злоумышленник получает куки и использует его для подделки запроса от имени нашего авторизованного пользователя. Сервер успешно принимает и обрабатывает этот запрос, как если бы он пришел от авторизованного пользователя. Если не реализована дополнительная проверка IP-адреса, такая атака приведет к успешному взлому аккаунта пользователя со всеми вытекающими последствиями.
Почему это стало возможным? Очевидно, потому что имя и идентификатор сессии всегда одни и те же на все время жизни сессии, и если получить эти данные, то можно беспрепятственно слать запросы от имени другого пользователя (естественно, в пределах времени жизни этой сессии). Возможно, это не самый распространенный вид атак, но теоретически все выглядит вполне реализуемым, особенно учитывая, что подобному трояну даже не нужны права администратора, чтобы грабить куки браузера пользователя.
Как же можно защититься от атак подобного рода? Опять-таки, очевидно, ограничив время жизни идентификатора сессии и периодически изменяя идентификатор в пределах одной сессии. Мы можем также изменять и имя сессии, полностью удаляя старую и создавая новую сессию, копируя в нее все сессионные переменные из старой. Но на суть подхода это не влияет, поэтому для простоты ограничимся только идентификатором сессии.
Понятно, что чем меньше время жизни идентификатора сессии, тем меньше будет времени у злоумышленника, чтобы получить и применить куки для подделки запроса пользователя. В идеальном случае для каждого запроса должен использоваться новый идентификатор, что позволит свести к минимуму возможность использования чужой сессии. Но мы рассмотрим общий случай, когда время регенерации идентификатора сессии устанавливается произвольно.
(Опустим ту часть кода, которая уже рассмотрена).
Итак, при создании новой сессии (которое происходит в момент успешного входа пользователя), мы устанавливаем сессионную переменную starttime, хранящую для нас время последней генерации идентификатора сессии, в значение, равное текущему времени сервера. Далее в каждом запросе мы проверяем, не прошло ли достаточно времени (idLifetime) с момента последней генерации идентификатора, и если прошло — генерируем новый. Таким образом, если в течение установленного времени жизни идентификатора злоумышленник, получивший куки авторизованного пользователя, не успеет им воспользоваться, поддельный запрос будет расценен сервером как неавторизованный, и злоумышленник попадет на страницу входа.
Примечание: Новый идентификатор сессии попадает в куки браузера при вызове функции session_regenerate_id(), которая отправляет новый куки, аналогично функции session_start(), поэтому нам нет необходимости обновлять куки самостоятельно.
Если мы хотим максимально обезопасить наши сессии, достаточно установить время жизни идентификатора в единицу или же вообще вынести функцию session_regenerate_id() за скобки и убрать все проверки, что приведет к регенерации идентификатора в каждом запросе. (Я не проверял влияние такого подхода на быстродействие, и могу только сказать, что функция session_regenerate_id(true) выполняет по сути всего 4 действия: генерация нового идентификатора, создание заголовка с куки сессии, удаление старого и создание нового файла сессии).
Лирическое отступление: Если троян окажется настолько умным, что не будет отправлять куки злоумышленнику, а сам организует отправку заранее подготовленного поддельного запроса сразу при получении куки, описанный выше метод, скорее всего, не сможет защитить от подобной атаки, потому что между временем получения трояном куки и отправкой поддельного запроса практически не будет разницы, и велика вероятность, что в этот момент не произойдет регенерации идентификатора сессии.
Возможность одновременной работы в одном браузере от имени нескольких пользователей
Последняя задача, которую хотелось бы рассмотреть — возможность одновременной работы в одном браузере нескольких пользователей. Эта возможность особенно полезна на этапе тестирования, когда нужно эмулировать одновременную работу пользователей, и желательно делать это в своем любимом браузере, а не использовать весь доступный арсенал или открывать несколько экземпляров браузера в режиме «инкогнито».
В наших предыдущих примерах мы не задавали явно имя сессии, поэтому использовалось имя, установленное в PHP по умолчанию (PHPSESSID). Это значит, что все сессии, которые создавались нами до сих пор, отправляли браузеру куки под именем PHPSESSID. Очевидно, что если имя куки всегда одинаковое, то нет возможности в пределах одного браузера организовать две сессии с одинаковым именем. Но если бы мы для каждого пользователя использовали собственное имя сессии, то проблема была бы решена. Так и сделаем.
Теперь осталось позаботиться о том, чтобы вызывающий скрипт передавал в функцию startSession() уникальный префикс для каждого пользователя. Это можно сделать, например, через передачу префикса в GET/POST параметрах каждого запроса или через дополнительный куки.
Заключение
В заключение приведу полный конечный код наших функций для работы с сессиями PHP, включающий все рассмотренные выше задачи.
Надеюсь, эта статья сэкономит немного времени тем, кто никогда особо не углублялся в механизм сессий, и даст достаточно понимания этого механизма тем, кто только начинает знакомиться с PHP.