Репозиторий GitHub (в основной ветке используется метод неудаленного происхождения)

Обновлять

Есть гораздо более простой способ построить это. Вы используете содержимое popup ui в качестве iframe. Тогда вам не нужен URL-адрес удаленного источника. Якобы это безопасно. Я не уверен в этом, но когда я использовал URL-адрес удаленного источника, iframe обычно всегда был там. Но с хромом он, кажется, удаляется больше ... что привело меня к теневому корневому ТАК вопросу. Первоначально я думал, что это часть безопасности, но это больше предназначено для предотвращения коллизии стилей/очистки DOM (появляется меньше узлов). Также видимо некоторые сайты будут удалять фреймы.

Я не эксперт по безопасности расширений Chrome, поэтому я использую это на свой страх и риск.

Во всяком случае, вот расширение NANTA для Chrome, внедренное как iframe с использованием a chrome-extension://long-string iframe src.

Это использует локальную сеть Pi API/DB. Это не то, что я хотел построить. Это доказывает, что я могу построить то, что хочу, поэтому… Я опубликую обновление позже, когда оно будет делать то, что я хочу, возможно, через день или два.

Первоначальная публикация

Примечание: причина короткого кода в том, что я не понял, как безопасно отправить JWT из фонового скрипта в iframe удаленного источника. Если вы знаете, дайте мне знать. Я считаю, что это возможно, но мне нужно больше в этом разбираться.

Почему я сделал это?

Главное, чего я хотел, пока не столкнулся с проблемой сохраняемости JWT, — это что-то, что может всплывать на основе планировщика. Но также я хотел делать заметки о вещах, посмотреть, что я недавно изменил. У меня уже есть эта возможность с моими различными приложениями.

На самом деле, чтобы завершить этот проект вовремя, я вынул модуль создания заметок из кросс-платформенного приложения справа (сборка ReactJS в настольном приложении ElectronJS).

Изначально в моих проектах не было полного элемента, занимающего боковую или нижнюю панель.

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

Но потом я подумал о том, как пользовательский интерфейс скроет ситуацию. Лучше бы он всегда был там.

Технический макет

Возможно, я построил это неправильно, когда мне не нужно было делать то, что я делал. Но я торопился/хотел построить его за день или два.

Форма входа/короткий код хранится в popup ui. Он выполняет фактические вызовы API в background.js, а шорткод хранится в chrome.storage.

К сожалению, мои данные по большей части хранятся локально на моем сервере WiFi/Raspberry Pi 3 B+. Поэтому в какой-то момент мне придется перенести это на удаленную БД.

Уязвимости и недостатки

Это небезопасно в отношении возможности того, что кто-то закроет ваш iframe своим и перехватит клики/нажатия клавиш. Шорткод имеет длительный срок службы. Так что, если кто-то это получит, это будет отстой. В моей реализации у меня не было возможности копирования в буфер обмена на случай перехвата. Поэтому я вручную печатаю его. Это отстой, что каждый раз, когда вы переходите на новый веб-сайт или на веб-сайт, который не является SPA, вы должны войти в систему.

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