Серверный JavaScript: SpiderMonkey и http-запросы

[blessmaster]

Вопрос в следующем: возможно ли из серверного javascript-кода делать произвольные http запросы на движке SpiderMonkey и что для этого требуется? В интернете находится множество примеров, но они - для v8 и node.js и в данном случае не помогают.

Стоит такая задача: есть сервер с CouchDb имеющий ряд ограничений в плане настроек доступа к базе, которые не позволяют тонко ограничивать доступ на чтение - либо всё, либо ничего. И если это ещё терпимо при разработке сервисов, в которых предполагается, что на одну базу не более одного пользователя и никто кроме ограниченного круга доверенных лиц не должен получать доступ к конфиденциальной информации в этой базе, то это совершенно не применимо для создания коллективных сервисов, где у каждого пользователя своё персональное пространство, в котором он может произвольным образом делать доступными часть ресурсов другим пользователям.
Особенность CouchDb заключается в том, что при построении запроса определённым образом, он выдаёт клиенту всю информацию, предоставляя уже клиенту разбираться, что ему надо, а что нет.
Традиционное решение задач подобного рода - создание промежуточного звена между клиентом и базой данных, которое фильтрует выдаваемые данные.
У CouchDB есть своё собственное "среднее звено", но оно служит в основном в "оформительских" целях - для сборки клиента, который будет отображать полученные данные.
Если бы было возможным с помощью javascript на сервере создавать вложенные запросы, то это решило бы проблему без привлечения дополнительных надстроек.

Upd. Кстати, если кто-то может дать ссылку на удовлетворительное руководство по серверному скриптингу на JS SpiderMonkey, был бы очень признателен.

[Kolyaj]

Почему вы хотите использовать на сервере именно JavaScript? Почему именно SpiderMonkey?

[blessmaster]

Они уже использованы - речь идёт про CouchDB и его фреймворк CouchApp. Если есть выбор, мне было бы интересно об этом узнать.

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

[Kolyaj]

Зачем вам какой-то фреймворк? Для взаимодействия с CouchDB достаточно любого HTTP-клиента, коих полно как в PHP, так и в node.js имеется.

Ещё непонятно, как связан CouchApp и SpiderMonkey. Сам CouchApp на чём написан?

[SV0L0CH]

По SpiderMonkey удалось выяснить что готовых к использованию решений нет. Чтобы что-нибудь сделать, надо писать свою версию интерпретатора с необходимой функциональностью на C и только после этого его можно будет использовать. Очень неудобно по сравнению с решениями на V8.
Так что не найдя альтернатив nodejs, я полностью забил на SpiderMonkey как на серверную платформу.
Кроме того, в SpiderMonkey нет встроенного объекта JSON как и других ecma5 вкусностей, что делает его непригодным для решения данной задачи(хотя можно задействовать дополнительные библиотеки).
Думаю, тут целесообразней будет проверить наличие на сервере python и воспользоваться его JSON библиотеками (скорей всего python таки есть). В крайнем случае на Perl тоже должны быть решения.

[blessmaster]

Зачем вам какой-то фреймворк? Для взаимодействия с CouchDB достаточно любого HTTP-клиента, коих полно как в PHP, так и в node.js имеется.

Ещё непонятно, как связан CouchApp и SpiderMonkey. Сам CouchApp на чём написан?

CouchDB можно рассматривать как сервер веб-приложений; для реализации этой идеи в CouchDB встроен производительный веб-сервер, а программный код, как и данные, сохраняется в той же базе данных. Для автоматизации работы с приложениями CouchDB используется утилита CouchApp.
http://ru.wikipedia.org/wiki/CouchDB

По пунктам:

PHP и иже с ним - 3d-party. Зачем преумножать сущности, если CouchDB может работать без лишних посредников и сама является http-сервером?

CouchApp - это фреймворк данный от разработчика и интегрированный в работу CouchDb, позволяющий участвовать в формировании ответов от сервера и их трансформации прозрачно для клиента. То есть то, что мы получаем по http, когда нам "достаточно любого HTTP-клиента" - уже прошло на ранней стадии через CouchApp (если это предусмотрено архитектурой серверной части приложения).

SpiderMonkey - движок JS использованный в CouchDB для запуска JS-кода. Он обслуживает как сам код map/reduce функций в базе, если они написаны на JS, так и дополнения CouchApp.

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

Управление доступом в CouchDB реализовано на уровне баз. То есть просто так нельзя запретить клиенту получить полное содержимое базы и всех полей документов, если у него есть доступ на базу. Либо можно читать всё, либо ничего. Мы ищем наименее затратное средство реализации разграничений доступа в плане ресурсов сервера и команды разработчиков. И любой посредник в лице PHP, Python'а и прочих - не лучшее решение в данном случае, лишающее всех прелестей прямого доступа к базе по HTTP.

Впрочем, вариант посредника мы тоже рассматриваем, если его удастся сделать минималистичным и "незаметным", но пока что этот вариант оставлен как крайнее решение, при невозможности найти другие.

[blessmaster]

По SpiderMonkey удалось выяснить что готовых к использованию решений нет.[...]
Кроме того, в SpiderMonkey нет встроенного объекта JSON как и других ecma5 вкусностей, что делает его непригодным для решения данной задачи(хотя можно задействовать дополнительные библиотеки).

То есть всё настолько печально. Насколько я понял из Вашего ответа SpiderMonkey - это некий полуфабрикат интерпретатора, предназначенный исключительно для допиливания напильником в интегрирующем проекте?

В CouchDb есть объект JSON, видимо его таки подключают. Хорошо, возможно вопрос решается подключением дополнительных модулей и надеюсь подобное расширение возможно делать не влезая в код CouchDb.

[SV0L0CH]

Насколько я понял из Вашего ответа SpiderMonkey - это некий полуфабрикат интерпретатора, предназначенный исключительно для допиливания напильником в интегрирующем проекте?

Вообще какое-то недоразумение, JS и Lua рассматриваются исключительно как встраиваемые языки. Нормальная реализация библиотек и расширений предусмотрена только в V8. Можно использовать один и тот же код хоть в nodejs хоть в chrome(хотя в этом вопросе есчё до конца не разобрался).
Что касается CouchApp, то я не знаю что это из себя представляет, однако как-правило приложения на JS хорошо поддаются расширению и дополнениям. Тут ведь надо всего лишь прикрутить фильтр для запросов от клиента, как я понял.
В крайнем случае про комплект mongodb+nodejs я слышал в основном положительные отзывы, так что могу рекомендовать.

[blessmaster]

Тут собственно проблема не в том, как обработать ответ от сервера - он-то как раз приходит в JSON и проблем нет. Совершенно непонятно как сделать сам http-запрос, хоть какой-то. Объекта XMLHttpRequest нет, на require('request') - ругается, что нет такого. При попытке найти хоть какую-то документацию на SpiderMonkey - все пути ведут на API для встраивания, где ни слова по интересующей теме. Возможно есть другие способы формирования запросов?

От Монго пока отказались по причине крайне негативных отзывов о его надёжности. Предназначение будущей разработки - корпоративный сектор, где нужна высокая надёжность и потери данных - потери прибыли. А пока что сами разработчики Монго не рекомендуют брать его в эту сферу.

[blessmaster]

Тут ведь надо всего лишь прикрутить фильтр для запросов от клиента, как я понял.

Ну получается, что-то в этом роде. Только фильтр нужен для ответов, поскольку база выдаёт по запросу клиента любой документ и всё его содержимое. А это как бы не совсем хорошо, если часть документов помечена грифом "только для служебного использования" или некоторые поля документа должны видеть только сотрудники соответствующего отдела.
Один из выходов - разбиение на множество баз и репликация только нужных данных между ними, но это крайне ограниченный путь ведущий к значительному перерасходованию ресурсов.
Но даже если "клиент" вполне лоялен, уязвимость через исполнение "левого" скрипта в браузере клиента вполне может привести к утечке конфиденциальной информации, хотя это уже отдельная тема.