Удаленная альтернатива локальному хранилищу для пользовательских данных с низким уровнем безопасности?

Question

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

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

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

Единственный способ сделать это без создания какой-либо системы входа в систему (насколько я могу видеть) - это использование файлов cookie или другого локального хранилища (Flash / HTML 5....), который имеет очевидный и большой недостаток в том, что он привязан к компьютеру, а не к пользователю.

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

Служба хранения "ключ / значение", которой я передаю уникальный ключ (тот, который указал пользователь) и получаю взамен сохраненное значение, будет достаточно.Нет необходимости в реальной безопасности - данные не являются конфиденциальными.

OpenID не вариант: он недостаточно известен среди аудитории сайта.

Facebook будет вариантом, но я не думаю, что онипредоставить варианты «хранения», подобные этой.

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

Answer 1

API Google Docs обеспечивает программный доступ к Документам Google , где вы можете создавать и хранить документы и таблицы.Ваше приложение может иметь свой собственный логин Google, который он использует для создания одного или нескольких документов на пользователя.Эти документы могут использоваться для хранения пользовательских настроек.

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

В качестве альтернативы, вы можете объединить Документы Google с API таблиц Google , где я только что заметил эту довольно удобную функцию:

Таблицы и записи
Взаимодействие с электронными таблицами, как если бы они были базой данных с использованием таблиц и записей.

Answer 2

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

У нас есть система «ленивых регистров». Когда пользователь сохраняет элемент в первый раз, у него запрашивается адрес электронной почты (но пароль отсутствует, поскольку ничего не является конфиденциальным). Это хешируется и сохраняется локально с помощью файла cookie, а затем используется для установки / получения сохраненных элементов. Когда пользователь использует другой компьютер, его снова просят указать адрес электронной почты.

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