【问题标题】:Remote alternative to local storage for low-security user data?用于低安全性用户数据的本地存储的远程替代方案?
【发布时间】:2011-04-01 00:05:57
【问题描述】:

假设您正在为一个经常光顾的大型门户网站开发一个独立的小型子页面。

子页面显示公共活动日历中的条目,并允许用户突出显示他们特别感兴趣的条目。突出显示的事件应在该用户以后每次访问时突出显示(并且可能显示在单独的列表中)。

然而,构建一个经典的用户注册系统,或任何其他在服务器上存储用户突出显示的事件选择的方式,都不是一种选择:子模块需要尽可能独立,并且需要尽可能少的维护可能的。这是项目的条件之一。

在不构建某种登录系统的情况下(据我所知)的唯一方法是使用 cookie 或其他一些本地存储(Flash / HTML 5....),这具有明显和很大的缺点它与计算机相关联,而不是用户。

有没有一种方法可以按每个人存储几千字节的数据,但不必使用登录名或 openID,我忽略了这一点?也许是可靠的网络服务?

“键/值”存储服务,我将唯一键(用户指定的键)传递给它并获得保存的值作为回报,就足够了。不需要真正的安全性——有问题的数据绝不是机密的。

OpenID 不是一种选择:它在网站的受众中还不够知名。

Facebook 是一个选项,但我不认为他们提供这样的“存储”选项。

作为一种解决方法,我正在考虑向用户提供他们选择的事件作为文本文件下载,也可以将其上传并转换为另一台机器上的 cookie。但这对用户来说相当复杂,因此并不完美。

【问题讨论】:

  • OpenID 也不提供任何存储功能,因此无法使用。无论如何,没有办法在客户端存储每个用户的数据。您不能将数据存储在客户端上,然后它会神奇地出现在另一台计算机上。也许您可以将数据存储在服务器上的文本文件中?
  • @Mewp 是的,我指的是 OpenID 用于在本地构建一个非常轻量级的存储系统。由于您所说的原因,我显然不是在寻找客户端的想法。文本文件(或者说建立一个小型数据库,叹息)确实可能是要走的路。
  • 澄清一下:问题是找到数据存储的可移植身份验证机制/唯一ID还是是实现数据存储本身的问题?
  • 我是否正确,您没有从包含您的子页面的页面获得用户 ID 或传递的任何内容?
  • 您至少可以发送一个 iCalendar 文件,而不是纯文本文件。许多应用程序甚至手机/智能手机都支持该格式。 en.wikipedia.org/wiki/ICalendar

标签: php cookies html


【解决方案1】:

Google Docs API 提供对Google Docs 的编程访问,您可以在其中创建和存储文档和电子表格。您的应用程序可以有自己的 Google 登录名,用于为每个用户创建一个或多个文档。这些文档可用于存储用户设置。

如果您可以从每个用户那里获得一个唯一的 ID(一个电子邮件地址,或者更安全的东西,也许),这应该是相当简单的。您甚至可以将文件整理到文件夹中——每个用户一个。

或者,您可以将 Google Docs 与 Google Spreadsheets API 结合使用,我刚刚注意到这个相当方便的功能:

表格和记录
与电子表格进行交互,就好像它们是数据库一样 使用表格和记录。

【讨论】:

    【解决方案2】:

    我们的网站上有一个类似的系统,用户可以在其中将页面添加到计划器/愿望清单功能中。保存的项目通过webservice发送并存储在我们的服务器上,并有相应的get webservice。

    我们有一个“惰性注册”系统。用户第一次保存项目时,系统会要求他们提供电子邮件(但没有密码,因为没有什么是机密的)。这使用 cookie 进行哈希处理并在本地保存,然后用于设置/获取保存的项目。当用户使用另一台计算机时,系统会再次要求他们提供电子邮件。

    关键是注册和登录是同一个操作,所以不需要任何密码提醒或任何重置功能。

    【讨论】:

    • 是的,这可能也是我要结束的。我首先检查是否有任何方法不必将数据存储在应用程序的服务器上(但使用 Google API 或用户的 Facebook 帐户或其他),但也许像这样的简单解决方案是最好的方法去。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-01-31
    • 2011-04-27
    • 1970-01-01
    • 1970-01-01
    • 2016-01-10
    • 1970-01-01
    相关资源
    最近更新 更多