Ответы пользователя по тегу Сессии
  • Как правильно реализовать аутентификацию в SPA на Socket.io?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    пароль отправляется без криптования

    без SSL пининга можно и покриптовать пароль, но это нужно далеко не всем.

    На сервере пароль криптуется SHA256

    не криптуется а хэшируется, и лучше хэшировать в BCRYPT (или SCRYPT даже но я бы еще подождал пару годиков)

    после чего происходит поиск по бд пары логин-криптованный_пароль соответствующий введенным данным

    Ммм... шансы конечно малы... я бы даже сказал мизерные, но мы таким образом становимся уязвимыми к тайминг атакам. На данный момент адекватный алгоритм - это поиск по логину (идентити, логин или email или что вы там используете для идентификации пользователя) а затем сверяем хэши паролей посимвольно:

    var matches = true;
    for(var i = 0; i < 1024; i++) {
        if (str1[i] !== str2[i]) matches = false;
    }


    почему так убого? потому что почитайте про тайминг атаки. Есть даже задокументированный случай с эксплуатацией тайминг атак для подбора коллизий к хэшам через интернет (то есть с задержками порядка 10 и более милисекунд)! Правда для этого надо сделать пару миллионов запросов ну да несуть.

    Серверный socket.io ищет в бд пользователя с этим wskey

    Еще хорошая идея - socker.io серверный спрашивает у сервера авторизации правильный wskey или нет но это если вы упарываетесь по масштабированию.

    Если есть какие-то ошибки в написанном - пожалуйста, раскритикуйте)

    В целом все верно. А если не загоняться такими вещами как разделение ответственности (мол у вас отдельно socket-io сервер и отдельно приложение) то можно еще и JWT юзать. Тогда нам вообще не надо ничего нигде хранить а проверять валидность можно по подписи токена. Да и реализация готовая есть.
    Ответ написан
  • Где вы храните сессии пользователя, почему?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Что делать если у пользователя отключены cookies и нельзя определить идентификатор сессии?


    Сообщать ему что мол "чувак у тебя куки отключены!"

    https://developer.mozilla.org/en-US/docs/Web/API/N...
    Ответ написан
  • Как получить доступ к сессиям в шаблоне(twig) symfony2?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Можно, но зачем? Передавайте все явно и проблем будет меньше.
    Ответ написан
  • Symfony2 как лучше реализовать свой механизм сессий?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) session ID в любом случае придется передавать в каждом запросе, в заголовках, URI или куках - не важно. Самый простой способ - в URI но он же и не секьюрный... наверное... если перегенеривать часто то может и норм.
    2) Какие собственно другие аспекты затрагивает? Поставьте обработку этого дела в onRequest и onResponse (http middleware) и там делайте с запросами ответами что хотите. Ваше приложение ничего даже не узнает. А переопределить сервис по работе с сессиями вы уж как-нибудь сможете.
    Ответ написан
  • Чем куки отличаются от сессии в PHP?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Нууу давайте разбираться.

    Для начала почитайте про HTTP на той же вики. Досканально знать не нужно, но стоит минимально понимать структуру запросов/ответов, понимать что у запроса и ответа есть заголовки и тело (тела может и не быть, зависит от типа запроса/ответа).

    Так вот. Куки. Куки живут на стороне браузера. Они передаются HTTP заголовком на каждый запрос на сервер (даже если вы за картинками полезли). Есть просто куки, есть http-only куки. Куки могут быть разграничены по хосту и пути. Все это дает нам гибкость и помогает с секьюрностью. В PHP содержимое $_COOKIE предоставляет нам SAPI. Когда PHP получает на обработку запрос, SAPI используемое (php-fpm, cgi, mod_php имеют свои реализации SAPI) в данный момент берет заголовки и тело запроса, парсит их и заполняет все эти суперглобальные массивы типа $_SERVER, $_GET и в том числе и $_COOKIE. Все что прислал нам клиент (что-то что делает запросы это клиент, что-то что их обрабатывает - сервер), а куки шлет нам браузер только те что можно исходя из того куда шлется запрос. Устанавливаются куки заголовком Set-Cookie в ответе, то есть тут больше нужно читать в принципе про HTTP а не про PHP. PHP просто позволяет вам работать с этим добром. Вы можете сэтить куки напрямую работая с заголовками ответа при помощи функции header. Более того, если выставить время жизни куки в 0, то как раз таки они а не сессия будет сбрасываться при закрытии браузера так как тот будет забывать все такие куки.

    Вот... сессии... В PHP сессия обычно это файл. Просто какой-то файл с рандомным именем. Если скажем в php.ini указано session.autostart или делается вызов session_start то создается файл под сессию пользователя (можно переместить в рэдис или мемкэш, свое хранилище и т.д в зависимости от нужд. Так же данные можно шифровать, что по умолчанию и происходит). Этот файл имеет ID, просто какая-то рандомная строка. И если при обработке запроса не нашлась сессия с предыдущего запроса - создается новая.

    И вот мы подошли к самому интересному - как PHP связывает сессию с предыдущего запроса с текущей. И тут все довольно просто - куки. Когда пользователю присваивается сессия, автоматически сэтится http-only (что бы нехорошие люди не могли из js увести нашу сессию) кука, в которую записан идентификатор сессии. В дебагере браузера можете посмотреть есть ли у вас кука PHPSESSID (название можно менять в настройках, да и вообще сессии можно не только через куки связывать, но это уже загоны по секьюрности) когда будете эксперементировать с сессиями.

    Когда запрос обрабатывается SAPI, при наличии session.autostart, перед тем как начинать создавать новую сессию, пых все же смотрит а есть ли у нас кука с идентификатором сессии, проверяет есть ли у него такая, и если есть успокаивается и не создает новую. Поскольку сессия привязывается через куки, то можно выставить время жизни этой самой куки (в php.ini) и таким образом регулировать время жизни сессии.

    Вот... когда использовать куки а когда сессии? Желательно понимать, что чем больше данных в куках (а у них есть лимит к слову) - тем больше данных мы передаем на каждый запрос. То есть это не круто когда что бы получить 1 килобайт данных мы должны в заголовках передать пару килобайт кук. Люди, повернутые на оптимизации, даже картинки хранят на отдельных cookie-less доменах что бы уменьшить количество трафика и пакетов (обычно простенький HTTP запрос влазит в размеры одного TCP пакета). Если вам нужно работать с этими данными из JS на любой странице, например локаль выбранноую пользователем для того что бы применять переводы еще и в JS, то стоит использовать куки. Для всео остального лучше конечно же использовать сессии. Во всяком случае на начальных этапах когда что-то сильно сложное вам делать не придется.
    Ответ написан
  • Что означает эта ошибка в PHP?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    session_start создает сессию. Что это значит? Это значит что оно создает место куда будет сохраняться инфа (файл по умолчанию) и присваивает этому месту какой-то рандомный идентификатор. Что бы сессия не потерялась пользователь должен отправлять его при каждом запросе. Так сложилось что это дело разруливают через куки.

    Куки сетятся заголовком Set-Cookie, так что когда вы вызываете функцию session_start это равносильно отправке заголовка пользователю.

    Вообще в HTTP запросах/ответах есть две части - заголовки и тело. Заголовки описывают параметры запроса/ответа, в частности что именно содержится в теле запроса/ответа и в случае запроса, что хочет получить пользователь/клиент.

    Думаем дальше. для работы с заголовками ответов SAPI в PHP предоставляет вам функцию header. Упростим для себя жизнь и представим что session_start дергает внутри оную. Все что выходит через другие места в stdout (через echo или print например или просто какой-то символ перед <?php затесался) считается телом ответа. Так как должна соблюдаться последовательность действий при формировании HTTP ответа, то вы не можете менять заголовки как только хоть что-то, даже один байт, попал в буфер вывода.

    Частично эту проблему решают функции управления буфером вывода. То есть мы можем сказать пыху что бы тот чуть подожал, а затем сделать flush буфера. Тогда можно в коде спокойно менять местами echo и header.

    Вот... Помимо несоблюдения порядка взаимодействия с заголовками и выводом инфы частенько встречается такая штука как заголовки самих исходников (UTF BOM). Их умеет убирать любой нормальный редактор.

    Так же рекомендуется не закрывать <?php тег так как после закрытого тега может затесаться лишний перевод строки и при инклудах это сыграет злую шутку.
    Ответ написан