客户端javascript驱动的网站

首先，在客户端上运行代码以直接访问数据库听起来很麻烦。这似乎与信息隐藏的想法背道而驰，信息隐藏在设计更复杂的系统中非常有用。 因此，我认为这大部分是学术活动。 :) 大多数集中式数据库系统本身都有多个用户或角色。通常，我们对每个应用程序使用一个“用户帐户”，并允许应用程序以自己的方式定义用户。 （这一直困扰着我，总感觉管理员和用户角色也应该在数据库中分开。但是我个人看来似乎很孤单。 但是，您可以在数据库中定义“ 0”角色和“ 1”角色，为“ 1”角色赋予“ 2”特权，并为“ 0”角色赋予“ 4”特权。 PostgreSQL至少有一个预定义的

PUBLIC

可以代替

user

；以下示例是从http://www.postgresql.org/docs/9.0/static/sql-grant.html复制的：

GRANT SELECT ON mytable TO PUBLIC;
GRANT SELECT, UPDATE, INSERT ON mytable TO admin;

正确配置

pg_hba.conf

文件可能允许

admin

用户从特定IP登录，而

user

用户从其他任何地方登录，因此您可以将

UPDATE

和

INSERT

限制为特定IP。 现在的困难是用JavaScript编写PostgreSQL客户端库。 :)坦白说，我没有任何线索，如果基于浏览器的JavaScript虚拟机足够灵活以允许与远程主机进行任意套接字通信。 （鉴于如何如此热烈地拥抱WebSockets，我猜想JavaScript完全滞留在HTTP世界中。） 当然，您必须以某种方式将HTML页面提供给Web浏览器，这意味着拥有HTTP服务器。您也可以要求该服务器位于客户端和数据库之间。您也可以在服务器上执行一些处理任务，以避免同时向客户端发送冗余/不必要的数据……这正是我们今天所面临的情况。 :)     

是的，有可能有一个严重依赖JavaScript的Web应用程序。但是，大多数情况下，该层只是附加的；不能替代。大多数开发人员都认为JavaScript只是一个方便层，它使最终用户的交易“更轻松”，并且您可以说这是安全性最佳的方法。 JavaScript作为一种“确定性”工具，用于将可延展的数据清除到受信任的数据库中只是效率不高；除非您想将所有数据视为不安全的数据，并在每次显示数据时对其进行清理并通过JavaScript本身进行处理。 花哨的动画，AJAX，验证，计算通常只是为了方便起见，并认为有时使用客户端处理器比使用服务器更好。当然，自56k互联网连接以来，使事情“更快”是每个人都希望实现的事实。 在安全方面，拥有最终用户无法使用的任何额外保护层的安全逻辑简直是疯狂。将JavaScript视为一本额外的书。 JavaScript可以读取的内容，用户可以读取。您不会在其中存储数据库凭据或密码哈希密钥吗？ 特别是因为可以使用调试器在运行中修改JavaScript，并且几乎所有混淆的代码都可以解析为人类可读的内容。 不用考虑插入和“安全”数据，如果源是安全的，则获取公共可用信息不会有太大麻烦。 对于javascript前端，我会推荐Backbone.js，它将为您提供组织和交互方面的坚实基础：   骨干用品结构   大量使用JavaScript的应用   为模型提供键值   绑定和自定义事件，集合   具有丰富的可枚举的API   函数，带有声明性的视图   事件处理，并将其全部连接到   您现有的应用程序   RESTful JSON接口。 剩下的唯一事情就是可以在数据库（甚至是数据库本身）上放置一个薄层，以便在插入时清理数据并存储/计算在任何情况下都不会公开的敏感信息。给客户。 更新 博客示例 做您想做的3个真正的要求。 身份验证（后端）：访问数据库，删除注释等将需要此功能。 验证和消毒（后端）：限制字符数量，逃避恶意代码，禁止使用单词。 敏感数据处理（后端）：使用哈希来输入密码... 注意：通过在显示数据时将所有数据视为不安全的数据，您几乎可以绕过“验证和消毒”。就像我提到的那样，效率很低，因为您需要客户端以某种方式对其进行解析以确保其安全性；而且仍然很有可能会被绕过。另外两个，确实需要您有一种与宝贵的数据库进行交互的安全方法。 通常：如果后端发生故障，则前端发生故障。反之亦然。 XSS会对JavaScript统治的网站（例如Facebook）造成巨大的损害。     

无法从客户端与数据库对话。为了安全起见和验证，您必须进行两次。一次在客户端，一次在服务器端。 您可以在客户端执行的任何操作都可能被恶意用户伪造。客户端验证主要是为了方便用户。提供数据库安全性的是服务器端验证。