Онлайн сервис - "NotePad"

Пишу онлайн сервис - "NotePad". Не могу определиться с функционалом. Нужна помощь, ибо есть такие идеи, которые наверно выходят за рамки закона А именно: Хочу позволить пользователю открывать страницы по URL, а точней выкачивать HTML страницу и предоставлять её пользователю для взаимодействия с помощью javascript.

Предусматривается 2 рабочих окна: В первом страница с запрашиваемым URL, а во втором - блокнот (текстовое поле), в котором можно написать скрипт и, работать со сторонними ресурсами. Как вариант, если страницы можно будет выкачивать, - добавить опцию: Создать свою "кнопку". То есть пользователь сможет писать свой набор инструментов (типа - парсеры, калькуляторы и т.п.) и сохранять для дальнейшей работы.

Как и в обычном блокноте, можно будет писать всё что угодно, вплоть до создания своих страниц HTML, которые будут хранится на сервере и, при желании, будут доступны для индексирования поисковыми роботами. На этом пока-что пожалуй всё.

Вопрос: На сколько законно выкачивать страницы, если их нельзя будет сохранять? Понятное дело, частота запросов будет лимитирована. Да и вообще: Нужна ли такая опция?)

0

Если вы хотите закачивать чужой url в frame, а потом что то с ним сделать то у вас ничего не получится. Даже скриншот frame через javascript не сделать. Атака называется межсайтовый скриптинг. Все дыры в браузерах давно пофиксены. Большинство сайтов даже в iframe закачку заблочило.

Если использовать свой сервак в качестве прокси - то проблем там тоже гора. Многие сайты с такими прокси умело борятся.

0

Сообщение от developer123 Если вы хотите закачивать чужой url в frame

Я хочу закачивать на сервер во "временную память", и представляться сайтам как пользователь, который осуществляет этот запрос (на сколько это возможно...).

Сообщение от developer123 Если использовать свой сервак в качестве прокси - то проблем там тоже гора. Многие сайты с такими прокси умело борятся.

Планируется передавать в RequestProperty данные этого пользователя, чтоб он мог взаимодействовать с муляжом запрашиваемого URL, а не с реальным сайтом.

0

Сообщение от 1name Планируется передавать в RequestProperty данные этого пользователя

Как вы куки будите передавать? Или javascript storage? Некоторые сайты делают 100500 всяких редиректов на всякие авторизационные серверы. Плюс сама страница может статику закачивать опять же со 100500 мест. И опять же хранить всякие промежуточные ID на серверах. Всякие спамеры научились даже в tls рукопожатиях хранить данные.

Честно говоря не понятно зачем это всё.

0

Сообщение от developer123 Как вы куки будите передавать?

Если честно, то пока не думал над этим вопросом...

Сообщение от developer123 Честно говоря не понятно зачем это всё.

Поэтому я и поставил вопрос таким образом, чтоб правильно определить целесообразность, и вы на него ответили

Сообщение от developer123 Многие сайты с такими прокси умело борятся.

за что вам отдельное - спасибо. Не буду тратить на это время.

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

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

Безусловно, для одного это очень большой объём работы. Поэтому хочется интегрировать самое востребованное (в рамках моих возможностей). При этом всё должно быть просто и понятно, как в обычном NotePad.

0

Сообщение от developer123 Как вы куки будите передавать?

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

0

Если клиент подсоединяется к сайту по tls - то вы никак не повлияете на трафик. А сейчас все сайты работают по tls. Вам придётся подключаться к сайту своим сервером - и куки будут вашего сервера. Потом отдавать страницу клиенту. На клиенте появятся свои куки. Не забываем что куки можно создавать через javascript и работать с ними то же через javascript. А если учесть что современные страницы это не голый html а интерактивно строящийся реалтайм конструктор - со множеством запросов в реальном времени - то отладка ад.

Единственный способ получить доступ к станице на стороне клиента - это плагин для браузера.

0

Сообщение от developer123 Если клиент подсоединяется к сайту по tls - то вы никак не повлияете на трафик. А сейчас все сайты работают по tls. Вам придётся подключаться к сайту своим сервером - и куки будут вашего сервера.

Можно выделить канал обмена данных в отдельном потоке. Что собственно и происходит в таком случае. То есть создаётся TCP/IP соединение, где клиент и удалённый сервер общаются по протоколу HTTP, а прокси сервер выступает маршрутизатором. Через него проходят все данные, которые пишутся в буфер обмена. В таком случае, для удалённого ресурса, сессия выглядит как "пользователь вошёл с другого ПК через другой браузер". Если записывать сессию, можно привязывать события к конкретному клиенту. В этом случае даже не нужно знать о чём общается клиент с удалённым ресурсом, а просто упаковывать как пакет данных (байтов). Проверяя ответ сервера, можно передать управление "браузером", в случае возврата ответа "введите капчу". Я так когда-то экспериментировал с известными поисковыми системами (Google, Yandex, Bing) передавая поисковые запросы в разных потоках. Уже не помню как я это делал, но тем не менее оно работало...

Сообщение от developer123 Единственный способ получить доступ к станице на стороне клиента - это плагин для браузера.

вебдрайвер это и есть плагин для браузера. У меня под эту тему, пока-что выделена отдельная строка в коде без реализации методов, как "подозрительные запросы".

0

Надобность в "выкачивании html страниц" - отпала сама собой. Был подключён CLEditor, и он без всяких проблем передаёт "copy/past" данные любого типа, в том числе, как и планировалось - формулы с википедии. Можно даже сделать "ctr+a" любой интернет страницы, "ctr+c" и вставить в окно редактора "ctr+v". На выходе получается полная копия страницы, которую можно редактировать.

Интегрируя CLEditor, удалось реализовать два режима работы сервиса: "Html" и "Visual" editor. Причём в режиме "Visual", не нужно обладать знаниями Html. Достаточно использовать готовые функции CLEdito. И что самое главное: Генерируемый код Html при работе в режиме "Visual editor", получается (достаточно) чистым/валидным. Удалось написать методы форматирования и склеивания повторяющихся тэгов таким образом, что ничего лишнего в коде Html не остаётся.

Как уже было написано ранее, предусматривается поддержка javascript и jquery. Можно будет написать не просто статическую html страницу, а дополнить её скриптами, которые тут же можно будет протестировать (и всё это, возможно, будет без регистрации).

Работы ещё много (около 1-2 месяце) до первых запусков, и на данном этапе стоит вопрос безопасности выполнения скриптов. Необходимо предусмотреть случаи, когда пользователь по ошибке или целенаправленно блокирует внешние элементы управления и навигации сайта. Какие события (скрипты), могут быть в этом смысле опасны? Если скрипт будет выполняться в iframe, он будет работать только в рамках этого фрейма, или с него можно добраться и к странице на которой расположен iframe?

0

Непонятно что вы хотите.

Все вьюсинги основаны на одном теге - contenteditable="true" - только код там генерируется далеко не идеальный.

Тот же гугл док вообще на javascriopt свой текстовый процессор сделали. Но из за ограничений javascript там жуткие костыли.

0

Сообщение от developer123 Непонятно что вы хотите. Тот же гугл док вообще на javascriopt свой текстовый процессор сделали. Но из за ограничений javascript там жуткие костыли.

Код, который пишет пользователь, обрамляется тегом или перезаписывается в отдельный файл, который подгружается в iframe. Мой вопрос заключался в следующем: Если скрипт будет выполняться в рамках этого фрейма, он может добраться к странице на которой расположен этот iframe?

Сообщение от developer123 Все вьюсинги основаны на одном теге - contenteditable="true" - только код там генерируется далеко не идеальный.

Ну, это дело поправимо... Как оказалось, ckeditor-4 генерирует достаточно чистый код, и что самое главное - делает это быстро в реальном времени, снимая ненужную нагрузку на сервера. Поэтому, пожалуй будет интегрирован именно этот редактор для режима "Visual editor".

0

Сообщение от 1name он может добраться к странице на которой расположен этот iframe

никаким образом до iframe не добраться. Иначе зашли на какйо нибудь сайт а у вас украли всё, где вы залогинены были.

Сообщение от 1name Как оказалось, ckeditor-4 генерирует достаточно чистый код

ckeditor-4 не генерирует никакой код - код генерирует браузер. И раньше с множеством браузерных движков там генерировался целый зоопарк. Сейчас 3 осталось - хромиум, сафари, лиса. Edge - вроде как уже умер.

0

Сообщение от developer123 никаким образом до iframe не добраться.

Код выполняемый в iframe, может обратиться к родительскому окну. Единственный способ закрыть видимость - пропускать через ещё один iframe ("пустышку"). Даже если скрипт будет обращаться к DOM элементам родительского фрейма, он получит доступ к промежуточному окну, а дальше добраться не сможет. Это обусловлено уровнями языков программирования.

Сообщение от developer123 ckeditor-4 не генерирует никакой код - код генерирует браузер.

Речь идёт об html разметке при редактировании страницы/документа. Браузер отображает страницу в соответствии с html разметкой.

0

Сообщение от 1name Код выполняемый в iframe, может обратиться к родительскому окну

Что вы хотите сделать? Я так понял загружать в iframe сторонний сайт - и редактировать его через javasript. Так вот к стороннему сайту в iframe получить доступ нельзя. Даже если сделать скриншот страницы через javascript - iframe будет серой областью. Многие сайты запрещают загрузку себя в iframe.

Сообщение от 1name Речь идёт об html разметке при редактировании страницы/документа. Браузер отображает страницу в соответствии с html разметкой.

Всё что делают WUSIWYG редакторы это включают contenteditable="true" для редактируемого тега. Дальше внутри тега всю редактируемость - делает браузер.
Все кнопки редакторов это javascript ExecCommand команды. Которые говорят браузеру - мол включи например жирный для редактируемой области. А как уже выполнится команда - каждый браузер сам для себя решает. Потому как сделать тот же жирный - в современном веб можно 100500 разными способами.
В своё время столкнулся с этими редакторами - так каждый браузер перенос делал по свойму. Кто <br> вставлял. Кто div. Кто <p>. Короче геморрой сплошной был.Особенно если есть глобальные стили на тот же <p>.

0

Сообщение от developer123 Что вы хотите сделать? Я так понял загружать в iframe сторонний сайт - и редактировать его через javasript.

Нет. Тема этой ветки форума Онлайн сервис - "NotePad". Блокнот, который будет поддерживать html, javascript и jquery. Можно будет написать код и сразу же проверить его работу. Что касается сторонних ресурсов, то разумеется, всё на совести пользователя. Если например блокнотом будет пользоваться студент, который делает конспект с википедии, то он с лёгкостью сможет вставлять любые формулы, но доступа через сайт к самой википедии у него не будет.

Сообщение от developer123 Всё что делают WUSIWYG редакторы это включают contenteditable="true"

Включая contenteditable="true", браузер не знает как делать разметку. Скрипт делает эту работу и вставляет нужный тэг в нужном месте. Кроме того, в данном случае, возможно будет дополнительная проверка и редактирование html разметки на стороне сервера, как это делалось в случае с редактором CLEditor.

Добавлено через 19 минут
И если кто-то вдруг захочет зарабатывать на своих страницах NotePad, то он сможет вставить рекламный скрипт, например от гугла или яндекса, и получать прибыль за просмотры или клики в соответствии с их политикой. Но как это будет организовано - пока-что трудно сказать. Проектом предусматривается и своя система поиска...

0

Сообщение от 1name Блокнот, который будет поддерживать html, javascript и jquery. Можно будет написать код и сразу же проверить его работу.

https://jsfiddle.net/

0

Usaga, спасибо за ссылку, но это не то же самое. Ставится задача - максимально автоматизировать процесс. Пользователю не нужно знать html и css. Но если это продвинутый пользователь, то он сможет добавлять свои скрипты и редактировать html разметку.

0

Сообщение от 1name Пользователю не нужно знать html и css.

https://ru.wix.com/

0

Usaga, Wix - это конструктор сайтов, а у нас "обычный" тектовый редактор с расширенными функциями. Писать и оформлять страницы, можно как в обычном документе Word.

0

Сообщение от 1name а у нас "обычный" тектовый редактор с расширенными функциями.

https://code.visualstudio.com/

1