По поводу jQuery выше отписывался — в electron из-за наличия module и window единовременно jQuery начинает колбасить. потому приходится изгаляться. Напрямую через скрипт просто так не подключишь.
Еще смешнее получается при использовании preload и включенной ноде. Как в таком случае поступать. так и не придумал. в итоге тупо выключил ноду для окна(благо. в скрипте из preload контекст ноды доступен в любом случае).
Про global для ноды в курсе. но не знал. что это справедливо и для BrowserWindow, спасибо.
У электрона есть свои преимущества, Как упомянул ниже, для меня это ES6(кстати, не понял, почему не работает в nw.js, если у него на данный момент хром посвежее. Включать нужно, что ли?), и более полноценная консоль(к примеру, то же сохранение css в nw.js не работает). Ну и electron-rebuild — удобная штука(не в курсе, есть ли аналоги у nw).
Что до размера — 123МБ у свежего nw.js, 120 — у электрона.
Возможно, такая проблема возникает только внутри скриптов, подключаемых через require или index.html лежит в корне, а не в какой-либо папке? По крайней мере, с такой проблемой не сталкивался.
Кстати, еще не помешало бы упомянуть, что как минимум jQuery сходу не заведется(если не ошибаюсь, связано с проверкой на окружение) и вышеупомянутая строчка как раз является фиксом.
Еще бы не помешало упомянуть про то, что index.html не обязательно должен находиться на локальной машине. Довольно удобным способом является использование BrowserWindow в качестве обычного браузера, но с подключением скрипта с нодой с указанием через параметр preload и отключением контекста ноды для безопасности(ну или без отключения, если таковая не требуется).
Насчет глобального объекта — не уверен, сработает ли такой фокус. Разве если в main.js добавить свойство в тот же process, оно будет доступно в "клиентской" части? Если да — спасибо, пригодится.
Про выгрузку модулей было бы интересно почитать, хотя не совсем понятно, зачем это нужно, с учетом того, что при обновлении страницы перезагружается и нода.
Ну и главное — планируется ли написание других статей по электрону? Перешел на него с nw.js(приманило наличие ES6 из коробки и рабочее сохранение файлов из devtools), было бы интересно почитать статьи об особенностях использования.
Тор/VPN/proxy/анонимайзеры/бла-бла-бла, к примеру, очень удобно использовать для обхода разного рода блокировок по странам в тех же игрушках или сайтах. К примеру, у нас заказчики из Израиля, в котором провайдеры банят Украину. Без подмены IP даже мелкие правки внести несколько… проблематично. Да, шифрование как таковое не нужно, но TOR/VPN для постоянной работы использовать удобнее всего.
Если не ошибаюсь, на хабре недавно видел статью по поводу прокидывания сети для удаленных сотрудников через VPN. Вот и еще 1 пример — компаниям иногда нужно по тем либо иным причинам выдавать удаленный доступ, при этом шифруя данные, что бы уменьшить риск их потерь. Шифрование используется далеко не только против государства — те и так найдут, что им надо, шифруй не шифруй. В первую очередь оно нужно от всяких любопытствующих.
Если отказываться от шифрования, тогда нужно отказаться и от HTTPS, всяких secret token'ов социалок и прочей разной разности.
Обсуждать мнение по поводу минусов в карму не хочу, но вообще что-то в этой аналогии есть. Что до негативных новостей и шифрования — тут все очень просто: о позитивных примерах тупо никто не пишет, их просто используют. Не будете же Вы писать новость в духе "бухгалтер М. сэкономил предприятию 3млн долларов, воспользовавшись калькулятором Windows"? Это само собой подразумевается.
Да, разного рода даркнеты и прочая хняба используется, как правило, для разного рода вредоносной деятельности — но это не значит, что сама технология порочна. Это всего лишь значит, что практически любое положительное начинание можно при желании испоганить.
Из первого, что приходит в голову — а там точно ANSI, а не UTF?
У фриды на выбор есть Memory.allocUtf8String(str), Memory.allocUtf16String(str), Memory.allocAnsiString(str), может, стоит попробовать 1 из них?
Еще можно попробовать для проверки найти набор байт(взять из того же artmoney/cheatengine).
Еще тупой вопрос — а точно этот адрес принадлежит главному модулю?
Ну и если есть какой-никакой скилл в реверсе, можно попробовать найти адреса нужных функций и перехватывать их, вместо поиска строк.
В самом посте содержится простой пример — возможность изменения прокси для каждого запроса по отдельности либо по необходимости. Кроме того, удобнее все держать в 1 пакете, нежели в отдельных приложениях, для каждого из которых нужно писать инструкцию в случае доставки конечному пользователю. Также fiddler позволяет перехватывать и менять не только управляемые пользователем запросы, а вообще весь входящий/исходящий трафик, включая(если не ошибаюсь) веб-сокеты. Соответственно, получаем достаточно удобный инструмент для отладки происходящего на сайте, включая те случаи, когда отладчика вебкита недостаточно(впрочем, никто не мешает использовать и его тоже). К примеру, та же консоль отлично подходит для тех случаев, когда нужно увидеть исходящие/входящие запросы, однако довольно проблематично поменять, к примеру, User-Agent.
DLL нет. код можно менять на лету в .CS. Кроме того. ffi умеет вроде только unmanaged dll. Впрочем. ffi я тоже использовал. но для других задач. удобная штука.
Небольшой вопрос из разряда «здрасте, я Капитан Очевидность»: какого рода произошли изменения в js? Перенесли часть логики на ajax? Если да-то знатно проще самому выполнять ajax запрос и получать готовый результат в виде json или чего они там юзают. Если нет — то какого рода были вообще изменения?
А вообще для вещей подобного плана кроме nw.js или питона сокомпани неплохо работает связка awesomium+C#+CSQuery(ну или любой другой хороший парсер). Если нужна огромная скорость парсинга — то code.google.com/p/majestic13 (крайне неудобная гадость, но по скорости работы уделывает большинство из парсеров, которые я вообще пробовал(давал прирост где-то на 40мс со страницы, что при большом кол-ве страниц довольно-таки заметный прирост). Парсил когда-то магазинчик, разгонял где-то под 40-50 страниц в секунду за счет многопоточности, правда ЦПУ жрало неимоверно).
Еще смешнее получается при использовании preload и включенной ноде. Как в таком случае поступать. так и не придумал. в итоге тупо выключил ноду для окна(благо. в скрипте из preload контекст ноды доступен в любом случае).
Про global для ноды в курсе. но не знал. что это справедливо и для BrowserWindow, спасибо.
В Вашем случае отлично подойдет electron-rebuild, Удобен и пока что не подводил.
Что до размера — 123МБ у свежего nw.js, 120 — у электрона.
Возможно, такая проблема возникает только внутри скриптов, подключаемых через require или index.html лежит в корне, а не в какой-либо папке? По крайней мере, с такой проблемой не сталкивался.
Кстати, еще не помешало бы упомянуть, что как минимум jQuery сходу не заведется(если не ошибаюсь, связано с проверкой на окружение) и вышеупомянутая строчка как раз является фиксом.
По поводу взаимодействия main.js/index.html и передачи переменных напрямую не совсем верно. Точнее говоря, напрямую передать нельзя, а вот посредством ipc — пожалуйста.
https://github.com/atom/electron/blob/master/docs/api/ipc-main.md
https://github.com/atom/electron/issues/991
Кстати говоря, это же справедливо и для webview.
Еще бы не помешало упомянуть про то, что index.html не обязательно должен находиться на локальной машине. Довольно удобным способом является использование BrowserWindow в качестве обычного браузера, но с подключением скрипта с нодой с указанием через параметр preload и отключением контекста ноды для безопасности(ну или без отключения, если таковая не требуется).
Насчет глобального объекта — не уверен, сработает ли такой фокус. Разве если в main.js добавить свойство в тот же process, оно будет доступно в "клиентской" части? Если да — спасибо, пригодится.
Про выгрузку модулей было бы интересно почитать, хотя не совсем понятно, зачем это нужно, с учетом того, что при обновлении страницы перезагружается и нода.
Ну и главное — планируется ли написание других статей по электрону? Перешел на него с nw.js(приманило наличие ES6 из коробки и рабочее сохранение файлов из devtools), было бы интересно почитать статьи об особенностях использования.
Если не ошибаюсь, на хабре недавно видел статью по поводу прокидывания сети для удаленных сотрудников через VPN. Вот и еще 1 пример — компаниям иногда нужно по тем либо иным причинам выдавать удаленный доступ, при этом шифруя данные, что бы уменьшить риск их потерь. Шифрование используется далеко не только против государства — те и так найдут, что им надо, шифруй не шифруй. В первую очередь оно нужно от всяких любопытствующих.
Если отказываться от шифрования, тогда нужно отказаться и от HTTPS, всяких secret token'ов социалок и прочей разной разности.
Обсуждать мнение по поводу минусов в карму не хочу, но вообще что-то в этой аналогии есть. Что до негативных новостей и шифрования — тут все очень просто: о позитивных примерах тупо никто не пишет, их просто используют. Не будете же Вы писать новость в духе "бухгалтер М. сэкономил предприятию 3млн долларов, воспользовавшись калькулятором Windows"? Это само собой подразумевается.
Да, разного рода даркнеты и прочая хняба используется, как правило, для разного рода вредоносной деятельности — но это не значит, что сама технология порочна. Это всего лишь значит, что практически любое положительное начинание можно при желании испоганить.
func(123);
Так можно вызывать нативные функции. Что до явовских — не в курсе, не пробовал.
Что до поиска адресов, что получится, если искать паттерн в байтах вместо строки?
У фриды на выбор есть Memory.allocUtf8String(str), Memory.allocUtf16String(str), Memory.allocAnsiString(str), может, стоит попробовать 1 из них?
Еще можно попробовать для проверки найти набор байт(взять из того же artmoney/cheatengine).
Еще тупой вопрос — а точно этот адрес принадлежит главному модулю?
Ну и если есть какой-никакой скилл в реверсе, можно попробовать найти адреса нужных функций и перехватывать их, вместо поиска строк.
А вообще для вещей подобного плана кроме nw.js или питона сокомпани неплохо работает связка awesomium+C#+CSQuery(ну или любой другой хороший парсер). Если нужна огромная скорость парсинга — то code.google.com/p/majestic13 (крайне неудобная гадость, но по скорости работы уделывает большинство из парсеров, которые я вообще пробовал(давал прирост где-то на 40мс со страницы, что при большом кол-ве страниц довольно-таки заметный прирост). Парсил когда-то магазинчик, разгонял где-то под 40-50 страниц в секунду за счет многопоточности, правда ЦПУ жрало неимоверно).