Demoåtkomst till WordPress adminpanel är en standardmetod för att sälja plugins och teman. En potentiell köpare besöker sajten, ser inloggning och lösenord, kopierar dem, går till wp-login.php, klistrar in... För många steg. Varje extra klick filtrerar bort en del av publiken.

Automatisk inloggning via länk löser problemet radikalt: en länk, och användaren är redan i adminpanelen, under rätt konto. Inget kopiera-klistra, ingen förvirring med inloggningsuppgifter.

Här är ett färdigt PHP-snippet som lägger till denna mekanism på valfri WordPress-sajt. Tjugo rader kod, anpassning tar 2 minuter. Snippet:et är inte beroende av temat, drar inte in externa beroenden och aktiveras som ett vanligt plugin.

💡 Snabb översikt:

• Du lägger till en URL-parameter till inloggningsadressen (till exempel ?autologin=demo), och wp_signon() auktoriserar användaren under det angivna kontot med en omdirigering till önskad sektion
• Snippet:et är utformat som ett separat WordPress-plugin: aktivera det så fungerar det direkt, avaktivera det så är det inaktiverat, temat är inte bundet till det
• Grundversionen hanterar ett konto, den utökade versionen stöder valfritt antal konton med olika roller och målpunkter
• Anpassning för ditt projekt: ändra tre värden i koden (användarnamn, lösenord, URL-nyckel), ladda upp pluginet till sajten och få inloggning via länk

Hur auto-inloggning fungerar: wp_signon-mekaniken

Kärnan i hela strukturen är funktionen wp_signon(). Den tar emot inloggningsuppgifter: användarnamn, lösenord och "kom ihåg"-flagga, och auktoriserar sedan användaren precis som standardformuläret på wp-login.php. Skillnaden är att anropet sker programmatiskt, utan mänsklig medverkan. Användaren följer helt enkelt länken och hamnar inuti.

Hooken after_setup_theme körs innan headers skickas, vilket är kritiskt eftersom wp_signon() sätter en auth-cookie, och cookies måste skickas innan någon utdata till webbläsaren. Om du hänger anropet på init eller en senare hook kan inloggningen misslyckas. Det är just därför snippet:et är utformat som ett separat plugin istället för att infogas i temats functions.php: pluginet laddas i de mycket tidiga stadierna av WordPress livscykel, vilket garanterar att hooken körs i tid.

Här är det minimala fungerande pluginet:

1
<?php
2
/*
3
Plugin Name: Auto Login
4
Plugin URI:  https://techblog.sdstudio.top/
5
Version:     1.0.0
6
Author:      Harri Bell-Thomas
7
*/
8
 
9
function autologin() {
10
    if ( $_GET['autologin'] !== 'demo' ) {
11
        return;
12
    }
13
 
14
    $creds = array(
15
        'user_login'    => 'demo',
16
        'user_password' => 'demo',
17
        'remember'      => true,
18
    );
19
 
20
    $user = wp_signon( $creds, false );
21
 
22
    if ( ! is_wp_error( $user ) ) {
23
        wp_redirect( admin_url() );
24
        exit;
25
    }
26
}
27
add_action( 'after_setup_theme', 'autologin' );

Låt oss bryta ner det rad för rad. Villkoret $_GET['autologin'] === 'demo' kontrollerar att den nödvändiga parametern skickas i URL:en: wp-login.php?autologin=demo. Arrayen $creds innehåller användarnamn, lösenord och "kom ihåg"-flagga. wp_signon() med parametern false betyder: använd inte säker cookie (lämpligt för lokal utveckling och staging-sajter utan HTTPS). Vid framgång omdirigerar wp_redirect( admin_url() ) användaren till adminpanelen. Vid fel (felaktigt lösenord, obefintlig användare) visar WordPress standardinloggningsformuläret utan att avslöja att ett auto-inloggningsförsök gjordes.

Anpassning för ditt projekt

För att anpassa snippet:et räcker det att ändra tre värden: URL-parametern, användarnamn och lösenord. I nästa block är de flyttade till början av funktionen för bekvämlighets skull:

1
function autologin() {
2
    $param  = 'autologin';
3
    $user   = 'dummy';
4
    $pass   = 'pa55word';
5
 
6
    if ( $_GET[ $param ] !== $user ) {
7
        return;
8
    }
9
 
10
    $creds = array(
11
        'user_login'    => $user,
12
        'user_password' => $pass,
13
        'remember'      => true,
14
    );
15
 
16
    $login = wp_signon( $creds, false );
17
 
18
    if ( ! is_wp_error( $login ) ) {
19
        wp_redirect( admin_url() );
20
        exit;
21
    }
22
}

Tre regler vid anpassning som kommer att spara timmar av felsökning.

Första: värdet på parametern $user får inte matcha reserverade WordPress-nycklar. Fyra nycklar är reserverade: loggedout för utloggning, action för lösenordsåterställning, redirect_to för omdirigeringar efter inloggning och wp_lang för att byta språk. Om du använder något av dessa ord kommer auto-inloggning antingen inte att fungera eller förstöra standardbeteendet i kärnan.

Andra: lösenordet lagras som klartext i plugin-koden, så använd aldrig detta snippet för administratörs- eller redaktörskonton på en live-sajt. En demoanvändare med rollen Prenumerant eller, högst, Redaktör, är acceptabelt. En administratör med auto-inloggning via länk är ett hål som en angripare hittar på en sekund.

Tredje: om sajten körs på HTTPS, ersätt false med true i det andra argumentet till wp_signon(). Detta aktiverar säker cookie och förhindrar avlyssning av auth-token under nätverksöverföring.

Inloggningsadressen kommer att se ut så här: https://your-site.com/wp-login.php?autologin=dummy. När man följer den hamnar användaren omedelbart i adminpanelen. Inga mellanliggande skärmar, inget kopiera-klistra av inloggningsuppgifter.

Flera konton: en länk, olika konton

Vad händer om demosajten visar produkten från olika roller? Administratören ser inställningspanelen, redaktören ser publiceringsgränssnittet, prenumeranten ser mitt konto. För detta scenario utökar vi snippet:et för att stödja flera konton:

1
<?php
2
/*
3
Plugin Name: Auto Login
4
Plugin URI:  https://techblog.sdstudio.top/
5
Description: Automatic login for demo accounts. Configure accounts in the array below.
6
Version:     1.0.0
7
Author:      Harri Bell-Thomas
8
*/
9
 
10
$autologin_param = 'autologin';
11
 
12
$autologin_accounts = array(
13
    array(
14
        'user'     => 'demo',
15
        'pass'     => 'demo',
16
        'location' => 'wp-admin',
17
    ),
18
    array(
19
        'user'     => 'editor_demo',
20
        'pass'     => 'demo',
21
        'location' => 'wp-admin/post-new.php',
22
    ),
23
);
24
 
25
function autologin() {
26
    global $autologin_param, $autologin_accounts;
27
 
28
    foreach ( $autologin_accounts as $account ) {
29
        if ( $_GET[ $autologin_param ] === $account['user'] ) {
30
            $creds = array(
31
                'user_login'    => $account['user'],
32
                'user_password' => $account['pass'],
33
                'remember'      => true,
34
            );
35
 
36
            $user = wp_signon( $creds, false );
37
 
38
            if ( ! is_wp_error( $user ) ) {
39
                wp_redirect( admin_url( $account['location'] ) );
40
                exit;
41
            }
42
        }
43
    }
44
}
45
add_action( 'after_setup_theme', 'autologin' );

Mekaniken är densamma, men arrayen $autologin_accounts lagrar inloggningsuppgifterna för alla demoanvändare, och foreach itererar genom dem och letar efter en matchning med URL-parameterns värde. Att lägga till ett nytt konto handlar om att kopiera array-blocket med nya värden för user, pass och location.

Parametern location accepterar vilken relativ sökväg som helst inuti /wp-admin/: till exempel options-general.php för inställningssidan, edit.php för inläggslistan eller post-new.php för att skapa ett nytt inlägg. Du kan också ange en fullständig URL för omdirigering till frontend, men ersätt då admin_url( $account['location'] ) med $account['location'] i koden.

Ingångspunkten är densamma: https://your-site.com/wp-login.php?autologin=editor_demo, och användaren landar på sidan för att skapa inlägg istället för admin-roten. För demo-sajtägaren innebär detta full kontroll över första intrycket: varje typ av användare ser exakt den del av produkten som är relevant för deras intressen.

⁉️🤔 Vanliga frågor

Är det säkert att lagra lösenord i plugin-kod?

Nej, det är inte säkert. Snippet:et designades för demosajter där konton avsiktligt är offentliga och inte har verkliga privilegier. På en produktionssajt med riktiga användare är detta tillvägagångssätt oacceptabelt: lösenordet i klartext kan läcka vid varje kodgranskning. För produktionsscenarier, överväg en engångs-token-mekanism eller SSO via REST API med nonce-verifiering.

Varför inte wp_login-actionen, utan direkt wp_signon?

Hooken wp_login körs efter en lyckad inloggning, den utför inte själva auktoriseringen. wp_signon() är funktionen som autentiserar användaren: den kontrollerar lösenordet via wp_authenticate(), sätter cookien och utlöser wp_login som en konsekvens. Om du behöver programmatiskt auktorisera en användare är wp_signon ditt verktyg.

Kan jag infoga snippet:et i functions.php istället för ett separat plugin?

Ja, koden fungerar i temats functions.php också. Men ett plugin är bekvämare: auto-inloggning är inte bundet till temat och går inte sönder vid temabyten. Dessutom kan pluginet avaktiveras med ett klick utan att redigera filer på servern.

Vad gör man om användaren efter inloggning inte är auktoriserad i is_user_logged_in?

Detta är en känd egenhet hos wp_signon() när den anropas före init-hooken: cookien är satt, men den globala $current_user är inte uppdaterad än. Lösningen är att tvinga fram ett anrop till wp_set_current_user( $user->ID ) omedelbart efter en lyckad wp_signon(). I vårt snippet är detta inte kritiskt eftersom en omdirigering följer omedelbart, men i scenarier utan omdirigering är raden obligatorisk.

Fungerar snippet:et på multisite?

Ja, men med en brasklapp. wp_signon() auktoriserar användaren inom den aktuella sajten i nätverket. Om kontot bara finns på en av undersajterna fungerar inte auto-inloggning på de andra. För korsautentisering genom hela nätverket, använd en kombination av wp_signon() och wp_set_auth_cookie() med tvingad cookie-installation för huvuddomänen.

Auto-inloggnings-snippet: vad är slutresultatet

Femton rader PHP eliminerar den huvudsakliga friktionen i demo-sajtens tratt: att kopiera användarnamn och lösenord. En länk, och besökaren är inne i produkten, med den roll och i den sektion du valde.

Grundversionen täcker scenariot "en demoanvändare", den utökade täcker valfritt antal roller med olika omdirigeringspunkter. Båda är oberoende av temat, kräver inga tredjeparts-plugins och aktiveras på en minut.

Huvudregeln för säkerhet är att inte höja privilegier. En demoanvändare med rollen Prenumerant eller, högst, Redaktör är acceptabelt. En administratör med auto-inloggning via länk är ett hål som en angripare hittar på en sekund.

Om demoåtkomst är en försäljningskanal för dig slutar automatisk inloggning att vara ett "trevligt tillägg" och blir ett obligatoriskt konverteringselement. En länk istället för användarnamn och lösenord är skillnaden mellan "jag testar senare" och "jag testar nu".