Sesje, hasła, przekaźnik i tryby serwera

Jedna zgodna sesja łączy źródła, doki, nakładki, alerty i strony API. Flagi routingu również muszą do siebie pasować.

Model połączenia

  1. Źródło przechwytuje czat lub zdarzenie i publikuje je w sesji Social Stream.
  2. Dok, nakładka Featured, Multi Alerts, Event Flow i inne strony dołączają do tej samej sesji.
  3. Jeśli ustawiono hasło, każda dołączająca strona musi używać tego samego hasła.
  4. Jeśli włączono routing przez serwer, aktywne strony muszą używać nowo wygenerowanych adresów URL z pasującymi parametrami routingu.
Source → same session ID + password + routing mode → Dock / overlay / API consumer

Identyfikator sesji i hasło

Otwórz Global settings and tools → Session Options , aby zobaczyć bieżący identyfikator sesji i ustawić opcjonalne hasło.

Opcje Session Options w Social Stream Ninja z polem identyfikatora sesji, opcjonalnym polem hasła i opcją Hide your links
W dokumentacji i na zrzutach ekranu używaj wartości zastępczej. Nigdy nie publikuj prawdziwego hasła sesji ani prywatnego wygenerowanego linku.
WartośćZasada
Identyfikator sesjiPozostaw go bez zmian, chyba że zamierzasz zastąpić wszystkie korzystające z niego adresy źródeł, doków, nakładek i integracji.
HasłoOpcjonalne, ale po ustawieniu musi być wszędzie takie samo. Po dodaniu lub zmianie skopiuj nowo wygenerowane linki.
Wygenerowany linkTraktuj cały link jako prywatny, jeśli zawiera hasło lub inne poufne parametry.

Najlepiej kopiuj wygenerowane adresy URL. Zawierają już bieżącą sesję, hasło, wersję strony i obsługiwane opcje routingu. Ręcznie zmieniane linki są częstą przyczyną pustych stron.

Włącz awaryjny serwer do odczytu i odpowiedzi

Użyj tej opcji, gdy dok lub połączony czat nawiązuje połączenie, ale wiadomości nie docierają, lub gdy odpowiedzi nie działają, ponieważ zwykła ścieżka peer-to-peer jest blokowana albo zawodna.

Dwa przełączniki awaryjnej ścieżki działają w parze: Wysyłaj wiadomości czatu do serwera API (dla zewnętrznych odbiorców) przenosi przychodzący czat na ścieżkę serwera, natomiast Dok wysyła polecenia do rozszerzenia przez serwer przenosi odpowiedzi i polecenia doku z powrotem.

Szybka metoda

  1. Otwórz lub przeładuj wygenerowany link doku.
  2. Wyślij sztuczną wiadomość testową z Social Stream Ninja.
  3. Jeśli pojawi się Włącz zapasowy serwer powiadomienie, wybierz je i potwierdź. Social Stream Ninja włącza jednocześnie serwerowe ścieżki przychodzącego czatu i poleceń odpowiedzi.
  4. Skopiuj nowo wygenerowane linki doku i nakładek. Ponownie otwórz zwykłe okna przeglądarki i zastąp wszystkie zapisane adresy URL źródeł przeglądarkowych OBS.

Metoda ręczna w aplikacji komputerowej

  1. Otwórz aplikację komputerową Social Stream. W panelu po prawej stronie „Źródła i ustawienia” rozwiń Ustawienia globalne i narzędzia.
  2. Rozwiń Mechanics - Connections & Integrations.
  3. Włącz Wysyłaj wiadomości czatu do serwera API (dla zewnętrznych odbiorców). To ścieżka odbierania i odczytu czatu.
  4. Włącz Dok wysyła polecenia do rozszerzenia przez serwer. To ścieżka odpowiedzi i sterowania.
  5. Skopiuj i ponownie otwórz nowo wygenerowane linki. Już otwarte strony i zapisane adresy OBS nie aktualizują się same.
Elementy sterowania Mechanics w Social Stream Ninja z opcjami Send chat messages to API server i Dock commands via server
Aby uruchomić standardową awaryjną obsługę odczytu i odpowiedzi, włącz opcję czatu przychodzącego oraz opcję poleceń doku. Pozostałe elementy sterowania serwerem są oddzielnymi funkcjami.

Nie włączaj wszystkich opcji serwera. Włącz zdalne sterowanie przez API, Włącz używanie i publikowanie przez serwer API w dokuoraz tymczasowa opcja dodatkowego dostarczania nie są wymagane przy standardowej awaryjnej obsłudze odczytu i odpowiedzi. Dodatkowe dostarczanie może powodować powielanie wiadomości.

Tryb domyślny, przekaźnika i serwera API

SterowanieCo zmieniaKiedy używać
Domyślne linki Standardowy transport peer/sesji Social Stream, bez dodanej flagi serwera. Większość konfiguracji na jednym komputerze i zwykłych konfiguracji OBS.
Włącz zdalne sterowanie rozszerzeniem przez API Włącza sterowanie rozszerzeniem przez HTTP/WebSocket i obsługę przychodzących webhooków. Zewnętrzne aplikacje, sterowanie przez Stream Deck/API lub obsługiwane przychodzące webhooki wpłat.
Włącz używanie i publikowanie przez serwer API w doku Dodaje parametr strony server routing tam, gdzie jest obsługiwany. Przepływ pracy Dock/Featured wymaga zdalnego sterowania przez serwer API zamiast standardowej ścieżki.
Wysyłaj wiadomości czatu do serwera API Kieruje przechwycony czat do ścieżki odbiornika serwera API i dodaje server2 do obsługiwanych generowanych łączy. Dok wymaga awaryjnego serwera dla przychodzącego czatu albo czat musi odbierać Python, Node lub inny zewnętrzny odbiornik WebSocket.
Wysyłaj też czat kierowany przez API zwykłą drogą Tymczasowe dodatkowe dostarczanie obiema ścieżkami. Tylko podczas świadomego przechodzenia między trybami; może powielać wiadomości.
Polecenia doku przez serwer Dodaje server3 tam, gdzie jest obsługiwany, aby polecenia doku wracały przez ścieżkę serwera. Połączenia peer są blokowane lub zawodne, a polecenia z doku do rozszerzenia wymagają serwera.
Globalne elementy sterowania Mechanics w Social Stream Ninja dotyczące zdalnego sterowania API, publikowania doku przez serwer API, zewnętrznych odbiorców czatu, dodatkowego dostarczania oraz poleceń doku przez serwer
Obecne elementy sterowania routingiem. Zmiana opcji generowanych linków nie zmienia już otwartej strony ani zapisanego źródła przeglądarkowego OBS.

Informacje localserver

Niektóre strony obsługują localserver i używają lokalnego punktu końcowego WebSocket pod adresem ws://127.0.0.1:3000. Dodaj localserverport=PORT , aby wybrać inny port z zakresu od 1024 do 65535. Nieprawidłowe lub pominięte wartości bezpiecznie powodują użycie portu 3000. Pamiętaj, że nowe instalacje aplikacji komputerowej Social Stream uruchamiają serwer lokalny na porcie 3003 i dodają localserverport=3003 w generowanych linkach — więc jeśli ręcznie tworzysz adres URL dla nowej instalacji, dodaj ten parametr samodzielnie. Dodawaj te parametry tylko wtedy, gdy serwer lokalny rzeczywiście działa, a konkretna strona je obsługuje.

Zrzuty ekranu i szczegółową konfigurację hostowanego WebSocket lub zaawansowanego serwera lokalnego znajdziesz w Tryby hostowanego WebSocket i lokalnego serwera.

Parametry routingu zależą od strony. server, server2, server3, localserver i localserverport nie działają jednakowo w każdej nakładce. Użyj wygenerowanego adresu URL dla konkretnej strony, zamiast kopiować flagi z innego narzędzia.

Po zmianie sesji lub przełącznika routingu

  1. Skopiuj nowo wygenerowany adres URL doku lub nakładki.
  2. Zamknij i ponownie otwórz aktywne strony przeglądarki korzystające ze starego adresu URL.
  3. Zastąp adres URL w zapisanych źródłach przeglądarkowych OBS i odśwież ich pamięć podręczną.
  4. Przeładuj lub ponownie aktywuj strony źródeł, jeśli zmienił się identyfikator sesji lub hasło.
  5. Wyślij jedną sztuczną wiadomość testową i potwierdź, że dotarła do doku, zanim przetestujesz docelową nakładkę.

Lista kontrolna pustego doku lub nakładki

  1. Porównaj pełną wartość session= w źródle, doku i nakładce.
  2. Sprawdź, czy w jednym z adresów URL nie brakuje bieżącego password=.
  3. Sprawdź, czy w starym adresie OBS nie brakuje aktualnych flag routingu przez serwer.
  4. Usuń ręcznie dodane flagi routingu i skopiuj świeżo wygenerowany adres URL, jeśli tryby są niejasne.
  5. Najpierw przetestuj dok. Jeśli dok odbiera wiadomości, następnie sprawdź filtry zdarzeń i opcje URL nakładki.
  6. Zobacz Rozwiązywanie problemów z OBS oraz Dokumentacja poleceń i API , aby przeprowadzić dokładniejsze sprawdzenie.