Профиль пользователя ASP.NET против использования файлов cookie - PullRequest
3 голосов
/ 19 января 2009

Я думаю, что почти во всех случаях данные о предпочтениях пользователя могут храниться в cookie-файлах с (почти) такими же хорошими результатами, как и при использовании API профиля пользователя. Недостатки использования файлов cookie (для прошедших проверку пользователей) заключаются в том, что файл cookie может быть удален или истек тайм-аут, и в этом случае данные о предпочтениях пользователя будут потеряны. Для анонимных пользователей, если данные предпочтений необходимо сохранять в течение сеансов, необходимо использовать cookie, даже если используются профили пользователей.

Так, каковы некоторые из самых больших преимуществ / недостатков использования пользовательских профилей или файлов cookie для хранения пользовательских настроек?

Ответы [ 6 ]

3 голосов
/ 19 января 2009

Одним из преимуществ регистрации на сайте является то, что он запоминает мои предпочтения - если вы храните эту информацию в файле cookie на моем компьютере, а не на вашем сервере, то, когда я захожу на ваш сайт с другого компьютера, я ' я должен снова настроить все мои предпочтения - с точки зрения удобства использования, это довольно плохо.

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

Кроме того, я заметил, что разные браузеры имеют разные реализации для файлов cookie - например, IE теперь может получать 50 файлов cookie из одного домена (по сравнению с исходными 20), но он все еще ограничен общим 4096 байт для всей коллекции файлов cookie (и предыдущие версии) - другие браузеры будут поддерживать 4 КБ на файл cookie, а не на домен.

2 голосов
/ 19 января 2009

Другим недостатком хранения всех данных о предпочтениях в файлах cookie является то, что все эти данные необходимо будет отправлять при каждом запросе от клиента и при любом ответе от сервера при каждом изменении данных. Хотя это может показаться незначительным моментом в эпоху широкополосной связи, это все еще дополнительные издержки. Использование API профилей означает, что данные хранятся на сервере, и браузер должен отправлять только cookie идентификации сеанса.

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

2 голосов
/ 19 января 2009

Файлы cookie ограничены по максимальной длине, и они используют реализацию вне вашего контроля (в конце концов, они являются функцией браузера вашего посетителя). Лично мне не нравится полагаться на неизвестные сторонние реализации, над которыми я не имею никакого контроля, и, если мне нужно, я пытаюсь использовать это самым простым способом.

Итак, откуда я пришел, я всегда сохранял пользовательские данные на сервере и просто передавал cookie, указывающий на эту информацию.

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

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

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

1 голос
/ 16 апреля 2009

На самом деле вам не нужно сохранять данные предпочтений в файлах cookie для анонимных пользователей при использовании поставщика профилей ASP.NET. Просто сохраните текущий идентификатор пользователя (который представляет собой ужасную строку, связанную с сеансом) в файле cookie. Он становится предыдущим идентификатором пользователя при последующих посещениях, а затем вы можете просто получить старую информацию о профиле и перенести ее в текущий профиль или даже аутентифицировать ее как этот старый анонимный профиль.

1 голос
/ 19 января 2009

Имейте в виду, что возможно создать ProfileProvider, который сохраняет пользовательские данные в куки, так что вы можете получить лучшее из обоих миров, если решите, что состояние, которое вы хотите сохранить, подходит для куки (размер, безопасность и т. Д.) .

1 голос
/ 19 января 2009

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

Я не знаком с API профиля пользователя, но полагаю, что он хранит информацию на сервере (?). Если это так, то у вас могут возникнуть проблемы, если у вас много пользователей.

В целом, возможно, лучшим решением является использование профиля пользователя, если он гарантирует постоянство информации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...