Typy node i konfiguracja połączeń

Każdy node ma inny poziom integracji i wymaga innej wiedzy. Wybierz typ pasujący do maszyny/urządzenia i postępuj według sekcji poniżej. Wszystkie node wystawiają trasy URI, ale różnią się transportem i tym, co potrafią.

Typ	Transport	Wymagana wiedza	Connector
🖥️ server	shell / SSH	SSH, instalacja zdalna	get-node + shell
💻 pc	aplikacja + shell	pulpit, terminal	get-node + kvm
🪟 rdp	pulpit zdalny (RDP)	RDP, login Windows	kvm / rdp
📱 smartphone	webpage → APK/Termux	instalacja apki, sieć LAN	android-node + adb
🌐 browser-debug	DevTools (CDP)	uruchomienie z debug portem	webnode
🧩 browser-chrome-plugin	Chrome Extension	Load unpacked, permissions	chrome-plugin
🧩 browser-firefox-plugin	Firefox Extension	Temporary Add-on, permissions	firefox-plugin
📄 webpage	HTML/JS na stronie	CDP, plugin albo page bridge	webnode / js-urirun-com
🔌 api	HTTP/REST/OpenAPI	URL API + auth	http-api / fetch / oauth
🧩 device	wiele protokołów	panel, RTSP, SSH, SMB/NAS	camera / rtsp / ssh / smb

🖥️ Server — shell / SSH

Headless maszyna (VPS, serwer). Sterowanie przez shell; węzeł urirun instalujesz zdalnie po SSH.

Potrzebujesz: dostęp SSH (user@host), prawa do instalacji.

ssh user@HOST "curl -fsSL https://get.ifuri.com/node.sh | bash -s -- --name HOST --port 8765 --background"

Następnie w dashboardzie zapisz node z URL http://HOST:8765. Test: http://HOST:8765/health.

💻 PC — aplikacja + shell

Maszyna z GUI (laptop, desktop). Uruchamiasz węzeł lokalnie lub przez aplikację ifURI; dochodzi sterowanie pulpitem (connector kvm: zrzut ekranu, klawiatura, mysz).

curl -fsSL https://get.ifuri.com/node.sh | bash -s -- --name pc --port 8765 --background

Zapisz node z URL http://IP-PC:8765.

🪟 RDP — pulpit zdalny

Windows/xrdp przez RDP (port 3389). Łączysz się z pulpitem i sterujesz nim; po stronie pulpitu działa węzeł urirun z connectorem KVM.

Potrzebujesz: host RDP, login, klient RDP (np. xfreerdp).

xfreerdp /v:HOST:3389 /u:USER /p:PASS /cert:ignore

Na pulpicie uruchom węzeł (jak PC) i zapisz node z URL http://HOST:8765.

📱 Smartphone — webpage node → mobile node

Dwa etapy integracji telefonu:

Webpage node (od razu): uruchom serwis android-node/webpage i otwórz jego URL w przeglądarce telefonu. Przeglądarka rejestruje się jako webpage node — sterowanie przez JS na otwartej stronie: nawigacja, eval, lista urządzeń, kamera i akcje strony. Nic nie instalujesz.
Mobile node (pełny): ze strony pobierasz APK lub uruchamiasz skrypt Termux. Telefon staje się pełnym węzłem (port 8765): pliki, system, wejście — przez connector adb.

urirun-android-node serve     # serwis dystrybucji (port 8195), QR + APK + bootstrap

W dashboardzie: Smartphone → Uruchom serwis android-node → Pokaż QR. Zeskanuj telefonem. Podłączone telefony pojawią się na liście „webpage node"; po instalacji APK zapisz je jako „mobile node".

🌐 Browser Debug — cała przeglądarka (CDP)

Sterowanie całą przeglądarką przez Chrome DevTools Protocol: wszystkie karty (otwórz/zamknij/nawiguj), status, zrzuty. Connector webnode, zakres browser. Stary typ browser jest aliasem do browser-debug.

google-chrome --remote-debugging-port=9222 --remote-debugging-address=127.0.0.1

urirun run "webnode://browser/tabs/query/list" --entry-points --execute --allow 'webnode://*'

Zapisz node z endpointem http://127.0.0.1:9222 i typem browser-debug.

🧩 Chrome Plugin — aktywna karta przez rozszerzenie

Tryb bez debug portu. Rozszerzenie działa w aktywnej karcie, obsługuje browser-plugin://chrome/... oraz kompatybilne browser://..., a inne URI przekazuje do skonfigurowanego node /run.

cd /home/tom/github/if-uri/chrome-plugin
make test
# chrome://extensions -> Developer mode -> Load unpacked -> ten folder

🧩 Firefox Plugin — aktywna karta przez rozszerzenie

Analogiczny tryb dla Firefox. Rozszerzenie obsługuje browser-plugin://firefox/... oraz kompatybilne browser://....

cd /home/tom/github/if-uri/firefox-plugin
make test
# about:debugging#/runtime/this-firefox -> Load Temporary Add-on

📄 Webpage — pojedyncza strona (HTML/JS)

Sterowanie konkretną stroną/kartą: nawigacja, eval JS, klik po selektorze, wpisywanie, zrzut, lista urządzeń strony, kamera, sensory, iframe/proxy. Może działać przez CDP page scope, plugin albo page bridge na porcie 8195. Stary typ web jest aliasem do webpage.

# lista kart i ich id:
urirun run "webnode://browser/tabs/query/list" --entry-points --execute --allow 'webnode://*'
# steruj jedną stroną:
WEBNODE_TARGET=<id> urirun run "webnode://page/command/navigate" \
  --entry-points --execute --allow 'webnode://*' --payload '{"url":"https://example.com"}'

Zapisz node z endpointem CDP i typem webpage, albo otwórz QR z serwisu 8195, żeby strona zarejestrowała się jako webpage node.

🔌 API — zewnętrzny endpoint z autoryzacją

API node służy do podpinania SaaS, lokalnych usług HTTP, REST/OpenAPI albo paneli sterowania. Sekret przekazany w formularzu jest zapisywany w keyring jako secretRef, a nie w pliku config.

urirun host add-node crm-api https://api.example.test/v1 \
  --kind api --api-id main --api-kind rest \
  --auth-type bearer --auth-token PASTE_ONCE

{
  "name": "crm-api",
  "url": "https://api.example.test/v1",
  "kind": "api",
  "apis": [
    {"id": "main", "kind": "rest", "url": "https://api.example.test/v1",
     "auth": {"type": "bearer", "token": "PASTE_ONCE"}}
  ]
}

Discovery pokazuje wtedy route'y konfiguracyjne, np. api://crm-api/main/command/request.

HTTP/REST/OpenAPI może być wykonane bezpośrednio przez hosta. Przykład payloadu:

{
  "uri": "api://crm-api/main/command/request",
  "mode": "execute",
  "payload": {"method": "GET", "path": "/accounts", "query": {"limit": 10}}
}

Wariant neutralny dla plannerów to configured://host/node-api/command/request z payloadem zawierającym node i apiId.

🧩 Device — kamera, RPi, NAS, nietypowe urządzenie

Device node ma wiele interfejsów API. Przykład: RPi jako kamera i NAS ma panel WWW, RTSP stream, SMB share i SSH shell. Jeden obiekt node grupuje je jako apis[].

urirun host add-node rpi-camera http://rpi.local \
  --kind device \
  --api '{"id":"panel","kind":"web","url":"http://rpi.local"}' \
  --api '{"id":"stream","kind":"rtsp","role":"camera","url":"rtsp://rpi.local/live"}' \
  --api '{"id":"share","kind":"smb","url":"smb://rpi.local/share"}' \
  --api '{"id":"ssh","kind":"ssh","url":"ssh://pi@rpi.local"}'

{
  "name": "rpi-camera",
  "url": "http://rpi.local",
  "kind": "device",
  "apis": [
    {"id": "panel", "kind": "web", "url": "http://rpi.local"},
    {"id": "stream", "kind": "rtsp", "role": "camera", "url": "rtsp://rpi.local/live"},
    {"id": "share", "kind": "smb", "url": "smb://rpi.local/share"},
    {"id": "ssh", "kind": "ssh", "url": "ssh://pi@rpi.local"}
  ]
}

Discovery tworzy syntetyczne route'y: device://, media://, camera://, ssh:// i fs://. Wykonanie tych route'ów powinny przejąć odpowiednie connectory. Host wykona tylko interfejsy HTTP-like; dla RTSP/SMB/SSH zwróci connector_required, zamiast udawać wykonanie.

⬅ Powrót do dashboardu