> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/da/apps/custom-frontends.md).

# Brugerdefinerede frontends

Byg brugerdefinerede frontends til PowerShell Universal med React, Vue eller almindelig HTML og CSS, host dem derefter som publicerede mapper, og kald PSU API-slutpunkter.

## Brugerdefinerede frontends

Brugerdefinerede frontends er statiske webprogrammer, som De bygger med standardwebværktøjer og hoster med PowerShell Universal. Sådanne frontends er nyttige, når De vil bruge et JavaScript-framework, genbruge et eksisterende designsystem eller have fuld kontrol over oplevelsen på klientsiden.

PowerShell Universal behøver ikke at kompilere eller forstå Deres frontend-kildekode. Byg programmet med Deres foretrukne værktøjer, udgiv de genererede filer med en [udgivet mappe](/powershell-universal/da/platform/published-folders.md), og kald PowerShell Universal-API'er fra browseren.

Dette adskiller sig fra [statiske apps](/powershell-universal/da/apps/static-apps.md), som er bygget ud fra definitioner af PowerShell Universal-apps. Brugerdefinerede frontends bruger standard-HTML, CSS og JavaScript direkte.

## Brug af JavaScript-biblioteker

De kan bruge React, Vue, Angular, Svelte eller et hvilket som helst andet frontendbibliotek, der producerer statiske filer. PowerShell Universal serverer det kompilerede output, f.eks. en `dist`-, `build`- eller `wwwroot`-mappe.

Et typisk arbejdsflow er:

1. Opret frontendprojektet med frameworkets værktøjer.
2. Konfigurer buildet til at bruge den anmodningssti, De publicerer i PowerShell Universal.
3. Byg frontenden.
4. Publicer buildoutputtet som en publiceret mappe.

Når De hoster programmet under en sti som `/dashboard`, skal De konfigurere Deres bundlers basissti, så URL'er til JavaScript, CSS, billeder og skrifttyper opløses korrekt. Undgå `/portal`, fordi den er i konflikt med den indbyggede PowerShell Universal Portal.

For Vite-baserede programmer skal De angive indstillingen `base`.

```typescript
import { defineConfig } from 'vite'

export default defineConfig({
	base: '/dashboard/'
})
```

For Angular-programmer skal De angive base href ved bygning.

```powershell
ng build --base-href /dashboard/
```

Hvis programmet bruger routing på klientsiden, skal De konfigurere routeren til at bruge den publicerede anmodningssti. De kan også bruge hashbaseret routing, når De ikke ønsker, at serveren skal håndtere dybe links direkte.

Under udviklingen kan De køre frameworkets lokale udviklingsserver og kalde PowerShell Universal-API'er fra browseren. Hvis udviklingsserveren kører på en anden oprindelse end PowerShell Universal, konfigurer [CorsHosts](/powershell-universal/da/config/settings.md#corshosts), eller brug proxyfunktionen på frontend-udviklingsserveren. I produktion bør De foretrække relative URL'er, så kaldene går tilbage til den samme PowerShell Universal-instans, som leverede frontenden.

## Brug af CSS-frameworks

De kan bruge CSS-frameworks som Tailwind CSS, Bootstrap, Bulma eller frameworkspecifikke komponentbiblioteker. Medtag CSS på samme måde, som De ville gøre i et hvilket som helst statisk webprogram.

For de fleste programmer skal De installere CSS-frameworket via Deres pakkehåndtering og inkludere det i bundtet. Dette holder programmet selvstændigt og undgår afhængighed af eksterne CDN'er.

```powershell
npm install bootstrap
```

```javascript
import 'bootstrap/dist/css/bootstrap.min.css'
```

Den brugerdefinerede frontend er uafhængig af Admin Console og PowerShell Universal App Framework. Medtag alle typografier, skrifttyper og aktiver, som Deres program kræver, i buildoutputtet, eller servér dem fra en anden udgivet mappe.

## Kald af PSU-API'er

Brugerdefinerede frontends kan kalde både brugerdefinerede API-slutpunkter og administrations-API'en i PowerShell Universal.

Brug [brugerdefinerede API-slutpunkter](/powershell-universal/da/api/endpoints.md) til programspecifikke data og handlinger. Dette er den anbefalede fremgangsmåde for de fleste brugerdefinerede frontends, fordi De styrer ruten, inputvalideringen, svarformen, godkendelsen og rollekravene.

```powershell
New-PSUEndpoint -Url '/frontend/profile' -Method Get -Authentication -Endpoint {
		[PSCustomObject]@{
				UserName = $User.Identity.Name
				ServerTime = Get-Date
		}
}
```

Kald slutpunktet fra frontenden med `fetch`.

```javascript
const response = await fetch('/frontend/profile', {
	credentials: 'same-origin'
})

if (!response.ok) {
	throw new Error(`Request failed: ${response.status}`)
}

const profile = await response.json()
```

Ved JSON-anmodninger skal De sende headeren `Content-Type` og fortolke brødteksten i slutpunktet eller bruge en `param`-blok.

```powershell
New-PSUEndpoint -Url '/frontend/tickets' -Method Post -Authentication -Endpoint {
		$Ticket = ConvertFrom-Json $Body

		[PSCustomObject]@{
				Id = [guid]::NewGuid()
				Title = $Ticket.Title
				Created = Get-Date
		}
}
```

```javascript
await fetch('/frontend/tickets', {
	method: 'POST',
	credentials: 'same-origin',
	headers: {
		'Content-Type': 'application/json'
	},
	body: JSON.stringify({ title: 'Reset development environment' })
})
```

Administrations-API'en er tilgængelig under `/api/v1` og er beregnet til administrative handlinger. Brug den, når De bygger en administrativ frontend, og den bruger, der er logget på, har de nødvendige tilladelser. Til brugervendte arbejdsflows kan De overveje at eksponere et mindre brugerdefineret API-slutpunkt, der kun udfører den handling, som frontend'en har brug for.

Undgå at oprette brugerdefinerede slutpunkts-URL'er, der er i konflikt med interne URL'er til Administrations-API'en. Se [API endpoints](/powershell-universal/da/api/endpoints.md) og [API security](/powershell-universal/da/api/security.md) for at få flere oplysninger.

## Dokumentation af API'er med OpenAPI

[OpenAPI](/powershell-universal/da/api/openapi.md) dokumentation er nyttig, når De bygger brugerdefinerede frontends, fordi den beskriver API-kontrakten i et standardformat. Udviklere og AI-agenter kan bruge den til at forstå ruter, HTTP-metoder, parametre, godkendelseskrav, brødtekster i anmodninger, svarstrukturer og statuskoder, før de skriver frontendkode.

Opret en definition af slutpunktsdokumentation for den API, som Deres frontend bruger, og tildel relaterede slutpunkter til den.

```powershell
New-PSUEndpointDocumentation -Name 'Dashboard API' -Url '/dashboard-api' -Description 'APIs used by the custom dashboard.'

New-PSUEndpoint -Url '/frontend/tickets' -Method Get -Authentication -Documentation 'Dashboard API' -Endpoint {
    <#
    .SYNOPSIS
    Returns tickets displayed by the custom dashboard.

    .DESCRIPTION
    Returns the ticket list for the signed-in user. Operators receive assigned tickets and administrators receive all tickets.

    .OUTPUTS
    200:
      Description: Ticket list returned successfully.
    401:
      Description: The user is not authenticated.
    #>
    Get-Ticket | Select-Object Id, Title, Status, AssignedTo
}
```

OpenAPI-definitioner vises i det indbyggede Swagger-dashboard.

```http
http://localhost:5000/swagger/index.html
```

Brug kommentarbaseret hjælp i slutpunktsscripts til at dokumentere formålet med slutpunktet og dets parametre. For mere udførlige API-kontrakter skal De definere input- og outputtyper i definitionen af slutpunktets dokumentation og henvise til dem fra afsnittene `.INPUTS` og `.OUTPUTS`. Dette hjælper genererede klienter, testværktøjer og AI-agenter med at producere mere nøjagtige anmodninger.

Når De arbejder med en AI-agent, skal De angive OpenAPI-dokumentet eller Swagger-URL'en sammen med frontendkravene. Agenten kan bruge kontrakten til at generere typede API-klienter, hjælpere til anmodninger, formularer, validering, indlæsningstilstande og fejlhåndtering, der matcher de faktiske slutpunkter.

## Godkendelse

Publicerede mapper og API-slutpunkter kan uafhængigt kræve godkendelse og roller.

For at kræve, at brugere logger på, før frontendfilerne indlæses, skal De aktivere godkendelse på den publicerede mappe.

```powershell
New-PSUPublishedFolder -Name 'Dashboard' -Path 'C:\Apps\Dashboard\dist' -RequestPath '/dashboard' -DefaultDocument 'index.html' -Authentication -Role 'Operator'
```

For at beskytte data og handlinger skal De aktivere godkendelse på de API-slutpunkter, som frontend kalder.

```powershell
New-PSUEndpoint -Url '/frontend/admin-data' -Method Get -Authentication -Role 'Administrator' -Endpoint {
		Get-Date
}
```

Når frontenden leveres fra den samme PowerShell Universal-instans, fungerer cookie-godkendelse naturligt for brugere, der er logget på. Brug `credentials: 'same-origin'` sammen med `fetch`, så browserens legitimationsoplysninger medtages i anmodninger til godkendte slutpunkter.

App-tokens er nyttige til automatisering, eksterne integrationer og server-til-server-kald. Indlejr ikke app-tokens i browser-JavaScript, gem dem ikke i lokal lagring, og commit dem ikke sammen med frontend-kildekoden. Hvis en frontend skal udføre en handling, der kræver ophøjede tilladelser, opret et brugerdefineret API-slutpunkt med den relevante godkendelse, rolletjek og logik på serversiden.

Når De har brug for at kalde API'er med et app-token fra en betroet klient, skal De sende det i headeren `Authorization`.

````http
Authorization: ****** Universal also supports the `X-PSU-Authorization` header for scenarios where a reverse proxy needs to use the standard `Authorization` header for another purpose. See [App Tokens](/pages/ybubDKrhYyjSXn4SbSJH) for token management guidance.

## Hosting Static Assets

Use [published folders](/pages/7K71tKGBkFetUzIPmCdd) to host the compiled frontend files. The published folder maps a local file system path to a request path on the PowerShell Universal web server.

```powershell
New-PSUPublishedFolder -Name 'Dashboard' -Path 'C:\Apps\Dashboard\dist' -RequestPath '/dashboard' -DefaultDocument 'index.html'
````

Efter publicering kan brugere åbne frontenden på anmodningsstien.

```http
http://localhost:5000/dashboard
```

Parameteren `-DefaultDocument` serverer `index.html`, når brugeren anmoder om mappens rod. Dette er vigtigt for single-page-programmer. Til direkte links til indlejrede ruter på klientsiden skal De bruge hashbaseret routing eller sikre, at Deres hostingsti kan returnere frontend-indgangspunktet for disse ruter.

Publicer kun mappen med det kompilerede output. Publicer ikke kildemapper, der indeholder konfigurationsfiler, pakkemetadata, miljøfiler eller andet indhold, der ikke bør kunne downloades.

Statiske aktiver som billeder, skrifttyper og genererede JavaScript-chunks kan ligge i den samme mappe med buildoutput. Hvis De har brug for at dele aktiver på tværs af flere frontends eller apps, skal De publicere en separat mappe som `/assets` og referere til den fra frontenden.

## Opbygning med AI-agenter

AI-kodeagenter kan hjælpe med at opbygge en grundstruktur og iterere på en brugerdefineret frontend, især når De angiver PowerShell Universal-begrænsningerne på forhånd. Giv agenten anmodningsstien, frameworket, API-ruterne, godkendelsesforventningerne og den build-kommando, De planlægger at bruge.

PowerShell Universal-skills kan give AI-agenter genanvendelige PSU-specifikke instruktioner, scripts og referencer. Devolutions vedligeholder en samling af disse skills i lageret [powershell-universal-skills](https://github.com/Devolutions/powershell-universal-skills). Disse skills følger Agent Skills-formatet og kan hjælpe agenter med at udføre almindelige opgaver i PowerShell Universal med mere produktspecifik kontekst.

Lageret indeholder f.eks. en `install-sandbox-psu`-skill til installation af PowerShell Universal i et sandkassemiljø til test og udvikling. De kan installere samlingen med skills-CLI'en.

```powershell
npx skills add devolutions/powershell-universal-skills
```

Efter installationen kan understøttede kodeagenter bruge færdighederne automatisk, når en relevant PowerShell Universal-opgave registreres. Det kan være nyttigt, når De vil have en agent til at oprette en brugerdefineret frontend og også opsætte en lokal PSU-instans, konfigurere understøttende ressourcer eller validere frontend'en mod et sandkassemiljø.

For eksempel:

```
Build a React and Vite frontend for PowerShell Universal. It will be hosted at /dashboard from a published folder. Configure the Vite base path for /dashboard/. Use relative fetch calls to /frontend/profile and /frontend/tickets with same-origin credentials. Do not store app tokens in the browser. Include loading, error, and empty states.
```

Nyttige detaljer, der skal medtages i prompts, er:

* Det framework og den pakkehåndtering, der skal bruges.
* Anmodningsstien for den publicerede mappe.
* De forventede URL'er til API-slutpunkter og JSON-strukturer.
* OpenAPI-dokumentet eller Swagger-URL'en til frontend-API'erne.
* Om frontenden er offentlig eller kræver godkendelse.
* Rollebestemt funktionsmåde, som brugergrænsefladen skal vise eller skjule.
* Den buildoutputmappe, der vil blive publiceret.
* Eventuelle installerede PowerShell Universal-agentfærdigheder, som agenten skal bruge.

Når agenten har oprettet frontend'en, skal De gennemgå buildkonfigurationen, køre produktionsbuildet og kun publicere den genererede outputmappe med `New-PSUPublishedFolder` eller **Build > Published Folders**.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.devolutions.net/powershell-universal/da/apps/custom-frontends.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.