Move _users _design/auth into Erlang

[wohali]

Right now we enforce _users to have a _design/auth ddoc with a VDU in it that we force the value of.

Expected Behavior

_users VDU should be hard-coded in Erlang and enforce the same rules as the JS VDU today.

Current Behavior

We forcibly create _users/_design/auth and forcibly maintain the contents of its VDU.

Context

This would be a prerequisite towards an optional no-couchjs version of CouchDB 2.x, something we discussed in janl/couchdb-next#23 .

[nickva]

Same thing would be good for the _replicator db's _design/_replicator VDU doc. It would be simpler if it was in Erlang

[davisp]

+1 with the caveat that we should't do this via enabling the erlang view server since that's leads to other issues (unless until Erlang figures out sandboxing).

[janl]

The first steps would be to transliterate these two files into native Erlang. After that, we could figure out how we can hard-wire them into their respective databases without enabling the Erlang view server:

https://github.com/apache/couchdb/blob/master/src/couch/include/couch_js_functions.hrl
https://github.com/apache/couchdb/blob/master/src/couch_replicator/src/couch_replicator_js_functions.hrl

This would make a great first time contribution, any one of the functions would already be a good help.

See https://github.com/apache/couchdb/blob/master/test/javascript/tests/erlang_views.js for a few examples of how to write ddoc functions in Erlang.

Please no comments about us embedding JS in Erlang in one case, and Erlang in JS in the other ;D

[abc3]

Hi to all! I have made translation functions to erlang for _users view.

@janl check, please, this
https://github.com/abc3/couchdb/blob/851a8163fa9e1719da0017f61701162bcd17e703/src/couch/include/couch_erl_functions.hrl

Did you mean some like this?

[wohali]

@abc3 can you open a pull request for this please? Your patch got lost :)

[abc3]

Yes, sure.

[igorski89]

I understand the same will have to be done for _design/_replicator in the _replicator db?

[nickva]

@evsukov89 yes, that would be great to get _design/_replicator into Erlang and not it as a "system" _design doc.

[igorski89]

@nickva but wouldn't this not be enough? porting the validation functions to Erlang is only half the job, the rest is to integrate them directly into couch code that already handles _users, _replicator, etc. Otherwise erlang query server has to be enabled by default, which is a security concern as I understand

[wohali]

There is already a pull request for this ticket:

#1146

@nickva any chance to review?

@evsukov89 feel free to open a new issue to track moving _design/_replicator's VDU.