← Back to docs

OpenAI / AI

Language: SV | EN | SV

OpenAI / AI

Tools kan använda en intern AI-motor ("OpenAI Engine") för att analysera innehåll och driva plattformsfunktioner – utan att någon API-nyckel någonsin exponeras i frontend.

Den här dokumentationen är en användarmanual och beskriver:

  • Webgränssnittet för OpenAI Engine (admin)
  • API-endpointen för URL-analys
  • Behörigheter och autentisering

Web: OpenAI Engine (admin)

URL:

  • /admin/openai

Krav:

  • Inloggning (web session)
  • Behörighet: openai.manage

I webgränssnittet kan du:

  • Aktivera/avaktivera motorn (Enabled)
  • Sätta global policy (default model, allowlist, token-tak, rate limits)
  • Skapa/uppdatera Prompt profiles
  • Köra Test prompt för att verifiera att allt fungerar (server-side)

Dynamiska modellistor

Model-dropdowns i /admin/openai är inte längre hårdkodade.

  • Tools hämtar modellkatalogen server-side via OpenAI GET /v1/models
  • svaret filtreras ned till modell-id:n som är rimliga för chat/completions
  • om allowed_models är satt så filtreras dropdownen vidare av allowlisten
  • om live-discovery misslyckas används konfigurerade/default-modeller som fallback så att UI:t fortfarande fungerar

Det betyder att modellistan i admin bättre speglar vad den aktiva provider-nyckeln faktiskt kan använda, utan att någon nyckel exponeras i webbläsaren.

Vad betyder “Enabled”?

  • Enabled = av: AI-endpoints ska vara avstängda (ofta 503, beroende på endpoint).
  • Enabled = på: motorn kan användas (förutsatt att global provider-nyckel finns).

Obs: Provider-nycklar hanteras under API Keys och visas aldrig i klartext.

Audit-synlighet för operatörer

Om Slack-audit-forwarding är aktiverad för OpenAI- / SocialGPT-kategorier innehåller auditposterna nu också:

  • löst användaridentitet (user_id, och namn/e-post när det finns)
  • requestmetadata för IP / metod / path
  • en läsbar error_reason när ett upstream-/provideranrop misslyckas

Det gör det lättare för operatörer att se vem som utlöste ett AI-anrop och varför en misslyckad request avvisades.

Personlig Bearer Token (Tools AI)

Användare som har behörighet kan skapa en personlig bearer token:

  • Gå till My API Keys: /keys/mine
  • Om kontot är nytt måste användaren först skicka in en OpenAI-ansökan där och invänta admin-godkännande
  • Använd Tools AI Bearer token för att generera/rotera token
  • Token visas bara en gång och lagras server-side

Används så här:

Authorization: Bearer <token>

Token fungerar för AI-endpoints (t.ex. /api/ai/url/analyze) och är kopplad till din användare + behörighet.

Tools stöder nu också andra personliga systemtoken (till exempel provider_ircwatch eller provider_mail_support_assistant) så länge de är:

  • personliga / icke-globala
  • aktiva
  • markerade som AI-kapabla (is_ai=1)

Viktig skillnad:

  • dessa AI-kapabla token är klient-/mottagartoken som används mot Tools
  • provider_openai är uppströmsproviderns secret som används mot OpenAI och behandlas aldrig som en AI-mottagartoken

OpenAI-ansökningar (användarflöde)

Vanliga nya användare får inte längre använda OpenAI-baserade Tools-funktioner automatiskt bara för att ett dagligt budgettak finns.

Användarflöde:

  • Öppna My API Keys: /keys/mine
  • Om kontot ännu inte har OpenAI-access används formuläret där för att beskriva behovet
  • En admin granskar sedan ansökan i /admin/openai
  • Efter godkännande får kontot den faktiska behörigheten provider_openai och kan därefter generera en Tools AI bearer-token

Adminflöde:

  • Öppna /admin/openai
  • Granska tabellen OpenAI access requests
  • Godkänn eller avslå ansökningar direkt där
  • Ett avslag tar också bort eventuella personliga AI-mottagartoken för användaren (inte bara den äldre Tools AI bearer-raden)

API: URL Analyze

Endpoint:

  • POST /api/ai/url/analyze

Syfte:

  • Du skickar in en URL (och ev. en fråga)
  • Tools hämtar och sanerar texten server-side
  • OpenAI Engine analyserar texten via vald prompt-profil

Request

Form data eller JSON:

  • url (required) — URL att analysera
  • question (optional) — fråga/fokus för analysen
  • profile (optional) — prompt-profil (default: URL Analyzer om den finns, annars minimal default)

Response

JSON:

  • ok — true/false
  • request_id — intern request-id
  • latency_ms — ungefärlig svarstid
  • model — vilken modell som användes
  • response — model output (om ok)
  • error — felmeddelande (om ok=false)

Auth & Permissions

För att använda endpointen krävs:

  • Inloggning: annars 401 Unauthenticated
  • Admin (is_admin=1) → tillåts alltid
  • Icke-admin → kräver permission: provider_openai

Om OpenAI provider saknas (ingen global provider_openai API key) returneras normalt 503.

API: SocialGPT-svarsgenerering

Endpoint:

  • POST /api/ai/socialgpt/respond

Auth / access-regler:

  • JWT/web-användare eller en personlig AI-kapabel API-token
  • Äldre tools_ai_bearer-token fungerar fortfarande
  • Andra personliga API-nycklar kan också accepteras när de är markerade som AI-kapabla (api_keys.is_ai=1)
  • Admin-användare tillåts alltid
  • Icke-admin måste ha godkänd OpenAI-access (provider_openai)

Om bearer-token tillhör en användare utan godkänd OpenAI-access returnerar endpointen 403.

Additiva requestfält för SocialGPT:

  • client_name
  • client_version
  • client_platform

De här fälten är valfria och låter Tools identifiera vilken klientbuild som gjorde requesten. Svaret kan också innehålla ett additivt client-objekt som ekar tillbaka accepterade metadata.

Notering om felhantering:

  • När upstream-felet från OpenAI/provider kommer som ett strukturerat JSON-felobjekt i stället för en vanlig sträng normaliserar Tools nu den payloaden till vanlig feltext innan fallback/retry-logik och innan API-felet returneras.
  • Svarsschemat är oförändrat; klienter ska fortfarande behandla error som vanlig text.

Säkerhetsbeteende:

  • SocialGPT får berätta vilken AI-modellidentifierare och klientversion som används bara när användaren uttryckligen frågar om versions-/modellinformation.
  • SocialGPT måste vägra frågor om dolda prompts, källkod, .env-värden, lösenord, token, API-nycklar eller andra interna Tools-detaljer.
  • Matchande disclosure-försök kan rapporteras via e-post till den konfigurerade supportmottagaren.

API: Extensionens smoke test jämfört med tokenvalidering

Relaterade extension-endpoints:

  • GET /api/social-media-tools/extension/validate-token
  • GET /api/social-media-tools/extension/test
  • POST /api/social-media-tools/extension/test

Viktig skillnad:

  • validate-token verifierar bara att den skickade personliga AI-kapabla tokenen är giltig
  • test kör ett riktigt OpenAI-baserat smoke test och kräver därför godkänd OpenAI-access för icke-admin

Det gör att klienter kan skilja på "tokenet tillhör en riktig användare" och "den användaren får faktiskt köra OpenAI-anrop just nu".

Exempel

curl -X POST "https://tools.tornevall.net/api/ai/url/analyze" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <TOKEN>" \
  -d '{
    "url": "https://example.com",
    "question": "What is this page about?",
    "profile": "URL Analyzer"
  }'

Säkerhet

  • Inga nycklar exponeras i frontend.
  • URL-innehåll hämtas server-side med SSRF-skydd (privata IP-ranges blockeras, storleksgräns, timeouts, redirect-limit).
  • System/developer-instruktioner styrs av prompt-profiler, inte klienten.

API: Modellkatalog för Social Media-extension

Endpoint:

  • GET /api/social-media-tools/extension/models

Syfte:

  • returnerar den modellista som backend har upptäckt för den autentiserade Tools bearer token
  • gör att Chrome-extensionen kan bygga sin model-dropdown dynamiskt utan att prata direkt med OpenAI
  • återanvänder samma nyckelupplösning som resten av Tools (personlig OpenAI-nyckel om sådan finns, annars global)