QWebView and NetworkAccessManager. Завернуть все HTTP запросы в какой нибудь IPC |
Здравствуйте, гость ( Вход | Регистрация )
QWebView and NetworkAccessManager. Завернуть все HTTP запросы в какой нибудь IPC |
vetalvv |
26.8.2015, 19:42
Сообщение
#1
|
Новичок Группа: Новичок Сообщений: 3 Регистрация: 26.8.2015 Пользователь №: 4438 Спасибо сказали: 0 раз(а) Репутация: 0 |
Доброго времени суток.
Хочу написать простейшее клиент серверное приложение на QT. Процессы клиента и сервера собираюсь писать на С++ и QT5 Интерфейс будет на html5+css+javascript Клиентская часть приложения это будет простейший Web браузер который будет просто загружать web страничку следующим образом:
А также будет реализован простейший веб сервер на TCP сокетах с помощью QT. Примеров реализации простейшего веб сервера на QT в Интернете тоже много. Это нужно чтобы к простейшему веб серверу можно было подключаться по сети обычным вебраузером (Firefox, Chrome, etc...) Это могут быть как два отдельных (свой браузер и свой сервер) приложения (отдельных процесса), так и два треда (потока) внутри одного процесса. Как лучше сделать пока еще не решил. Вопрос заключается в следующем: Я хочу сделать так, чтобы клиент (QWebView, или QNetworkAccessManager) мог посылать HTTP запросы серверу не только по сети, а и напрямую (это именно в случае когда и клиент и сервер запущены на одном компьютере, если они будут на разных компьютерах то тут и так ясно что они смогут ТОЛЬКО по сети общаться) используя какой нибудь IPC. Ну вот например приходит в голову мысль посылать HTTP запросы серверу по DBus и получать ответ от сервера тоже по DBus, ну или может быть каким то другим способом на одном компьютере передавать HTTP запрос и получать HTTP ответ от одного процесса другому. Тоесть как я понимаю, нужно завернуть изначально идущий сетевой HTTP запрос из сети в IPC. Это все дело мне нужно для того, чтобы после реализации браузера и сервера, сконцентрироваться на разработке бизнесс логики приложения уже на JavaScript, который будет соответственно посылать серверу различные AJAX запросы. И соответственно нужно чтобы все эти AJAX запросы тоже шли к серверу не по TCP (network) а локально по IPC, и ответы на них тоже приходили по IPC. Поясню зачем все именно такое нужно. Данное приложение будет являться переносной (т.н. Portable) системой по управлению и накоплению документации. Т.е. некоторый гибрид Knowledge Tree и Wiki движка. Пересмотрел много самых разных вики движков, и переносных и самых разных. Решил писать свое, потому что в существующих не хватает нужной именно мне функциональности. Важно чтобы данную систему можно было носить с собой на флешке и смотреть с любого компа. Допустим зашел к человеку починить компьютер, у которого нет, или не доступен интернет, но нужно в своей документации посмотреть какую либо инструкцию. Поэтому нужно чтобы решение было кроссплатформенным и работало под Linux, Windows и Android. Также нужно чтобы была Web версия приложения. Например нужно коллеге по работе посмотреть какую либо инструкцию, он заходит на мой сайт, и смотрит ту же самую инструкцию того же самого приложения на сайте. Чтобы не писать два разных приложения (версия для сайта и версия переносная для десктопа), решил сразу интерфейс приложения делать на html5+css+javascript. А чтобы этот же интерфейс был переносным, решил для этого использовать QT и QWebView. Почему решил свой простейший браузер делать? да по той причниче что у любого браузера ограниечние для доступа к файловой системе, а мне нужно чтобы это локальное веб приложение могло сохранять документацию в формате html на файловую систему. А теперь про то зачем мне нужно IPC. Все дело в том, что иногда приходится работать за компьютерами, на которых у меня нет админских привилегий. Некоторые администраторы с соображений безопасности, закрывают фаерволами все лишнее. И например если запустить свое такое приложение (Portable Web сервер и Portable Browser) на таком компе, где фаерволами закрыто абсолютно все, и localhost в том числе, то фаервол может это блокировать. Отсюда и возникла мысль о том, чтобы HTTP запросы отправлять серверу не по сети, как это изначально делает QWebView через QNetworkAccessManager, а напрямую от одного процесса другому, например через DBus, или как либо еще. Да я изначально рассматривал вариант использовать qtwebkit bridge, чтобы из JavaScript получить доступ к файловой системе сохраняя файлы на диск. Но тут тогда получается для функциональности CRUD нужно также реализовывать два варианта, один для работы по сети в случае версии приложения как сайт, и второй - для локальной версии которая будет уже делать CRUD через qtwebkit bridge. Если завернуть HTTP коммуникацию между сервером и вьюэром через IPC, то можно будет сконцентрироваться только лишь на разработке серверной части сайта. Т.е. писать приложение как обычный сайт с клиент-серверной архитектурой приложения на HTML+CSS+JavaScript, а сервер будет использоваться только лишь для операций CRUD (Создавать, читать, редактировать, удалять) над документами. И если завернуть HTTP запросы через IPC, то тогда локальному клиент серверному Web приложению не будут мешать фаерволы, и не нужно будет делать несколько реализаций некоторой функциональности для локальной и веб версии приложения. Вот собственно говоря и все ТЗ. И если реализовать данную задумку завернув HTTP запросы не через сеть а через IPC, то тогда вся эта глобальная задумка с множеством вышеописанных требований к приложению красиво решается. PhantomJS тоже рассмаривал для этого. Но он не подходит потому что это просто JavaScript движок, а мне нужно еще и выполнять рендеринг HTML+CSS, плюс насколько мне известно, нет реализации под Android. QWebView Собственно говоря делает тоже самое, только оно кроссплатформенное и доступно во всех популярных платформах. Главный вопрос: Как завернуть HTTP запросы от QWebView в какой нибудь IPC чтобы отправлять их локально не через сеть другому процессу? |
|
|
lanz |
27.8.2015, 9:30
Сообщение
#2
|
Старейший участник Группа: Участник Сообщений: 690 Регистрация: 28.12.2012 Пользователь №: 3660 Спасибо сказали: 113 раз(а) Репутация: 8 |
Можно переопределить QNetworkAccessManager
http://stackoverflow.com/questions/1428053...ng-ajax-request |
|
|
Iron Bug |
27.8.2015, 11:09
Сообщение
#3
|
Профессионал Группа: Модератор Сообщений: 1611 Регистрация: 6.2.2009 Из: Yekaterinburg Пользователь №: 533 Спасибо сказали: 219 раз(а) Репутация: 12 |
а зачем так исхитряться? во всех системах есть внутренний сетевой loopback интерфейс, который просто пересылает пакеты между приложениями, минуя сетевую карту. обычно его хватает для общения с локальным http сервером.
с точки зрения админа закрывать loopback абсолютно бессмысленно. это не добавляет никакой безопасности, ибо весь код выполняется локально и если уж код попал на машину, то он может выполнить любую инструкцию. более того, закрытие loopback'а, скорее всего, вызовет полный паралич системы, потому что многие системные процессы через него общаются. |
|
|
vetalvv |
27.8.2015, 17:31
Сообщение
#4
|
Новичок Группа: Новичок Сообщений: 3 Регистрация: 26.8.2015 Пользователь №: 4438 Спасибо сказали: 0 раз(а) Репутация: 0 |
Все дело в том, что на ОС Windows, фаерволы обычно фильтруют не по пакетам а по приложениям, а также админов встречал самых разных, которые порой слишком серьезно подходят к вопросам безопасности, и закрывают фаерволом все что можно закрыть, поэтому вариант с сервером по TCP на loopback интерфейсе и не подходит.
По поводу переопределения QNetworkAccessManager-а http://stackoverflow.com/questions/1428053...ng-ajax-request Все дело в том, что сам QNetworkAccessManager умеет работать и из сетью и из файлом, и пример выше он на самом деле просто делает перезапись URL-а, но как именно например http запрос передать от одного процесса другому например используя в качестве транспорта dbus (не сеть и не файл) непонятно. |
|
|
lanz |
27.8.2015, 22:43
Сообщение
#5
|
Старейший участник Группа: Участник Сообщений: 690 Регистрация: 28.12.2012 Пользователь №: 3660 Спасибо сказали: 113 раз(а) Репутация: 8 |
Для кросплатформенного IPC, используйте например
http://nanomsg.org/index.html Перегруженный QNetworkAccessManager как раз и будет заниматся упаковкой/пересылкой. Подмена URL там просто как пример. Не вижу, в чем проблема запаковать текст запроса/ответа в сообщение. Это же обычный текст, передавайте его как строку. Сообщение отредактировал lanz - 27.8.2015, 22:45 |
|
|
vetalvv |
28.8.2015, 18:37
Сообщение
#6
|
Новичок Группа: Новичок Сообщений: 3 Регистрация: 26.8.2015 Пользователь №: 4438 Спасибо сказали: 0 раз(а) Репутация: 0 |
Да вот я как раз понимая что это обычный текст, и хочу его передавать как текст, но я вот просто немогу понять куда этот текст передавать чтобы в результате получился объект QNetworkReply, и чтобы работали слоты и сигналы.
Пока вот немогу понять в каком месте QNetworkAccessManager взаимодействует с сетью. Видел там есть метод createRequest, но там ни слухом ни духом что оно как то обращается к сокетам. Как я предполагаю, возможно есть какой то класс, который взаимодействует с сокетами, и может как раз и посылать этот передаваемыйй текст по сети (TCP) и принимать ответ, который мне походу и нужно переопределить, но что-то то я никак немогу его найти. Как передавать данные по сети через TCP сокеты я то понимаю, но вот не понимаю как оно взаимодействует с QNetworkAccessManager-ом, и кто возвращает объект QNetworkReply, ну и сюдаже сигнлы и слоты. |
|
|
Текстовая версия | Сейчас: 23.4.2024, 10:15 |