Когда я должен использовать переменные сеанса вместо cookie?
IIUC:
df = pd.DataFrame([["11","2", "6"], ["12","4", "2"], ["13","3", "4"]],
columns=["ix","a", "b"])
ix a b
0 11 2 6
1 12 4 2
2 13 3 4
Проверьте, содержатся ли значения в a в значениях в b:
df['res']=df.a.isin(df.b).astype(int)
>>df
ix a b res
0 11 2 6 1
1 12 4 2 1
2 13 3 4 0
Это также работает для списка.
8 ответов
Сессии и cookie не являются тем же вообще. Cookie являются стороной клиента. Сессии являются стороной сервера. Сессии часто (но не обязательно) используют cookie для корреляции одного запроса с другим от того же пользователя, чтобы определить, что они принадлежат той же сессии.
сессия А является искусственным понятием, и HTTP не имеет того понятия. Это создается веб-серверами, чтобы помочь веб-разработчикам хранить информацию через запросы, как информация об учетной записи пользователя, тележки для покупок, данные формы, и т.д. Cookie несут стандартные HTTP-заголовки.
информация Вы храните на сессии по сравнению с cookie, ваше дело. Обычно Вы помещаете материал в cookie, которые Вы хотите сохранить через сессии после того, как пользователь закрывает его браузер. Возможно, запоминание аутентификационных маркеров для реализации "помнит меня" функциональность или прошлое пользовательское действие для персонализации его опыта. Сохраните эту информацию маленькой и "справочной", т.е. это могли быть просто идентификаторы, которые относятся к более богатой информации, которую Вы храните, разъединяют сторону. Помните, что то, что является стороной клиента, более уязвимо для вредоносного программного обеспечения, не храните пароли или уязвимую информацию.
Наконец, существует также локальное устройство хранения данных, которое Вы не упоминали. Это - также сторона клиента, но возможно немного менее восприимчивый к взломам сценариев перекрестного сайта с тех пор, в отличие от данных cookie, она автоматически не отправляется в заголовках.
Способ состоит в использовании ~/.netrc, как описано на шаге 3 этой документации Git :
Затем добавьте следующее к $ HOME/.netrc (вы можете обойтись без, но будет предложено ввести пароль много раз):
машина < имя _ сервера > вход < имя _ пользователя > пароль < пароль >... и установить разрешения:
chmod 600 ~/.netrc
ОБНОВЛЕНИЕ:
Как и в случае git 1,7,9, это, похоже, путь, чтобы пойти будет собственный API поддержки учетных данных. Git поставляется с открытым текстом хранилища учетных данных или менее удобным, но более безопасным временным кэшем учетных данных . Также можно использовать сторонних помощников по работе с учетными данными. До сих пор мне известны помощник для собственного хранилища учетных данных Windows и , который интегрируется с ключевым ключом OS X . (Сборка Git, поставляемая Homebrew, имеет двоичный файл, как и другие дистрибутивы OS X Git. Github также предоставляет автономный двоичный .)
Как правило, достаточно настроить помощник учетных данных один раз:
git config --global credential.helper wincred
Или вместо wincred используйте любой помощник, подходящий для вашей платформы. (Если имя исполняемого файла помощника - git-credential-wincred , то значение параметра будет равно wincred и т.д.)
Помощники учетных данных также поддерживают необходимость иметь отдельные наборы учетных данных для различных репозиториев на одном хосте.
-121--961300-Файлы cookie отправляются на сервер по каждому запросу, поэтому, если вы планируете сохранить значительный объем данных, сохраните их в сессии.
В противном случае, если вы храните небольшие объемы данных, файлы cookie будут в порядке.
Любые конфиденциальные данные должны храниться в сеансе, так как файлы cookie не защищены на 100%. Преимуществом файлов cookie является возможность сохранения памяти на сервере, который обычно хранит данные сеанса.
-121--99943-Сеансы хранятся на сервере, что означает, что клиенты не имеют доступа к хранящейся информации о них. Данные сеанса, хранящиеся на сервере, не должны передаваться в полном объеме с каждой страницей; клиенты должны просто отправить идентификатор, и данные будут загружены с сервера.
С другой стороны, файлы cookie хранятся на клиенте. Они могут быть сделаны прочными в течение длительного времени и позволит вам работать более гладко, когда у вас есть кластер веб-серверов. Однако, в отличие от сеансов, данные, хранящиеся в файлах cookie, передаются в полном объеме с каждым запросом страницы.
Избегайте хранения данных в файлах cookie
- Это может быть видно, прочитано и обработано конечным пользователем или перехвачено теми, кто имеет гнусные намерения. Нельзя доверять каким-либо данным в файлах cookie, кроме "session_id."
- Это увеличивает пропускную способность, если добавить 1 000 данных на страницу запроса на пользователя, что может увеличить пропускную способность на 10-15%. Возможно, это не дорого с точки зрения $ $, но это может быть с точки зрения производительности. Это эффективно снизит пропускную способность на каждом сервере на 10-15%, т. е.это может привести к необходимости дополнительных серверов.
То, что можно хранить в данных сеанса, зависит от объема данных и количества пользователей.
no _ of _ users*size _ of _ session _ dataдолжен быть меньше свободной памяти, доступной на сервере.
- Всегда используйте сеансы
- Используйте cookies только если вам нужны более длительные сеансы входа в систему - тогда добавьте cookie с зашифрованным идентификатором пользователя.
Файлы cookie могут сохраняться дольше, чем один сеанс. Однако файлы cookie могут быть удалены пользователем, или у вас может быть пользователь, чей браузер не принимает файлы cookie (в этом случае будет работать только сессия на стороне сервера).
В большинстве случаев состояние сеанса сохраняется с помощью файлов cookie. Так что вопрос не в одном или другом, а в том, как их использовать вместе.
Использование инфраструктуры сеанса вашего фреймворка может упростить задачу, но отслеживание состояния вручную с помощью файлов cookie обычно дает более точный контроль. Правильное решение зависит от того, чего вы пытаетесь достичь.
Cookies работают на стороне клиента, а сессии - на стороне сервера.
Используйте куки для небольших фрагментов данных, которые вы можете доверить пользователю (например, настройки шрифта, темы сайта и т.д.) и для непрозрачных идентификаторов данных на стороне сервера (например, идентификатор сессии). Ожидайте, что эти данные могут быть потеряны в любой момент, и им нельзя доверять (т.е. они должны быть дезинфицированы).
Используйте данные сеанса для больших кусков данных (во многих системах могут храниться объекты, структуры данных и т.д.) и тех, которым вы должны доверять - например, статус авторизации и т.д. В общем, используйте данные сеанса для хранения больших данных состояния.
Вы можете хранить такие вещи, как статус авторизации, в cookies, если это необходимо для GUI, кэширования и т.д. - но никогда не доверяйте им и не полагайтесь на их наличие. Cookies легко удалить и легко подделать. Данные сессии подделать гораздо сложнее, поскольку ваше приложение контролирует их.
Файлы cookie отправляются на сервер при каждом запросе, поэтому, если вы планируете хранить значительный объем данных, сохраните их в сеансе.
В противном случае, если вы храните небольшие объемы данных, подойдет файл cookie.
Любые конфиденциальные данные должны храниться в сеансе, поскольку файлы cookie не защищены на 100%. Преимущество файлов cookie заключается в том, что вы можете сэкономить память на своем сервере, которая обычно хранит данные сеанса.
Сеансы хранятся на сервере. Если вы храните что-то в файле cookie, браузер пользователя отправляет эту информацию с каждым запросом, что потенциально замедляет работу вашего сайта с точки зрения пользователя. Я стараюсь по возможности избегать использования файлов cookie.