Каковы передовые методы обслуживания DApp через HTTPS, подключения к узлу Ethereum с использованием JSON RPC/web3.js, который по умолчанию использует HTTP?

Резюме: мы обслуживаем DApp Ethereum с веб-сервера через HTTPS. DApp подключается к узлу Ethereum через JSON RPC с использованием web3.js, который использует HTTP (не HTTPS). Как поступить с этим по-хорошему?

Хорошей практикой является предоставление веб-контента через HTTPS, поэтому наше приложение обслуживается, например, с https://myhost/ . Браузеры применяют практику HTTPS до такой степени, что, когда сайт/приложение обслуживается через HTTPS, браузер требует, чтобы любые дальнейшие подключения, сделанные приложением (включая XMLHTTPRequests, выполняемые web3.js), также загружались через HTTPS.

Следовательно, когда приложение обслуживается через HTTPS, браузер блокирует вызовы к узлу Ethereum (которые всегда являются HTTP) из-за ошибки «смешанного содержимого». Протестировано на последних версиях Chrome/Windows, но я думаю, что другие браузеры дадут тот же результат. В принципе, хорошо, что браузер это делает.

Насколько мне известно, текущие реализации Ethereum не имеют функций для обслуживания конечной точки JSON RPC через HTTPS. Следовательно, это можно обойти, обернув соединение JSON RPC в HTTPS, например, создав небольшую службу Node.js.

Что я хочу знать, так это то, как другие справляются с этой ситуацией, и, возможно, есть более простое решение, чем предложенный обходной путь, который я пропустил?

Пример сообщения об ошибке «Смешанное содержимое»:

Mixed Content: The page at 'https://myhost/user/login' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://blockchain:8101/'. This request has been blocked; the content must be served over HTTPS.
HttpProvider.send @ httpprovider.js:77
finishedWithRewrite @ hooked-web3-provider.js:72
rewritePayloads @ hooked-web3-provider.js:107
next @ hooked-web3-provider.js:117
rewritePayloads @ hooked-web3-provider.js:122
send @ hooked-web3-provider.js:75
RequestManager.send @ requestmanager.js:73
Method.send @ method.js:168
SolidityFunction.call @ function.js:112
SolidityFunction.execute @ function.js:212
(anonymous function) @ VM6322:2
InjectedScript._evaluateOn @ VM6122:875
InjectedScript._evaluateAndWrap @ VM6122:808
InjectedScript.evaluate @ VM6122:664

Для web3.js это представляет собой ошибку подключения:

Uncaught Error: CONNECTION ERROR: Couldn't connect to node http://blockchain:8101, is it running?
at Object.module.exports.InvalidConnection (https://myhost/vendors/web3/dist/web3.js:3051:16)
at HookedWeb3Provider.HttpProvider.send (https://myhost/vendors/web3/dist/web3.js:4119:22)
at finishedWithRewrite (https://myhost/js/lib/hooked-web3-provider.js:72:91)
at HookedWeb3Provider.rewritePayloads (https://myhost/js/lib/hooked-web3-provider.js:107:18)
at next (https://myhost/js/lib/hooked-web3-provider.js:117:25)
at HookedWeb3Provider.rewritePayloads (https://myhost/js/lib/hooked-web3-provider.js:122:18)
at HookedWeb3Provider.send (https://myhost/js/lib/hooked-web3-provider.js:75:21)
at RequestManager.send (https://myhost/vendors/web3/dist/web3.js:5757:32)
at Method.send (https://myhost/vendors/web3/dist/web3.js:4898:59)
at SolidityFunction.call (https://myhost/vendors/web3/dist/web3.js:3915:31)

Обратите внимание, что я использую HookedWeb3Provider, но поскольку способ подключения web3.js к узлу идентичен, я не ожидаю, что это будет иметь какое-либо значение.

В настоящее время используется web3.js 0.13.0.

Не могли бы вы уточнить вопрос здесь? Запрещение смешанного содержимого HTTP/HTTPS очень распространено в браузерах. Используйте все HTTP или, еще лучше, все HTTPS.
Спасибо, уточнил заголовок и вопрос. Сохранил сообщения об ошибках для целей поиска. Суть в том, что «это распространенный случай, насколько я понимаю, как с этим справиться разработчикам DApp», а не «как мне решить мою конкретную проблему прямо сейчас».

Ответы (2)

Ответ - нет. Теперь я знаю, что вы, вероятно, не хотите это слышать, но HTTP JSON RPC никогда не предназначался для использования таким образом, чтобы он был доступен извне. RPC был создан для того, чтобы вы могли разрабатывать на своем собственном локальном узле, используя свой собственный браузер.

Я предлагаю вам настроить прокси-сервер, который будет передавать все запросы локально работающему узлу Эфириума, вместо того, чтобы позволить всем напрямую взаимодействовать с самим узлом Эфириума. Это даст вам контролируемый доступ и HTTPS.

Конечно, я хочу услышать это, особенно от того, кто знает, о чем говорит :) (здесь я преуменьшаю). Однако люди используют JSON RPC извне, в качестве примера можно просто заглянуть внутрь app.augur.net и alpha.ujomusic.com . Рассмотрю применение прокси.
Для тех, кто использует Node.js, перенос конечной точки JSON RPC в HTTPS с помощью github.com/nodejitsu/node-http-proxy прост и работает хорошо.

Картина рисует тысячу слов - Масштабируемая, отказоустойчивая и безопасная среда для узлов Go-Ethereum: защита Go Ethereum (Geth) в производстве с помощью JSON RPC с использованием HTTPS и NGINX

Масштабируемая, отказоустойчивая и безопасная среда для узлов Go-Ethereum: защита Go Ethereum (узлов Geth) в производственной среде с поддержкой JSON RPC с использованием HTTPS и NGINX

Пример конфигурации NGINX:

http { upstream nathanawgethnodes { сервер 127.0.0.1:8545 вес=3; сервер 127.0.0.2:8545; сервер 127.0.0.3:8545;
сервер 127.0.0.4:8545; }

сервер { слушать 443 ssl; имя_сервера www.nathanaw-go-eth.com; keepalive_timeout 70;

    ssl_certificate     www.example.com.crt;
    ssl_certificate_key www.example.com.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;

} }

Каковы передовые методы обслуживания DApp через HTTPS, подключения к узлу Ethereum с использованием JSON RPC/web3.js, который по умолчанию использует HTTP?
СпросиСетьПолитика конфиденциальности1y, 0v