Logowanie do panelu
Dostęp jest ograniczony. Zaloguj się podpisem BLURT — jako administrator, reviewer lub właściciel przypisanej aplikacji Guest API.
Używaj wyłącznie Posting Key. Nigdy nie wpisuj tutaj Owner Key, Active Key ani hasła głównego. Klucz służy tylko do lokalnego podpisu jednorazowego komunikatu — nie jest przesyłany ani zapisywany w panelu.
Dokumentacja Guest API — jak podłączyć własny frontend? (bez logowania)
Blurt Account Creator
Przypomnienia po 7 dniach bez aktywności
Moduł sprawdza konta utworzone przez kreator i wysyła jednorazowe przypomnienie, jeśli nie wykryto pierwszej aktywności.
BLURT GUEST GATEWAY · API v1
Dokumentacja integracji Guest API
Instrukcja podłączenia komentarzy gościnnych do własnego frontendu BLURT. Od uzyskania dostępu po publikację, moderację i diagnostykę.
English documentation · Otwórz osobną stronę
1. Architektura i zakres usługi
Guest Gateway umożliwia niezalogowanym odwiedzającym komentowanie artykułów w blockchainie BLURT. Frontend przyjmuje pseudonim oraz treść, jego własny serwer wysyła zgłoszenie do Guest API, Gemini AI analizuje komentarz, a worker publikuje zatwierdzony wpis w blockchainie z konta technicznego.
- Odwiedzający → formularz na Twojej stronie.
- Backend frontendu → HTTPS + sekret API → Guest Gateway.
- Weryfikacja danych, limitów i moderacja Gemini; w razie potrzeby ręczne zatwierdzenie.
- Worker → podpis Posting Key konta gościa → RPC BLURT.
- Frontend → sprawdzenie statusu zgłoszenia po ID.
Każda aplikacja ma własny sekret i limity. Może publikować przez własne konto BLURT, np. @blurtpl-guest dla blurt.pl albo niezależne konto utworzone przez operatora innego frontendu. Pseudonim odwiedzającego pojawia się w treści, ale autorem blockchainowym pozostaje konto gościnne.
2. Zaproszenie, własne konto Guest i aplikacja
- Poproś administratora o dostęp. Dostęp do zarządzania Guest API nie jest publicznie otwarty. Administrator przypisuje Twój nick BLURT, rolę managera i ewentualne uprawnienie „Może dodać własne konto gościnne”.
- Zaloguj się do panelu blurtplugin.online kontem BLURT przez WhaleVault / Blurt Keychain lub opcję podpisu Posting Key (jeśli dostępna w Twojej wersji panelu).
- Przygotuj dedykowane konto gościnne BLURT. Konto musi już istnieć w blockchainie. W zakładce Konta gościnne dodaj je wraz z Posting Key (WIF), jeśli administrator zezwolił na samodzielne dodawanie. Jeżeli nie masz tego uprawnienia, administrator może przypisać Ci istniejące konto.
- Utwórz aplikację. W Kontach gościnnych podaj nazwę, wskaż przydzielone konto BLURT, ustaw limit godzinowy i dzienny, kliknij Wygeneruj sekret API.
- Skopiuj sekret natychmiast. Wartość w postaci
ggk_…jest pokazywana tylko raz; później można ją wymienić, ale nie ponownie odczytać. - Skonfiguruj backend swojego frontendu i przetestuj zgłoszenie oraz późniejszy odczyt jego statusu.
3. Co jest czym: nick, Posting Key i API key
| Element | Do czego służy | Gdzie przechowywać |
|---|---|---|
| Nick BLURT właściciela | Logowanie do panelu oraz przydział uprawnień | Publiczny identyfikator |
| Konto Guest BLURT | Formalny autor komentarzy w blockchainie | Konto publiczne, niezależne od aplikacji |
| Posting Key (WIF) | Podpisuje operacje komentarzy konta Guest | Tylko zabezpieczony panel Guest; nigdy kod JS, repozytorium ani wiadomości |
Guest API key ggk_… | Uwierzytelnia żądania konkretnej aplikacji | Wyłącznie serwer frontendu, poza publicznym katalogiem |
| Idempotency-Key | Identyfikator pojedynczej próby wysłania komentarza | Backend/sesja; zachować przy ponowieniu |
| visitor_id | Losowy identyfikator odwiedzającego do limitowania | Wygenerowany przez backend; bez danych osobowych |
Nie podawaj Active Key ani Owner Key. Złamanie Posting Key nadal umożliwia niechciane publikacje oraz generowanie kosztów; najlepiej używać dedykowanego konta o małym saldzie i posiadać możliwość wymiany klucza.
4. Endpoint i autoryzacja
Publiczny endpoint produkcyjny (wersja testowa usługi):
https://blurtplugin.online/bg-entry.php
Żądania wykonuj serwer → serwer przez HTTPS. Nagłówek Authorization musi mieć postać Bearer ggk_…. Nie wywołuj tego endpointu bezpośrednio z przeglądarki z prawdziwym sekretem.
Obsługiwane są POST (nowy komentarz) i GET ?id=… (odczyt statusu). Operacje administracyjne, nadawanie dostępu i dodawanie Posting Key odbywają się w panelu, a nie przez to publiczne API.
5. Wysłanie komentarza — POST
Przykładowe żądanie:
POST /bg-entry.php HTTP/1.1
Host: blurtplugin.online
Authorization: Bearer ggk_TUTAJ_SEKRET_APLIKACJI
Idempotency-Key: frontend:comment-1234567890
Content-Type: application/json
{
"visitor_id": "visitor_8nBL4m9X2qP7v6K1",
"nickname": "Anna",
"body": "Bardzo ciekawy artykuł!",
"parent_author": "autor",
"parent_permlink": "przykladowy-artykul"
}| Pole | Wymagania |
|---|---|
visitor_id | 16–128 znaków: litery, cyfry, _ i -; stabilny losowy ID odwiedzającego, nie IP/e-mail |
nickname | 2–50 znaków; bez znaczników </>, znaków kontrolnych i nowych linii |
body | 2–2500 znaków treści |
parent_author | Nick autora wpisu lub komentarza nadrzędnego w BLURT |
parent_permlink | Permlink wpisu/komentarza nadrzędnego; do 255 znaków, małe litery/cyfry/myślniki |
Nagłówek Idempotency-Key | 12–120 znaków z A-Z a-z 0-9 _ : -; ten sam klucz przy ponowieniu tego samego zgłoszenia |
Wymagany Content-Type: application/json. Żądanie ma limit ok. 16 KB. Konto autora Guest jest wybierane po kluczu aplikacji — nie wysyła się żadnego posting_key, account czy api_secret w JSON.
Odpowiedź 202 Accepted przy poprawnym przyjęciu (publikacja nie musi być natychmiastowa):
{
"ok": true,
"id": "9f3ca91dba802a531c48f77b892ac343",
"status": "moderating",
"account": "blurtpl-guest"
}id jest identyfikatorem zgłoszenia. Ponowienie żądania z tym samym Idempotency-Key w obrębie aplikacji zwraca ten sam komentarz i może zawierać duplicate: true. Nie generuj nowego klucza przy timeoutach lub ponowieniu tego samego formularza.
6. Sprawdzanie statusu, AI i moderacja
Do sprawdzenia statusu użyj tego samego klucza API:
GET /bg-entry.php?id=9f3ca91dba802a531c48f77b892ac343 HTTP/1.1
Host: blurtplugin.online
Authorization: Bearer ggk_TUTAJ_SEKRET_APLIKACJIPrzykładowa odpowiedź:
{
"ok": true,
"comment": {
"id": "9f3ca91dba802a531c48f77b892ac343",
"status": "published",
"review_reason": null,
"permlink": "re-9f3ca91dba802a531c48f77b",
"tx_id": "...",
"published_at": "2026-10-30 10:15:00",
"account": "blurtpl-guest"
}
}| Status | Znaczenie dla interfejsu |
|---|---|
moderating | Oczekuje na automatyczną analizę Gemini AI |
review | Wymaga zatwierdzenia przez moderatora |
rejected | Zgłoszenie odrzucone; nie publikować jako sukces |
queued | Zatwierdzone i oczekuje na proces publikacji |
publishing | Próba wysłania transakcji w toku |
broadcasted | Transakcja wysłana; potwierdzenie w toku |
uncertain | Niepewny wynik operacji; nie ponawiaj nowym ID — zgłoś administratorowi |
published | Publikacja potwierdzona w blockchainie |
failed | Nieudana operacja; potrzebna diagnostyka |
AI ma identyfikować spam i nadużycia, a nie oceniać poglądy. W przypadku niejednoznacznej treści lub niedostępnej usługi zgłoszenie może trafić do ręcznej kontroli. Frontend powinien pokazać użytkownikowi informację, że publikacja może potrwać — 202 nie oznacza published.
Dla odczytu statusu ID ma postać 32 małych znaków hex. Sekret innej aplikacji nie może odczytać cudzych zgłoszeń.
7. Limity, błędy HTTP i ponawianie
Gateway ogranicza zgłoszenia do 3 komentarzy na odwiedzającego na 24 godziny w ramach aplikacji, a także stosuje osobne limity godzinowe i dobowe skonfigurowane przez właściciela aplikacji. Wdrożony frontend powinien dodatkowo posiadać własny antyspam, CAPTCHA i ochronę CSRF.
| HTTP | Przykładowa przyczyna | Co zrobić |
|---|---|---|
400 | INVALID_JSON, INVALID_ID, IDEMPOTENCY_KEY_REQUIRED | Popraw format żądania/identyfikator |
401 | UNAUTHORIZED | Sprawdź Bearer API key, aktywność aplikacji, ewentualną rotację sekretu |
403 | APP_DISABLED (gdy wyłączono aplikację podczas żądania) | Skontaktuj się z właścicielem aplikacji |
404 | NOT_FOUND | Sprawdź ID i czy używasz właściwego klucza aplikacji |
405/415 | Niedozwolona metoda / wymagany JSON | Użyj GET albo POST z application/json |
413/422 | Za duże żądanie / niepoprawne pola, nickname lub długość treści | Popraw dane wejściowe |
429 | RATE_LIMITED | Nie ponawiaj agresywnie; pokaż limit użytkownikowi |
503 | SERVICE_UNAVAILABLE, ACCOUNT_UNAVAILABLE | Zastosuj opóźnioną próbę z tym samym Idempotency-Key |
426 | HTTPS_REQUIRED | Użyj HTTPS |
Odpowiedź błędu zwykle ma postać {"ok":false,"error":"KOD"}. Zależnie od konfiguracji reverse proxy odpowiedź 404 może być HTML — sprawdzaj HTTP status i nie zakładaj, że każdy błąd zwróci JSON.
8. Przykłady integracji — cURL, PHP i frontend
Test serwerowy (cURL)
curl --fail-with-body -X POST 'https://blurtplugin.online/bg-entry.php' \
-H "Authorization: Bearer $BLURT_GUEST_API_KEY" \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: frontend:comment-1234567890' \
--data '{
"visitor_id":"visitor_8nBL4m9X2qP7v6K1",
"nickname":"Anna",
"body":"Testowy komentarz.",
"parent_author":"autor",
"parent_permlink":"przykladowy-artykul"
}'Uwaga: powyższy POST tworzy rzeczywiste zgłoszenie. Używaj wyłącznie własnej aplikacji i testowego wpisu, a nie cudzych artykułów.
PHP — wywołanie z backendu
<?php
$apiKey = getenv('BLURT_GUEST_API_KEY'); // konfiguracja poza webrootem
if (!$apiKey) { throw new RuntimeException('API key missing'); }
// Zachowuj ten sam klucz dla ponowienia tej samej operacji.
$submissionKey = 'frontend:comment-1234567890';
$payload = [
'visitor_id' => 'visitor_8nBL4m9X2qP7v6K1',
'nickname' => 'Anna',
'body' => 'To jest komentarz testowy.',
'parent_author' => 'autor',
'parent_permlink' => 'przykladowy-artykul',
];
$ch = curl_init('https://blurtplugin.online/bg-entry.php');
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_HTTPHEADER => [
'Authorization: Bearer ' . $apiKey,
'Content-Type: application/json',
'Idempotency-Key: ' . $submissionKey,
],
CURLOPT_POSTFIELDS => json_encode($payload, JSON_THROW_ON_ERROR),
CURLOPT_RETURNTRANSFER => true,
CURLOPT_CONNECTTIMEOUT => 5,
CURLOPT_TIMEOUT => 15,
]);
$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
if ($response === false) { throw new RuntimeException('Guest API connection failed'); }
curl_close($ch);
$result = json_decode($response, true);
if ($httpCode !== 202 || !is_array($result) || empty($result['ok'])) {
throw new RuntimeException('Guest API rejected the submission: HTTP ' . $httpCode);
}
$commentId = $result['id']; // zachowaj do odpytywania statusuJavaScript po stronie przeglądarki
// Tylko Twoja własna trasa backendowa! Nigdy nie przekazuj tu ggk_...
const response = await fetch('/api/guest-comment', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
credentials: 'same-origin',
body: JSON.stringify({nickname, body, parent_author, parent_permlink})
});
const result = await response.json();
// Backend ustala visitor_id i Idempotency-Key, chroni trasę CSRF/rate-limit.
// Po otrzymaniu result.id odpytuj status przez własny backend.Backend frontendu powinien sam tworzyć losowy visitor_id (np. przechowywany w sesji), nadawać trwały identyfikator wysyłki, kontrolować uprawnienia/czas odpowiedzi i nie przekazywać surowego API key przeglądarce. Dla żądania GET statusu używa tych samych nagłówków Bearer po stronie serwera.
9. Bezpieczeństwo i niezależność frontendów
- API key przechowuj tylko na serwerze frontendu, np. w prywatnej konfiguracji; nie loguj pełnego tokenu.
- Posting Key podawaj wyłącznie w zaufanym panelu Guest; nie przesyłaj go przez formularz komentarza ani endpoint publikacji.
- Najlepiej użyj osobnego konta gościnnego BLURT z ograniczonym saldem, a nie konta osobistego.
- Przy ujawnieniu sekretu wygeneruj nowy API key w panelu; stary traci ważność. Sprawdź limity i historię zgłoszeń.
- Po stronie frontendu zapewnij HTTPS, walidację pól, CSRF, ochronę przed botami oraz własne ograniczenia częstotliwości.
- Nie twórz ponownie tego samego zgłoszenia nowym Idempotency-Key, jeśli wcześniejsza operacja ma niepewny wynik.
- Manager widzi tylko przypisane aplikacje. Nadanie dostępu do panelu nie oznacza dostępu do innych kont, sekretów ani ustawień finansowych.
Gateway jest usługą scentralizowaną, natomiast opublikowane komentarze pozostają na blockchainie BLURT i mogą być wyświetlane także przez inne frontendy.
10. Lista kontrolna przed uruchomieniem
- Masz zaproszenie managera i dostęp do zakładki Konta gościnne.
- Dedykowane konto BLURT istnieje i ma prawidłowy Posting Key, uprawnienia publikacji oraz niezbędne saldo BLURT.
- Wygenerowano sekret API, zapisano go poza katalogiem publicznym frontendu.
- Z frontendu działa testowy POST i odczyt statusu GET po ID.
- Wyświetlane są czytelne informacje: moderacja, kolejka, publikacja, odrzucenie.
- Powtórzenie tego samego POST z tym samym Idempotency-Key nie tworzy nowego komentarza.
- Sprawdzono limity 429, błędny klucz 401 i brak dostępu do cudzych zgłoszeń.
- Włączono walidację, ochronę CSRF i zabezpieczenia antyspamowe po stronie swojej aplikacji.
- Opublikowany komentarz można odnaleźć w blockchainie pod kontem Guest.
Instrukcja podłączenia Guest API (PL) · English documentation
Blurt Guest Gateway v0.3.6 — uprawnienia w jednym panelu
Każdy frontend otrzymuje niezależny sekret API, przypisane konto BLURT i limity. Klucze kont są szyfrowane i nigdy nie są ponownie wyświetlane. Publikacja rzeczywistych transakcji jest początkowo wyłączona.
Automatyczna moderacja AI — Gemini
Używa tych samych kluczy API i listy modeli co weryfikacja rejestracji kont. Brak drugiego klucza i osobnych kosztownych integracji. Niepewne komentarze pozostają do ręcznej kontroli.
Konto gościa BLURT
Dodaj własne konto gościnne BLURT
Dodaj nowe konto techniczne, które kontrolujesz. Potrzebny jest wyłącznie Posting Key. Nie zapisuję klucza Active, a Claim i Power Up pozostaną wyłączone.
Dodaj aplikację i wygeneruj sekret API
Powiązane aplikacje
Moderacja i kolejka
Oczekujące komentarze można ręcznie zatwierdzić lub odrzucić. Komentarze po zatwierdzeniu trafiają do kolejki.
Historia zdarzeń
Status modułu
Automatyczne uruchamianie
Panel zapisuje harmonogram do bazy. Na serwerze wystarczy jeden techniczny cron uruchamiany co 5 minut.
*/5 * * * * /usr/bin/flock -n /tmp/blurt_inactive_reminder.lock /usr/bin/php /www/wwwroot/blurtplugin.online/account/_private/inactive_reminder_scheduler.php >> /www/wwwroot/blurtplugin.online/account/_private/inactive_reminder_scheduler.log 2>&1
Ostatnie wyniki
Tryb testowy kreatora kont
To przełącza globalny BLURT_FAKE_MODE w pliku .env. Gdy tryb jest włączony, kreator powinien działać testowo i zwracać FAKE_TXID zamiast tworzyć prawdziwe konto na blockchainie.
creator.php dla formularza rejestracji. Po testach wyłącz go przed produkcją.
Testy Account Creator
Pełny test „na sucho”: sprawdza konfigurację, tabele, RPC Blurt, endpoint Node oraz zapis voucherów w transakcji cofanej rollbackiem. Nie tworzy prawdziwego konta.
Wysyłka nastąpi tylko po zaznaczeniu opcji i potwierdzeniu. Nie tworzy voucherów ani kont.
Test bez wysyłki
Sprawdza kandydatów i aktywność na Blurt, ale nie wysyła maili.
Blokady e-mail i domen tymczasowych
Zarządzaj istniejącymi plikami z listami blokad. Zmiany zapisują się bezpośrednio w account/_private i są używane przez kreator/rejestrację.
- Banowane adresy blokują konkretny adres, np.
bot@example.com. - Banowane domeny blokują domenę w głównym kreatorze, np.
clearbeam.pro. - Domeny tymczasowe są listą jednorazowych skrzynek używaną przez ochronę publicznej rejestracji/register voucherów.
Dodaj szybki wpis
Test adresu e-mail
Sprawdź, czy konkretny e-mail trafi w blokadę adresu, domeny albo listę tymczasowych skrzynek.
Bezpieczeństwo panelu
Podsumowanie zabezpieczeń aktywnego panelu administratora.
Sumaryczny risk score i tryb ręcznej weryfikacji
Ustaw progi działania publicznej rejestracji. IP2Proxy jest traktowany jako sygnał do risk score, a nie bezwarunkowa blokada — dzięki temu fałszywe trafienia zwykłych ISP nie odcinają użytkowników.
php account/_private/tools/ip2proxy_csv_to_cidr.php IP2PROXY-LITE-PX2.CSV account/_private/ip2proxy/ip2proxy_detected_ranges.txt
AI weryfikacja przed wysłaniem linku
Publiczny formularz najpierw prosi użytkownika o krótką odpowiedź w stylu czatu. Backend wysyła do Gemini odpowiedź, zachowanie w formularzu oraz risk score. Przy niskim ryzyku link register idzie automatycznie, a przy wyższym zgłoszenie trafia do reviewerów.
Klucze są zapisywane w account/_private/.env. Puste pole nie nadpisuje wcześniej zapisanego klucza.
Pełny test AI register flow
Dry-run sprawdza pełną ścieżkę decyzyjną po captcha/PoW: risk score, commercial/campaign score, IP reputation, behavior score i AI. Nie tworzy vouchera, nie wysyła maila i nie tworzy konta.
Wyjątek działa tylko w endpointzie admina ai-full-flow-test. Publiczny register_submit.php nie przyjmuje flagi testowej, więc użytkownik nie może obejść AI przez wklejenie tego tekstu.
Automatyczna weryfikacja e-mail
Gdy zgłoszenie trafia do ręcznej weryfikacji, system automatycznie wysyła wiadomość z kodem. Odpowiedzi można pobierać z IMAP i oglądać bezpośrednio w tabeli zgłoszeń.
Hasło IMAP jest zapisywane tylko wtedy, gdy wpiszesz je w pole. Puste pole nie nadpisuje wcześniej zapisanego hasła.
Odpowiedz na e-mail i podaj: nick Blurt, skąd znasz Blurt / po co chcesz konto, opcjonalny link do profilu oraz potwierdzenie, że konto nie będzie używane do spamu lub masowej reklamy.
Test IP / VPN / proxy
Sprawdza lokalne listy CIDR, lokalną bazę IP2Proxy BIN/CIDR i ewentualny zewnętrzny fallback, jeśli jest ustawiony.
Podgląd risk score
Test diagnostyczny bez tworzenia konta. Pokazuje orientacyjną decyzję: normalny flow, ręczna weryfikacja, blokada albo blacklista.
Zgłoszenia do ręcznej weryfikacji
Tutaj trafiają publiczne rejestracje z VPN/proxy/datacenter albo wysokim risk score. Po weryfikacji możesz oznaczyć zgłoszenie jako zaakceptowane, odrzucone, wysłany prywatny voucher albo blacklista.
- kliknij e-mail i poproś o krótką odpowiedź: skąd zna Blurt oraz jaki nick chce założyć,
- sprawdź opcjonalny profil/link: czy konto wygląda naturalnie i nie jest świeżą farmą reklamową,
- jeżeli wygląda wiarygodnie, wyślij prywatny voucher i oznacz jako voucher_sent; jeżeli nie, rejected albo blacklisted.
Zarządzanie dostępami
W jednym miejscu przydzielam dostęp do weryfikacji rejestracji i niezależnie do Guest API. Nadanie roli Guest nie daje uprawnień reviewera. Dostęp do aplikacji jest wyłącznie na zaproszenie administratora.
Ładowanie przydziałów Guest API…
Guest API — przydziel dostęp
Przydziel uprawnienia kontom BLURT. Weryfikacja tożsamości przez istniejące logowanie podpisem. Manager widzi i zarządza tylko wskazanymi aplikacjami i kontami. Bez dostępu do kluczy prywatnych, ustawień finansowych ani pozostałych zakładek panelu.
Przypisane konta gości BLURT
Przypisane aplikacje API
Zaufani reviewerzy społeczności
Administrator dodaje tutaj konta Blurt osób, które mogą weryfikować zgłoszenia. Reviewer loguje się podpisem WhaleVault i widzi sekcję weryfikacji bez pełnych uprawnień administracyjnych.
Powiadomienia blockchain dla reviewerów
Powiadomienia są kolejkowane dopiero wtedy, gdy zgłoszenie trafia do ręcznej weryfikacji i ma już odpowiedź użytkownika z czatu AI albo e-maila. Publiczny komunikat jest celowo ogólny: bez e-maila, IP, score, języka i treści odpowiedzi. Domyślny kanał może publikować komentarz z @wzmianką do reviewera, bo zwykły transfer z memo nie zawsze pojawia się w dzwoneczku każdego frontendu.
*/5 * * * * cd /www/wwwroot/blurtplugin.online && /usr/bin/flock -n /tmp/blurt_review_notifications.lock /usr/bin/node account/_private/review_notification_worker.js --limit=25 >> account/_private/logs/review_notification_worker.log 2>&1
Link dla społeczności
Link pomocniczy do panelu można podawać zaufanym osobom. Dostęp i tak wymaga dodania konta Blurt do listy reviewerów.
https://blurtplugin.online/account/review/
Testowy e-mail
Wysyła pojedynczy testowy mail z wybranym językiem.
Ręczne uruchomienie wysyłki
Ten przycisk służy tylko do małego testu z poziomu przeglądarki. Panel uruchamia wysyłkę bez oczekiwania między mailami i ogranicza partię, żeby żądanie HTTP nie kończyło się błędem 502. Produkcyjne przerwy antyspamowe obsługuje cron.