如何减轻CouchDB对_users数据库的读/写限制 [英] How to ease CouchDB read/write restrictions on _users database

问题描述

在我的沙发应用程序中，正在使用两个数据库

In my couchapp two databases are being used

1是用于应用程序数据
2是 _users数据库。

1 Is for application data 2 Is "_users" database.

在我的应用程序中，我试图以一种形式实现自动完成，其中数据源是在 _users数据库中创建的视图。

In my application In one form I'm trying to implement autocomplete where data source is a "view" created in "_users" database.

现在，当我以非管理员的普通用户名登录时。尝试访问 _users数据库内的视图时，出现错误403：

Now when I login with normal user id other than admin. While trying to access the view inside "_users" database I'm getting the error 403 which is :

{ error： forbidden， reason：只有管​​理员才能访问系统数据库的设计文档操作。}

{"error":"forbidden","reason":"Only admins can access design document actions for system databases."}

我是否可以允许非管理员用户并将其访问权限限制为该视图？这样我就可以将_users数据库中的用户列表添加到我的应用程序中。

Is it possible for me to allow and limit the access for non admin users to that view only ? So I can get the list of users from _users database into my application.

推荐答案

我从来没有能够完成很多任务CouchDB本身需要很多自定义。我一直在其他地方需要一个脚本，该脚本可以为我提供所需的信息。

I've never been able to do many tasks that require much custom with CouchDB by itself. I've always needed a script somewhere else that gives me the info that I need.

此设置对我有用的是

• 看门人Sinatra应用程序拥有对我的CouchDB的管理员权限


• 使用CouchDB的配置代理我的Sinatra应用。 httpd_global_handlers _my_service {couch_httpd_proxy，handle_proxy_req，<< http：//127.0。 0.1：9999>>}

• A gatekeeper Sinatra app that has admin access to my CouchDB
• Using CouchDB's config to proxy to my Sinatra app. httpd_global_handlers _my_service {couch_httpd_proxy, handle_proxy_req, <<"http://127.0.0.1:9999">>}

代理的原因是因为任何请求到网守将设置AuthSession令牌。在网闸内部，您可以 GET localhost：5984 / _session 传递AuthSession cookie，它将告诉您谁是发出请求，使您可以查找它们，查看它们是否具有访问权限，或者只授予所有人访问您喜欢的内容的权限。代理的另一个原因是要避免任何CORS废话，因为您是向您的服务器：5984 / _my_service 发送请求。

The reason for the proxy is because any request that comes through to your gatekeeper will have the AuthSession token set. Inside your gatekeeper, you can GET localhost:5984/_session passing the AuthSession cookie along, it will tell you who is making the request, allowing you to look them up and see if they have access, or just give everyone access to whatever you like. Another reason for the proxy is to avoid any CORS nonsense since you're making the request to yourserver:5984/_my_service.

更新

一个纯粹的客户端/ javascript解决方案意味着它在某些时候从根本上是不安全的，因为一切都很好在客户端。但是也许您的应用并不需要那样是安全的。

A purely client-side/javascript solution means that it will be fundamentally insecure at some point, since well, everything is on the client-side. But perhaps your application, doesn't need to be that secure. That's up to you.

一个解决方法可以是使您的应用程序通过预定义管理员身份验证，然后以这种方式创建更多管理员用户。您可以在应用程序启动时或根据需要进行一次身份验证。

One workaround could be to make your application authenticate as a predefined admin, and then create more admin users that way. You could authenticate once when your application boots or on an as needed basis.

问题是CouchDB认为 _users 数据库从根本上来说是特殊的，而没有给您带来像其他数据库一样有机会更改凭证要求。通常，您可以使用 _security 文档给予基于角色或基于用户的访问权限。但这对于 _users 是不可能的。

The "problem" is that CouchDB sees the _users database as fundamentally special, and doesn't give you the opportunity to change the credential requirements like other databases. Normally you would be able to use the _security document to give role based or user based access. But that's not possible with _users.

另一个替代实现可能是为了跟踪您自己的用户，并完全放弃 _users 数据库。在这种情况下，您可以设置自己的Cookie，并拥有不依赖于CouchDB身份验证方案的登录和注销方法。您可以查询自己的 _view / users ，因为它位于您的主数据库中。事情不会一tight而就，但是只要没有人对入侵您的系统感兴趣，它们就可以正常工作。 ：）

An alternative implementation might be to keep track of your own users and forgo the _users database altogether. In that case you could set your own cookies and have your own login and logout methods that don't depend on CouchDB's authentication scheme. You could query your own _view/users because it would be in your main database. Things wouldn't be locked down tight but they would work fine as long as no one was interested in hacking your system. :)

这篇关于如何减轻CouchDB对_users数据库的读/写限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！