const MAINET_RPC_URL = 'https://mainnet.infura.io/metamask';
const ROPSTEN_RPC_URL = 'https://ropsten.infura.io/metamask';
const KOVAN_RPC_URL = 'https://kovan.infura.io/metamask';
const RINKEBY_RPC_URL = 'https://rinkeby.infura.io/metamask';
var ipaddr_prov_rinkeby = "http://35.185.16.215:8545";
var ipaddr_prov_main = "http://104.197.142.219:17348";
Topic: Внедрение интерфейса к ethereum смарт-контракту. (Read 846 times)
5. Если такое можно провернуть, то где взять адреса ноды с RPC и web3.js, которые мне помогут сосредоточиться на тестировании интерфейса а не на запуске всей этой архитектуры.
Так же интересуюсь подобным вопросом.
Появились ли у вас интересные находки?
Взлом сайта подразумевает не только получение доступа к нему и увод с него файлов с паролями или инфы из БД. Обычно при взломе на сайт заливается шелл, который что-то вытворяет от имени сайта, например, перенаправляет пользователей куда-нибудь, показывает левую рекламу, что-то ворует из оставленного пользователями. Например, пароли...
Конечно это не 100% безопасность. Но это убережет большое кол-во пользователей от потерь в случае взлома(Вы же будете мониторить ситуацию, правда?). Это намного лучше чем хранить приватные ключи на сайте. Тогда в случае взлома, все пользователи потеряют все.Безопаснее (но дороже за счёт комиссий на переводы) уводить деньги с потенциально небезопасных аккаунтов на сайте на свои личные аккаунты) на время, когда сайт не нужен. Если же речь о небольших суммах, то можно и не уводить.
Кто это должен делать? Давайте разберем все возможные варианты:1. Это делает скрипт на сайте(автоматически). В этом случае приватный ключ хранится на сайте в каком либо виде, и его можно получить и при взломе все выведут. Небезопасно
2. Это делает админ(в ручном режиме). Ну тогда все транзакции должен подтверждать админ вручную с помощью метамаска(например). Это безопасно но не удобно.
Вообщем есть две крайности,
1. Все автоматизировано, деньги сами переводятся туда сюда, смартконтракты сами запускаются. Вас взломали - деньги вы потеряли.
2. Все подтверждается вручную.
3. это может делать сам пользователь, добровольно, получив предварительное уведомление о небезопаснсоти хранения больших сумм на аккаунте.
Восхищаюсь такими людьми имеют желание прилагать минимум усилий и жить в шоколаде. З такими светлое буржуазное будущее. Один творец и мыслитель, а кругом масса хищников-прилипал. Так будем двигаться в светлое будущее та ша на горбу приживателей.
лень двигатель прогресса.
Взлом сайта подразумевает не только получение доступа к нему и увод с него файлов с паролями или инфы из БД. Обычно при взломе на сайт заливается шелл, который что-то вытворяет от имени сайта, например, перенаправляет пользователей куда-нибудь, показывает левую рекламу, что-то ворует из оставленного пользователями. Например, пароли...
Конечно это не 100% безопасность. Но это убережет большое кол-во пользователей от потерь в случае взлома(Вы же будете мониторить ситуацию, правда?). Это намного лучше чем хранить приватные ключи на сайте. Тогда в случае взлома, все пользователи потеряют все.Безопаснее (но дороже за счёт комиссий на переводы) уводить деньги с потенциально небезопасных аккаунтов на сайте на свои личные аккаунты) на время, когда сайт не нужен. Если же речь о небольших суммах, то можно и не уводить.
Кто это должен делать? Давайте разберем все возможные варианты:1. Это делает скрипт на сайте(автоматически). В этом случае приватный ключ хранится на сайте в каком либо виде, и его можно получить и при взломе все выведут. Небезопасно
2. Это делает админ(в ручном режиме). Ну тогда все транзакции должен подтверждать админ вручную с помощью метамаска(например). Это безопасно но не удобно.
Вообщем есть две крайности,
1. Все автоматизировано, деньги сами переводятся туда сюда, смартконтракты сами запускаются. Вас взломали - деньги вы потеряли.
2. Все подтверждается вручную.
Восхищаюсь такими людьми имеют желание прилагать минимум усилий и жить в шоколаде. З такими светлое буржуазное будущее. Один творец и мыслитель, а кругом масса хищников-прилипал. Так будем двигаться в светлое будущее та ша на горбу приживателей.
Взлом сайта подразумевает не только получение доступа к нему и увод с него файлов с паролями или инфы из БД. Обычно при взломе на сайт заливается шелл, который что-то вытворяет от имени сайта, например, перенаправляет пользователей куда-нибудь, показывает левую рекламу, что-то ворует из оставленного пользователями. Например, пароли...
Безопаснее (но дороже за счёт комиссий на переводы) уводить деньги с потенциально небезопасных аккаунтов на сайте на свои личные аккаунты) на время, когда сайт не нужен. Если же речь о небольших суммах, то можно и не уводить.
Безопаснее (но дороже за счёт комиссий на переводы) уводить деньги с потенциально небезопасных аккаунтов на сайте на свои личные аккаунты) на время, когда сайт не нужен. Если же речь о небольших суммах, то можно и не уводить.
про небезопасность хранения ключей на хостинге на каждом углу рассказывают. Ну а почему бы не организовать работу без хранения больших сумм на таких
Наверное же не зря предупреждают 
Мне кажется можно сделать так:
1. На сайте сгенерить сид для кошелька
2. Пользователь вводит пароль от кошелька
3. На сервере сохраняем только сид и адрес кошелька, пароль не сохраняем. Таким образом если у нас только сид без пароля сервер не может перевести деньги с кошелька.
4. Когда нужно вызвать смартконтракт спрашиваем у пользователя пароль и осуществляем траназкцию.
Минус такого: если нужно сделать транзакцию без пользователя (например по крону) то нужно писать емейлы пользователю чтобы он зашел и ввел пароль
про небезопасность хранения ключей на хостинге на каждом углу рассказывают. Ну а почему бы не организовать работу без хранения больших сумм на таких аккаунтах, например так:
1. зарегистрировался пользователь в панели, сгенерировать ему новый кошелёк с хранимыми на сайте ключами
2. пользователю передали расценки на работу и его адрес для пополнения, уведомив о небезопасном хранении и порекомендовав минимальный перевод достаточный для работы.
2a. или вместо пункта 2 порекомендовали завести самостоятельно кошелёк на mew (или другой нормальный) и по выходу с панели - отправлять остатки с баланса аккаунта на сайте на этот, более безопасный, кошелёк, в случае работы с не маленькими суммами.
3. организовать процесс по смене кошелька пользователя на сайте в случае его взлома.
1. зарегистрировался пользователь в панели, сгенерировать ему новый кошелёк с хранимыми на сайте ключами
2. пользователю передали расценки на работу и его адрес для пополнения, уведомив о небезопасном хранении и порекомендовав минимальный перевод достаточный для работы.
2a. или вместо пункта 2 порекомендовали завести самостоятельно кошелёк на mew (или другой нормальный) и по выходу с панели - отправлять остатки с баланса аккаунта на сайте на этот, более безопасный, кошелёк, в случае работы с не маленькими суммами.
3. организовать процесс по смене кошелька пользователя на сайте в случае его взлома.
2. Заставлять пользователей ставить metamask (не политкорректно)
вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.
вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.
На текущий момент это самый лучший вариант запуска смартконтрактов на стороне пользователя.
Запускать функции смартконтракта, вносить деньги на его счет. Это может работать только если пользование сервисом платное. Тогда можно выйти хотя бы в 0. Но безопасность этого решения нулевая. Взломают сайт получат доступ ко всем кошельками пользователям и выведут все деньги с них
2. Заставлять пользователей ставить metamask (не политкорректно)
вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.
вот пример дружелюбного интерфейса пользователя, оплачивающего самостоятельно сервис:
Зашёл на сайт, залогинился в панель управления, внёс деньги на счёт при помощи VISA, начал работать с функциональностью смартконтракта за свои деньги.
Т.е. пользователь не заморачивается даже открытием собственной учётной записи в эфириуме, не только что не ставит дополнительных плагинов, или устанавливает браузер, которым он может и не пользуется. Для такой работы нужно связать UI и блокчейн со смартконтрактом без участия пользователя. Создать (подтянуть) его учётную запись в блокчейне, пополнить её эфиром по текущему курсу и выполнять операции со смарт контрактом от её имени.
Пока не будет такого подхода, использование смарт контрактов массами будет тормозиться.
подниму тему - как обычно разворачивают готовые приложения с вёб интерфейсом на базе смарт контрактов?
1. Заливают смартконтракт в сеть.
2. Делают html/js которое работает с MetaMask
Вот пример такого шаблона https://github.com/ConsenSys/truffle-webpack-demo
Вот я сам делал для одного хакатона(демо). Должен быть активен плагин метамаск и выбрана ropsten сеть
https://worlaxgraphics.github.io/woroom-hackathon/dest/
подниму тему - как обычно разворачивают готовые приложения с вёб интерфейсом на базе смарт контрактов?
так, вот это получилось победить: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8545/
теперь могу тестировать на локальном компьютере, причём и с локальным web сервером и с обычного хостинга. Теперь вторая часть вопроса:
Какая наиболее типовая архитектура при разворачивании децентрализованного приложения в продакшене? Вижу несколько вариантов:
1. Выделенный сервер с полной установкой ноды (дорого)
2. Заставлять пользователей ставить metamask (не политкорректно)
3. Вариант verudza - заказать услугу выделенной ноды (это похоже на новое решение, не думаю что многие им пользовались)
4. Поднять ноду на отдельном компьютере со статичным сетевым IP и держать его включенным всегда (сомневаюсь что так вообще кто-нибудь делает)
5. Другой, не ведомый мне вариант
теперь могу тестировать на локальном компьютере, причём и с локальным web сервером и с обычного хостинга. Теперь вторая часть вопроса:
Какая наиболее типовая архитектура при разворачивании децентрализованного приложения в продакшене? Вижу несколько вариантов:
1. Выделенный сервер с полной установкой ноды (дорого)
2. Заставлять пользователей ставить metamask (не политкорректно)
3. Вариант verudza - заказать услугу выделенной ноды (это похоже на новое решение, не думаю что многие им пользовались)
4. Поднять ноду на отдельном компьютере со статичным сетевым IP и держать его включенным всегда (сомневаюсь что так вообще кто-нибудь делает)
5. Другой, не ведомый мне вариант
всем больше спасибо, но ребята, проблема у меня, как у обособленного самообучающегося разработчика не в том, что бы найти пример кода на js, который подключается к ноде и вызывает функции смарт контрактов, а проблема в правильном построении архитектуры и налаживании рабочего процесса. Так, для тестирования, я пробовал подключиться со своего сайта на сервере хостера - проблема с доступом к локальной ноде. Запустил сервер apache (на виртуалке) и стреляю с localhost получаю ошибку Cross-Origin Request Blocked... Пошёл в контору которая решила заняться смарт контрактами профессионально у меня в районе, что бы опыта у них поднабраться, они спрашивают, как я представляю работу со мной, если у меня уже есть работа((((((
Я всем реклмендую фреймворк truffle. В нем есть шаблон который включает в себя простенький контракт токена и веб интерфейс взаимодействия с ним. Это все работает на webpack. Сам такое делал, работает хорошо
оченьждёмс. а пока, не знаете как вот такое побороть:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8545/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
архитектура стандартная:
локальный web сервер apache
html+js+web3
geth -dev
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8545/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
архитектура стандартная:
локальный web сервер apache
html+js+web3
geth -dev
написал вкратце, как это делается, но статейка еще не прошла модерацию. Ждемс.
Jump to: