Проблема с сессией: Cannot send session cache limiter - headers already sent

#php #сессия

Изначально когда проектировал сайт, работал с сессиями только на одной странице,
где объявлял session_start(); Потом понадобилось распространить эту функцию на весь
сайт. Для этого я разместил session_start() в файл config.php, который в свою очередь
подключается к каждому файлу php сайта. Вот тут-то и возникли проблемы...

Структура сайта такова (заголовочные файлы):


config.php
header.php
left.php
footer.php


Эти файлы подключаются к каждой странице сайта.
А страницы разбиты по категориям в которых нет ошибки сессии:


index.php
shopingcart.php
contact.php


И файлы в которых ошибка возникает:


faqs.php
productdetail.php
checkout.php


Как можно побороть ошибку данную? 


  Warning: session_start() [function.session-start]: Cannot send session cache limiter
- headers already sent (output started at
  S:\home\localhost\www\web_shop\faqs.php:1) in
  S:\home\localhost\www\web_shop\config.php on line 2

    

Ответы

Ответ 1

Ошибка говорит о том, что функция не может установить заголовки ответа HTTP, так
как уже был вывод данных в тело ответа.
Функция header (которую в свою очередь вызывает session_start) может использоваться
только до вывода тела ответа.
Чтобы исправить ошибку разместите подключение config.php в самом начале текста файла.
Если это не помогло или так и есть уже, то пересохраните файл без BOM.


Ответ 2

Может кому то и поможет!
Открыл файл в Notepad++ и сохранил его с кодировкой UTF-8 без BOM. 
И перезалил файл на хостинг. 
После обновление страницы, предупреждение исчезла! 
Спасибо всем за наводку :)


Ответ 3

Благодаря помощи, товарища ToRcH565 удалось исправить эту ошибку. Дело было в том,
что я писал 

Как удалить запись массива из сессии - PHP

#php #массивы #сессия

есть вот такой массив в котором лежит 3 товара и передается через $_SESSION['shopping_cart'][]:

    array(3) {
  [0]=>
  array(3) {
    ["variant_id"]=>
    int(154)
    ["amount"]=>
    int(1)
    ["lvl"]=>
    int(1)
  }
  [1]=>
  array(3) {
    ["variant_id"]=>
    int(157)
    ["amount"]=>
    int(1)
    ["lvl"]=>
    int(6)
  }
  [2]=>
  array(3) {
    ["variant_id"]=>
    int(167)
    ["amount"]=>
    int(1)
    ["lvl"]=>
    int(0)
  }
}


Как мне удалить товар с variant_id = 157, то-есть весь массив [1], но я знаю только
variant_id. Буду благодарен за вашу помощь!
    

Ответы

Ответ 1

Как вариант можно через цикл:

$arr = [
    ['variant_id' => 154, 'amount' => 1, 'lvl' => 1],
    ['variant_id' => 157, 'amount' => 1, 'lvl' => 6],
    ['variant_id' => 167, 'amount' => 1, 'lvl' => 0]
];

foreach($arr as $key => $value)
{
    if ($value['variant_id'] == 157)
        unset($arr[$key]);
}

print_r($arr);


Второй вариант с помощью функции array_filter:

$id = 157;

$arr = array_filter($arr, function ($x) use ($id) {
    return $x['variant_id'] !== $id;
});

print_r($arr);


Ответ 2

Вы можете использовать, к примеру, функцию array_filter и включить туда более сложную
логику, если понадобится. Ну смотрите. 

$resultArray = array_filter($sessionArray, function ($value) use ($toDelete) {
    return $value['variant_id'] !== $toDelete
});


Объяснение: $sessionArray ваши исходные данные, а $toDelete значение, которое нужно
отбросить. Соответственно, вы можете оформить анонимную функцию отдельно и использовать
многократно передавая то, что вам нужно удалить, а если быть точнее, то в данном контексте
вы фильтруете свой ассоциативный массив, оставляя что вам нужно. Вы можете передать
в use, например, еще одно значение, которое будет являться ключом, который вам нужно
будет отфильтровать и тогда сможете этой функцией, передавая ей соответствующие значения,
добиваться фильтрации любых полей по заданным значениям.


Ответ 3

Можно через поиск:

$arr = [
    ['variant_id' => 154, 'amount' => 1, 'lvl' => 1],
    ['variant_id' => 157, 'amount' => 1, 'lvl' => 6],
    ['variant_id' => 167, 'amount' => 1, 'lvl' => 0]
];

$id = 157;

if(($key = array_search($id,array_column($arr, 'variant_id'))) !== FALSE){
    unset($arr[$key]);
}


Будет быстрее, чем filter

Особенности $_SESSION php

#php #сессия

Насколько безопасным является использование сессий в php? 

Безопасно ли делать авторизацию пользователей через сессии на php? Является ли кука
phpsessionid httpOnly? Какое время жизни сессии в php по умолчанию? 
    

Ответы

Ответ 1

Насколько безопасным является использование сессий в php? Безопасно ли делать авторизацию
пользователей через сессии на php? 

Ответ: Да, безопасно (см. http://php.net/manual/ru/session.security.php)


  "Работа с HTTP сессиями является основой web безопасности."






Является ли кука phpsessionid httpOnly? 

Ответ: По умолчанию - нет. 
Вы можете изменить это, задав свойство: session.cookie_httponly.

Пример:
ini_set('session.cookie_httponly', 1)





Какое время жизни сессии в php по умолчанию?

Ответ: (см. http://php.net/manual/ru/session.configuration.php#ini.session.cookie-lifetime)


  По умолчанию кука будет валидна до закрытия браузера

Авторизация и сессии в django и piston

#сессия #pymongo #django

Доброе время!
Имею urls.py:
auth = JSONAuthentication()
user_handler = Resource(UserHandler, auth)

urlpatterns = patterns('',
    url(r'^login/$', user_handler, { 'emitter_format': 'json' }),
)

Авторизация работает как. Сначала challenge 401, отправляю username и password, request.user
устанавливается какой нужно. дальше в handlers.py:
class UserHandler(BaseHandler):
    allowed_methods = ('POST',)
    def create(self, request):
        auth.login(request, request.user)
        return {u'user':unicode(request.user)}

т.е. делаю login, django в auth.login пишет request.session['_auth_user_id']=user.id,
далее оно сохраняется в базу сессий.
С этим всем хозяйством разобрался, отдебажил. Дальше в браузере жму F5, ожидаю, что
сессия (длиной в неделю) сохранится и request.user заполнится по имеющейся сессии...
Срабатывает опять авторизация, в авторизации предварительно ищу юзера в сессии:
class JSONAuthentication(object):
    ....
    def is_authenticated(self, request):
        user = auth.get_user(request)
        ....

И вот тут оказывается, что auth.get_user ищет в сессии request.session['_auth_user_id'],
которой там нет, и отваливается. В сессии на этот момент есть только sessionid=<правильная
сессия>, по которой надо получить сессию из базы - по коду оно дальше - и там уже user_id
будет и проч...
Вот я думаю, либо неправильно что-то делаю, либо что-то не допилил.
ЗЫ используется связка python 2.7, django 1.3, piston (rest), pymongo (база), mango
(хранение сессий и юзеров в mongodb)
UPD Проблему решить удалось, осталось выяснить чей косяк. Мой или pymongo :)    

Ответы

Ответ 1

Проблему удалось решить двумя способами.

Сложный. Проблема была в том, что сессия не восстанавливалась (обращение в auth.get_user
к request.session['_auth_user_id'] вызывало восстановление сессии). При восстановлении
возникало исключение UnicodeEncodeError в pymongo'вском bson.Objectid, который pymongo
не обрабатывают (обработывается только UnicodeDecodeError, т.е. зеркальный эксепшин).
Добавление в __setstate__ дополнительного UncodeEncodeError в секцию except решало
проблему. Написал краткий тест с минимальными вызовами для выявления бага, в шелле
он отрабатывал как надо, а в eclipse при отладке в частности валился, притом молчаливо
- except перекрывал исключение, но не обратывал его. Пытался даже с pymongo'вцами разобраться,
у них тоже в шелле все прекрасно работало. Оттуда выяснился более простой метод "исправления".
Простой метод основан на том, что pydev в eclipse при старте приложения устанавливает
свои параметры консоли, в частности меняет дефолтную кодировку (которая указывается
в настройках pydev'а). Из-за нее-то и возникала проблема. У меня стояла в настройках
cp1251, а в шелле - ascii, при которой работало все. Установил в настройках pydev'а
ascii (utf-8 тоже можно как оказалось) и все заработало. В инете много где пишут про
этот баг, мол setdefaultencoding - evil, evil, evil и в частности про pydev этим занимающийся
в частности.

Относительно pymongo, не знаю баг ли это в pymongo - то, что при одной дефолтной
кодировке работает, при другой не хочет, решать им конечно, но имхо, стоит добавить
этот злосчастный UnicodeEncodeError, хотя я видимо был бы единственным, кого это коснулось.
UPD Разработчики pymongo признали такое поведение как ошибку, связанную с кодировками,
используемыми в настройках сайта. В транк внесены изменения, убрана заглушка от ошибки
преобразования из неизвестной кодировки в latin-1. Внесена корректная проверка значения,
восстанавливаемого через pickle. 
В общем рад, что смог помочь выяснить причины, что привело к более правильному коду.

Авторизация и сессии [закрыт]

#веб_программирование #php #пароль #сессия #авторизация

        
             
                
                    
                        
                            Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы на него можно было дать ответ, основанный на фактах и цитатах, отредактировав его.
                        
                        Закрыт 4 года назад.
                                                                                
           
                
        
Подскажите, как в наше время делают авторизацию и где хранят сессии. Давно не занимался
сайтами, возможно отстал от прогресса.
Собственно:

Храню пароль в виде md5($salt.$pass.$salt). Вроде их уже легко ломают?
sessionhash=md5(uniqid(microtime()));
Сессии хранятся в таблице MySQL в sissionid, userid, sessionhash
sissionid и sessionhash отдаются в куках.

Как сейчас это делается?    

Ответы

Ответ 1

Данные, хранящиеся на стороне пользователя, надо зашифровать ключом, хранящимся на
сервере.
Тут это разбирается на примере Node.JS и для PHP: Раз и Два


Ответ 2

По пункту 1:
В настоящее время существуют очень эффективные реализации перебора хэшей. Поэтому
даже длинные пароли, подвергнутые однократному хэшированию, перестали быть безопасными.
В версии php 5.5 реализован алгоритм PBKDF2. Его рекомендууется использовать для
получения устойчивых хэшей.  http://php.net/manual/ru/function.hash-pbkdf2.php.


Ответ 3

Советую посмотреть в сторону фреймворка CodeIgniter. Всё удобно, защищено и очень
просто. + Есть библиотека аутентификации и регистрации.

Как правильно хранить сессию при разработке JSON API?

#json #api #сессия

Обычно мы храним id сессии в cockie браузера. Но допустим я хочу использовать свое
API в мобильных приложениях ios/android, и я собираюсь хранить куку в памяти приложения
и вставлять потом в каждый запрос с приложения. Но на сколько это правильно? Есть ли
какие-то советы по этому поводу?
    

Ответы

Ответ 1

Но на сколько это правильно?


Тут просто нет другого подхода. Вам так или иначе надо идентифицировать пользователя
API. По каким-либо косвенным признакам вы его идентифицировать не можете - на одном
IP могут сидеть несколько потребителей, User-Agent нет в принципе, да и вообще это
просто подменяемый заголовок и не более.

Поэтому вам надо с каждым запросом передавать некий идентификатор, который сможет
помочь вам найти пользователя. Тут есть несколько тонких моментов:


Это не должен быть сам идентификатор пользователя (иначе весь механизм ломается через
угон идентификатора, и с угнанным пользователем нельзя сделать ничего, кроме его убийства)
Этот идентификатор (или механизм, связанный с ним) должен однозначно подтверждать
корректность сессии либо передаваться исключительно по защищенному каналу (HTTPS),
иначе его можно будет ровно так же угнать и представляться некорректным пользователем.
Идентификаторы должны считаться расходным материалом в приложении: их всегда можно
грохнуть и насоздавать новых, чтобы любой угнанный идентификатор мог быть обнулен сразу
после обнаружения угона


Общепринятым подходом считается передаче токена доступа в произвольном заголовке
(github, google, amazon s3). Так или иначе информация для аутентификации всегда остается
в заголовках (в query parameters и непосредственно теле запроса ей не место), поэтому
здесь на самом деле тоже особого выбора нет. Токен хранится на устройстве, в случае
паники пользователь удаляет токен (пользуясь тем же токеном доступа)

Последний абзац - про подтверждение корректности сессии, передаваемое по незащищенному
каналу.
В случае, если есть опасения за перехват токена при его передаче - необходимо так
или иначе подписывать исходящие запросы. Для этого можно использовать полновесную или
легковесную challenge-response аутентификацию, смысл которой можно свести к тому, что
сервер и клиент загадывают друг другу загадки, которые могут разгадать только они сами.
В самом простом варианте сервер может выписывать токен, состоящий из идентификатора
и секретной части (ключа шифрования), которая однократно передается клиенту при создании
токена (клиент тоже может при этом переать некий секрет, но мы считаем, что серверу
всегда можно доверять). После этого все сообщения от клиента к серверу либо полностью
шифруются полученным ключом, либо содержат в дополнительном заголовке сформированную
на основе ключа и тела запроса подпись, которую злоумышленник не сможет подделать,
не своровав секретный ключ. Это, однако, не защищает само по себе от:


Replay-атак (e.g. если пользователь шлет запрос "удалить последнюю запись", то злоумышленник
может сгенерировать еще сотню таких запросов и полностью очистить историю пользователя).
Самое простое решение - жонглирование временными метками (e.g. не принимать запросы
старше 5 секунд), но при малейших проблемах с синхронизацией стреляет в ногу.
Физического изъятия ключа у клиента. Обычно считается, что от этого нельзя защититься,
и этот момент просто игнорируется.
Перехвата ключа в момент выписывания токена (поэтому лучше все-таки обзавестись HTTPS).
При открытом трафике можно воспользоваться алгоритмом Диффи-Хеллмана и аналогами, но
это займет времени больше, чем написание самого приложения.
Вычисления ключа при использовании некорректного алгоритма (e.g. если не происходит
ротации ключа и если злоумышленник знает, что всегда используется JSON, то он, зная,
что последний символ всегда является } или ], может вычислить ключ, сравнивая запросы
разной длины). Опять же, проще взять HTTPS, есть альтернативные методы, но я не буду
их рассказывать, чтобы ненароком не пропустить важный момент.


upd. есть некий стандарт json web token, сам я с ним пока не ознакомился.


Ответ 2

Это один из правильных подходов к разработке API. Есть такое понятие при разработке
REST API, как отсутствие состояния (statelessness, STATEless).


  Состояние клиента не хранится на сервере, ни в каком виде, этим
  занимается исключительно сам клиент


Серверы не связаны с интерфейсами клиентов и их состояниями. На стороне сервера не
сохраняется пользовательский контекст между двумя разными запросами. 

Каждый запрос содержит всю информацию, необходимую обработчику, а состояние сессии
хранится на клиенте. 

Несохранение состояния улучшает производительность Web-сервиса и упрощает дизайн
и реализацию серверных компонентов, поскольку отсутствие состояния на сервере устраняет
необходимость синхронизации сеансовых данных с внешним приложением.

Как положить в сессию не весь объект а только 3 поля?

#php #сессия

Здравствуйте

У меня в форме авторизации после всех проверок идет вот такая запись

$_SESSION['user'] = $user;


в сессию сохраняется весь объект $user, то есть логин, пароль и полностью все данные
с записи таблицы.
если записать так:

$_SESSION['user'] = $user['id'];


в сессию сохраниться только его id

Вопрос:
как сохранить в сессию id,login и image? как правильно нужно написать?

прошу помощи в реализации.
    

Ответы

Ответ 1

Например так:

$_SESSION['user'] = [
    'id' => $user['id'],
    'login' => $user['login'],
    'image' => $user['image'],
];


Ответ 2

$_SESSION['user']['id'] = $user['id']; // id юзера
$_SESSION['user']['login'] = $user['login']; // логин
$_SESSION['user']['image'] = $user['image']; // картинка


Чтобы было ясно, или ниже тоже хороший вариант посоветовали

Длительность сессии php

#php #сессия

Здравствуйте.

В php файле использую сессии session_start();, куки не использую.
Пытаюсь продлить время жизни сессии. Естественно, на хостинге файл php.ini не дают
править и советуют все настройки указывать в .htaccess там я указал строку равную трем
часам php_value session.gc_maxlifetime 10800
но сессия все равно обрывается раньше. Может что-то еще нужно прописать?
    

Ответы

Ответ 1

Помимо установки настроек session.gc_maxlifetime и session.cookie_lifetime надо учитывать
еще одну тонкость. http://kocherov.net/nyuansyi-rabotyi-php-session-gc_maxlifetime/

Если файлы сессий попадают в общую папку, где работают php скрипты с разными настройками,
то будут выполняться самые минимальные настройки из возможных. В этом случае надо хранить
файлы сессий в отдельной папке для этого сайта. 

ini_set(‘session.save_path’, value)


Ответ 2

попробуйте добавить в начале скриптов:

session_set_cookie_params(86400);
ini_set('session.gc_maxlifetime', 86400);


и проверьте, что при вызове phpinfo значение изменилось.

Расширение для Chrome в инкогнито режиме

#cookie #сессия #chrome_extension

Есть расширение для Chrome, которое делает ajax запрос на сайт. На сайте используются
сессии.

Так, вот, в ответе на ajax запрос к сайту, возвращается заголовок Set-Cookie c некоторым
идентификатором сессии и в разделе кук появляется соответсвующая запись. Речь идёт
о DevPanel фоновой страницы расширения.

Но, если посмотреть на куки в DevPanel браузера, то там совсем другой идентификатор
сессии.

Расширению разрешена работа в инкогнито режиме.

В обычном режиме браузера куки (идентификаторы сессии) в DevPanel расширения и браузера
одинаковы.

Я понимаю, что куки для обычного и инкогнито режимов должны быть разными, но почему
для расширения с разрешением работы в инкогнито режиме эти значения различаются?

Получается, что, несмотря на то, что расширению разрешено работать в инкогнито режиме,
он сам работает в обычном режиме?
    

Ответы

Ответ 1

Для всех, кого интересует данный вопрос. Решение мне подсказали на форуме для обсуждения
Google Chrome.

В manifest есть ключ "incognito", у которого три значения: "spanning" (по умолчанию),
"split" и "not_allowed".

Подробнее об этой настройке можете прочитать здесь: https://developer.chrome.com/extensions/manifest/incognito.

Решение моего вопроса, заключалось в задание значения "split". При этом значении,
для расширения в инкогнито режиме, будет создаваться отдельный процесс. Другими словами,
будет два процесса: для обычного и инкогнито режимов.

Теперь, запросы в инкогнито режиме выполняются в инкогнито процессе и сессионная
кука, получаемая расширением, может использоваться при редиректе на сайт.

P.S. Если вы разрабатываете кроссбраузерное расширение, используя WebExtension API,
то Firefox до сих пор (на 2017-12-11) поддерживает только "spanning" значение для ключа
"incognito".

Что лучше использовать: сессии или куки?

#php #cookie #сессия

У меня на сайте все блоки обновляются через jQuery. Так как хочу сократить SQL запросы,
хочу сделать маленький кэш. И вот думаю использовать сессии.

Суть вопроса: что лучше использовать сессию или куки? Для каждого блока - разное
время обновления.
    

Ответы

Ответ 1

Если вам надо хранить интерфейсную информацию: например, чтобы отмеченные чекбоксы
не сбрасывались при перезагрузке страницы, то используйте куки. Если вы хотите хранить
информацию, связанную с безопасностью, то однозначно сессии - их подменить можно, но
очень трудно.
И да, как уже было сказано, и то, и то не работает при выключенных куках.


Ответ 2

Советую помнить, что куки хранят не более 4кб инфы. В сессии тоже не запихать много.
Так что решайте сами, что юзать.


Ответ 3

Куки хранятся у клиента, а сессии занимают некоторое место на сервере. Я бы советовал
выбрать куки, если хранить надо 2-3 записи.


Ответ 4

Я бы вам советовал совместить куки и сессии, т.е. у пользователя могут быть выключены
быть куки. И тогда хранить на сервере(сессия) данные.


Ответ 5

Я за сессии, т.к. пользователь может отключить куки. Это первое. Второе - сессии
безопаснее, т.к. через определенный промежуток времени (по-дефолту 15 минут) сессии
уничтожаются. Т.е., не так страшно, если пользователь забудет на чужом компе выйти
из своего аккаунта. 
Вывод: если проект действительно серьезный - сессии, если красть особо нечего  можно
обойтись и куками.

Безопасно ли хранить информацию в Session? ASP.Net MVC, C#

#c_sharp #aspnet_mvc #сессия

Добрый день, граждане! 
Работаю, вот, с ASP.Net. Имеется здесь объект, представляющий текущую сессию пользователя,
в него можно записывать информацию любых видов и получать по ключу (короче, нечто вроде
Dictionary). Но вот безопасно ли это делать? Может ли пользователь перехватить оттуда
хранимую информацию? И, если да, какие есть аналоги?
    

Ответы

Ответ 1

В браузере нету содержимого самой сессии. Пользователю передается только идентификатор
сессии, который записывается в куки. Каждый пользователь может спокойно посмотреть
свои куки и изменить. 

Безопасно ли это? Конечно нет, но безопаснее куков. Все что передается пользователю
от сервера или к серверу можно перехватить иди даже проще случай, например, пользователь
может скопировать идентификатор сессии и передать его другому человеку.

Главное отличие сессии от куков это то, что при использовании сессий вся информация
хранится на сервере, а у клиента имеется только идентификатор. У куков вся информация
хранится у клиента.

Так же сессии хранятся определенное количество времени. Настраивается на веб-сервере.
Например, если по истечении 20 минут не было обращения, то сессия автоматически удаляется.

Сеансы поддерживают объекты любого типа, включая специальные, создаваемые самим разработчиком
типы данных. Управление сеансом не является частью HTTP-стандарта. Поэтому для отслеживания
информации сеанса и ее привязки к соответствующему ответу ASP.NET приходится выполнять
дополнительную работу. Для отслеживания сеанса используется уникальный 120-битовый
идентификатор, который генерируется по патентованному алгоритму. Этот идентификатор
является единственным фрагментом информации, который передается между веб-сервером
и клиентом.

Так же можно выбрать где хранить объекты сессии. Это может быть объект в памяти,
таблицы в б/д с специальным названием ASPState или Windows-служба.



Подробную информацию о сессиях, как их использовать, настроить или выбрать метод
хранения можно узнать на ProfessorWeb

Безопасность сессий в PHP?

#php #сессия #безопасность

В очередной раз работаю с сессиями в PHP и вдруг возникло ряд такий вопросов:

А насколько они безопасны в данном
   языке,какова вероятность их
   подделать?
Каковы средства защиты(в php),кроме привязки
   к ip и браузеру?
Может кто-нибудь интересовался этим
   вопросом и у него есть готовые ответы
   или ссылки на статьи?
    

Ответы

Ответ 1

Как Вы знаете, сессии базируются на куках. Идентификатор сессии записывается в куки
и по нему подымается сессия.
Никто не застрахован, что кто-то "подсмотрит" Ваш идентификатор и применит его в
своих целях. Применяют дополнительные меры предосторожности, как Вы уже упомянули -
привязка к IP и к User-Agent. Полной гарантии безопасности сессий не существует. На
порядок безопасность повышает SSL (https) на сайте- это наверное единственная рекомендация,
которую можно дать. 
P.S.: А почему мой ответ отобразился как "Сообщество Хешкод" ? :)


Ответ 2

сессии привязываются к конкретному браузеру, создается уникальный id и записывается
в переменную PHPSESSID. обратно она возвращается двумя путями через cookies и GET либо
POST запросом. в связи с этим сессию подделать можно.
можно дополнительно пользоваться одноразовыми токенами, которые усложнят доступ к сессии.
здесь достаточно подробно расписано о принципе действия сессий. Сессии в PHP


Ответ 3

Если украсть куки и подставить (если нет других мер защиты, типа привязки по IP),
то сессия будет украдена.

Авторизация пользователя на php/mysql/session

#php #mysql #сессия

Делаю авторизацию, возникла такая проблема. При нажатии на 
Logout  ,  происходит редирект на login.php, т.е. на форму, но если в соседней
вкладке зайти на home.php, то редирект не происходит и пользователь как бы остаётся
в системе. Т.е. не происходит разрушение сессии.

Вот код php:

login.php

 location.href='home.php'
";   
  }

  else
  {
echo "";
}

}

?>


home.php





    
Welcome 
 
 Logout 




logout.php



    

Ответы

Ответ 1

Ну, я уже не помню всех тонкостей с сессиями, но в моем видении это так: при логине
создаешь некий ключ в сессии, например:  

//login.php
if (mysql_num_rows($query) != 0){
    $row = mysql_fetch_assoc($query)
    $user_login = $row['username'];
    $_SESSION['user_login'] = $user_login;//присваиваем нашему ключу значение
//В нашем случае, логин юзера
    if(isset($_GET['requested_url']){
        header('Location: '.urldecode($_GET['requested_url']));
    }//Если был задан запрашиваемый адрес, то автоматически перенаправляем его туда.
}


Потом, когда к тебе на страницу заходят, первым делом вызываешь скрипт, который проверяет
сессию:

//somepage.php
if(!isset($_SESSION['user_login']){
    header('Location: login.php?requested_url='.urlencode($_SERVER[REQUEST_URI]));//В
идеале, передавая и адрес страницы, на которую изначально хотел зайти пользователь,
чтобы потом сразу перенаправить его туда.
}
require_once('content.php');

//logout.php
session_unset();
header('Location: login.php');


Сразу, просьба исключить комментарии про голый mysql вместо PDO и иже с ним, ответ
ориентируется на достижение других целей.


Ответ 2

Я использую сессии и авторизацию через $_SERVER, но может вам пригодится следующее:

session_unset ();
session_destroy ();
$connection->close();
unset($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW'], $_SERVER);
header('HTTP/1.0 401 Unauthorized');


Ответ 3

Попробуй использовать unset($_SESSION['login_user']);

session_destroy() не желательно использовать

Используй проверки if(isset($_SESSION['login_user'])) ...

Используют ли сессии?

#сессия #php

Используют ли стандартные сессии PHP в высоконагруженных проектах?
Если нет то почему?    

Ответы

Ответ 1

Используют. Сессии очень несильно грузят, вообще-то.
Другое дело, стоит осознавать для чего вам нужен данный механизм. Не стоит использовать
его для долговременного хранения данных десятка миллионов пользователей.


Ответ 2

ИМХО РНР такой язык, что вы упретесь в него гораздо раньше, чем в производительность
сессий.
Если не хранить в сессиях мегабайты - они работают очень шустро.
Если вам всё ещё беспокойно используйте memcached, а лучше перенесите временную папку,
где лежат сессии в tmpfs


Ответ 3

В высоконагруженных проектах не используют стандартные сессии из-за отсутствия возможности
горизонтального масштабирования. Используется альтернативное хранилище сессионных переменных,
высокопроизводительное и отказоустойчивое. И дело не в размере сессии, а в количестве
обращений на чтение и запись. Во всяком случае не слышал про стандартное хранение сессий
в проектах уже от 300 000 хитов в час в прыжке.


Ответ 4

Например, у себя реализовал сессии на MySQL. Работает отменно.

Безопасность использования сессий

#php #алгоритм #безопасность #сессия

Есть скрипт простой авторизации:

Пользователь вводит логин, пароль и капчу. По AJAX это дело отправляется в пхп скрипт,
который из БД достает пароль пользователя имя которого равно введенному, если они совпадают,
то в сессию записывается логин и идет редирект в ЛК. Если пользователь заходит в ЛК
и у него не зарегистрирована сессия с именем, то его выкидывает обратно в форму. Если
зарегистрирована то из БД берутся остальные данные на основе сессии с логином.

Как можно улучшить и какие дыры есть в этом алгоритме?
    

Ответы

Ответ 1

В качестве улучшения можно заглянуть в php.ini, и поменять  алгоритм хэширования,
используемый для генерации идентификатора сессии. '0' означает MD5 (128 bits), а '1'
означает SHA-1 (160 bits). Начиная с PHP 5.3.0 также стало возможным указать любой
из алгоритмов, предусмотренных расширением hash (если оно доступно), например sha512
или whirlpool. Полный список алгоритмов может быть получен с помощью функции hash_algos().


Ответ 2

В алгоритме дыр нет - все достаточно надежно. Дыры если возможны только на этапе
реализации.

В качестве усовершенствования можно (1) перевести страницы с формой и AJAX-обработчик
формы на HTTPS - трафик будет зашифрован и его перехват не даст злоумышленнику пароль
в открытом виде. (2) Для того, чтобы снизить вероятность угона сессии следует ограничить
время ее действия, каким-то разумным сроком. (3) Разумеется ни в коем случае нельзя
допускать XSS-инъекций на сайте, возможно стоит проверить его каким-нибудь автоматическим
инструментом.

Разница между Cookies и сессиями

#php #cookie #сессия

Здравствуйте, все никак не могу понять разницы между куки и сеансом. Насколько мне
известно, если в броузере отключен прием кук, то авторизацию и регистрацию пользователь
не пройдет, исходя из этих соображений для регистрации я делаю на session_start, но
если я в броузере выключаю куки, то все ровно не заходит.
Как работать с куки и сессиями? В каждом файле надо делать проверку на существование
сессии, для того, чтобы если их нет, то человек не смог зайти на эту страницу? Еще
я замечал на некоторых сайтах, что в броузерной строке по мимо адреса еще есть session_name
и session_id. Как это делается и для чего?
Пожалуйста, объяснить мне простыми словами, а не заученными терминами, как и с чем
работать? Что и для чего надо? Можно с примерами в которых будет пояснение, спасибо.    

Ответы

Ответ 1

Это разные явления.
Cookie — это просто пара имя-значение, которую (точнее, которые) сервер может оставить
у клиента (браузера). Наглядно:

Приходит клиент, спрашивает у сервера страницу.
Сервер в заголовках ответе может установить cookies. Например, выдав два заголовка:
Set-Cookie: foo=123 и Set-Cookie: bar=baz — по-русски — «запомни, foo — 123, а bar — baz».
При следующем обращении клиент, если он решил запомнить, говорит серверу «Cookie:
bar=baz; foo=123».

Упрощенно, не затрагивая тонкости — все, вот все, что представляют собой cookies.
Сессии — более эфемерное понятие, которое не привязано к какой-то конкретной реальной
технологии. Это просто некая методика, которая позволяет отличить одного клиента от
другого, и, как правило, где-то хранить связанные с каждым клиентом данные.
Как правило, сессии реализуются используя cookies и идентификаторы сессий. Т.е. сервер
со своей стороны создает уникальный идентификатор, например, «1a2b3c» (session_id про
который вы справшивали), а клиента просит его запомнить. Обычно — при помощи cookies,
говоря что-то в духе Set-Cookie: PHPSESSID=1a2b3c (где «PHPSESSID» — имя сессии, обычно,
оно только одно, вести параллельно несколько сессий нужно редко). Со своей стороны
сервер где-то (зависит от реализации, иногда это файл, например, /tmp/1a2b3c, иногда
запись в БД, иногда еще что-то) хранит различные данные, которые ему приказано связывать
с этой сессией. Например, имя пользователя.
PHP'шные сессии использовали не только cookies, но и аргументы в адресной строке.
Т.е. перед отдачей страницы пользователю «переписывали» все ссылки в ней, добавляя
свое «?PHPSESSID=1a2b3c». И клиент вместо «/forum.php» шел на «/forum.php?PHPSESSID=1a2b3c».
Таким образом сервер получал идентификатор сессии и все работало.
Сейчас PHP по умолчанию такого не делает — у этого метода есть куча своих недостатков.
Хотите включить — напишите ini_set('session.use_trans_sid', true);, но нужно понимать
связанные риски.
Еще можно хранить идентификаторы сессий в других местах. Например, Local Shared Objects
(«флэшевские cookie»), использовать возможности хранилищ HTML5, и еще ряде менее тривиальных
мест, но PHP этого «из коробки» не умеет.
Соответственно, раз и cookies и поддержка use_trans_sid (перезаписи адресов) отключены,
то PHP не может нигде оставить у клиента «метку». И сессии, по сути, не работают. Это,
в общем-то, не должно быть проблемой — если клиенту надо — он включит cookies.
Еще момент. Сами по себе сессии не дают авторизации — это только хранилище. Авторизацию
делаете Вы сами (или фреймворк, которым Вы воспользовались). Вы пользуетесь тем, что
данные, связанные с сессией (в типичной PHP'шной реализации) хранятся на сервере, и
клиент их там подменить не может.
Соответственно, когда клиент аутентифицируется — в сессии сохраняется кто он. Обратно
— если у нас в сессии записано кто он — можно этому верить. Вся дальнейшая логика —
пускать ли клиента, давать ли ему какие-то возможности и т.д. — на Вас.

Как работать с куки и сессиями? В каждом файле надо делать проверку на существование
сессии, для того чтобы если их нет то человек не смог зайти на эту страницу?

Зависит от того, что Вы хотите, и от того, как Вы все строите. Если к этой странице
должен быть доступ только у авторизованных пользователей — да, как вариант, так.
Иногда все запросы пропускают через один скрипт-«диспетчер». Иногда во все скрипты
в начало вставляют include, которое инициализирует общую для всего сайта логику (сессии,
авторизация).


Ответ 2

Сессия создается на сервере, а куки хранятся у пользователя на компьютере.
Протокол HTTP не может определять связь между двумя запросами одного и того же пользователя.
Для этого мы создаем переменные сессии. Важно понимать, что эти переменные сохраняются
даже после завершения выполнения php сценария.
Идентификатор сессии автомаически сохраняется в браузере пользователя в виде cookie,
а если браузер cookie не поддерживает - идентификатор добавляется автоматически к адресу
страницы и всем ссылкам на ней. Это значит, что при обновлении страницы браузер сам
отправит на сервер идентификатор сессии, независимо от действий пользователя.


Ответ 3

Как в таком случае работать: перенаправлять на главную и указывать, что куки по-хорошему
бы надо включить.
session_name задает имя сессии на случай, если надо разделить сессии в пределах одного
домена. Хотя это лучше не делать через адресную строку, а использовать в коде.

Когда создается объект HttpSession?

В сервлете есть метод:
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { System.out.println(req.getSession(false)); req.getRequestDispatcher(indexPage).forward(req, resp); }
При использовании apache-tomcat-8.5.15 при первом обращении получается следующий лог:
null null org.apache.catalina.session.StandardSessionFacade@5e21a333
Я всегда думал что существует возможность управлять процессом создания сессии при помощи getSession(true/false). Но выходит что сессия создается вне зависимости от моего желания? Так как же мне обеспечить что бы сессия не создавалась до тех пор, пока я сам не скажу getSession(true)? Хоть я false параметром и выставил, а все равно получил ее создание...
Помогите пожалуйста разобраться что произошло. Спасибо.

Ответ

Скорее всего в вашем приложении использовался JSP. По умолчанию сессия создается при обращении к произвольной JSP странице, если это в явном виде не отключено специальной директивой <%@ page session="false" %>
В остальном вы правы req.getSession(false) не приводит к созданию сессии, если она не была создана до этого.

Значение чекбоксов сохранить в сессию, если в сессии их нет то записать по умолчанию

Есть несколько input типа checkbox
...................................................................
Есть отдельный js, где обрабатывается логика поведения, который через ajax общается с php
Не могу понять, как мне правильно записать значение чекбоксов в сессию, чтобы потом через ajax вытащить в JS
Уточню что никаких кнопок submit нету

Ответ

session_start(); ..... $_SESSION['checkboxis'] = $_GET['ch'];
где то так на php.
можно использовать и storage js
http://javascript.ru/unsorted/storage подробнее можно сдесь прочитать, я не силён в js думаю коллеги что нибудь напишут в дополнение с примером кода.

Хранение объемных данных в viewstate asp.net

У меня есть сайт на asp.net и мне нужно хранить достаточно большие файлы, 2-4 файла каждый до 10 мб между postback'ами. Сейчас я их храню в сесиях, но админ попросил поискать решение менее требовальное к количеству оперативки на сервере.
Какие есть минусы хранения 40 мб файлов в Viewstate ? Отправляется ли viewstate в запросе с каждым постбеком, даже если она там не используется?

Ответ

Viewstate отправляется при каждом запросе и еще шифруется. Хранить в нем такие большие файлы нельзя. Для ускорения работы сайтов есть практика отключения Viewstate совсем.
Если ваши файлы разделяются между всеми пользователями, то замените хранение в сессии на хранение в Cache
Так же можно воспользоваться сторонним кеш-сервисом (memcached, redis и тд).
Для экономии оперативной памяти вы можете хранить ваши временные файлы на диске между запросами. При небольшом объеме оперативки вам придется сделать выбор между производительностью (хранение в памяти любого кеш-сервиса) и загрузкой памяти (хранить на диске).
Если задача это позволяет, то можно попытаться переделать последовательность работы с файлами исключающую потребность в их хранении между запросами. Например, вначеле мы собираем информацию об обработке файлов от пользователя и только в конце применяем все алгоритмы к данным из файлов.

Проблема с сессией: Cannot send session cache limiter - headers already sent

Изначально когда проектировал сайт, работал с сессиями только на одной странице, где объявлял session_start(); Потом понадобилось распространить эту функцию на весь сайт. Для этого я разместил session_start() в файл config.php, который в свою очередь подключается к каждому файлу php сайта. Вот тут-то и возникли проблемы...
Структура сайта такова (заголовочные файлы):
config.php header.php left.php footer.php
Эти файлы подключаются к каждой странице сайта. А страницы разбиты по категориям в которых нет ошибки сессии:
index.php shopingcart.php contact.php
И файлы в которых ошибка возникает:
faqs.php productdetail.php checkout.php
Как можно побороть ошибку данную?
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at S:\home\localhost\www\web_shop\faqs.php:1) in S:\home\localhost\www\web_shop\config.php on line 2

Ответ

Благодаря помощи, товарища ToRcH565 удалось исправить эту ошибку. Дело было в том, что я писал