Skip to content

Kõik WordPressist, veebiarendusest — ja mitte ainult

🔒 Kuidas piirata juurdepääsu WordPressi kohandatud postitüüpidele: samm-sammuline juhend

🔒 Kuidas piirata juurdepääsu WordPressi kohandatud postitüüpidele: samm-sammuline juhend

Kujutage ette: käivitasite ettevõtte portaali WordPressis, lõite kohandatud postitüübi nimega „Seadmed" ja täitsite selle sisedokumentatsiooniga. Nädal hiljem avastate, et kõik need lehed on otsingumootorite poolt indekseeritud ja kõigile möödujatele nähtavad. Juurdepääs peaks olema piiratud volitatud töötajatega, kuid teie oma on pärani lahti.

WordPressi sisseehitatud tööriistad ei võimalda valikuliselt piirata konkreetset kohandatud postitüüpi registreerimata kasutajate eest. Rollid ja õigused on olemas, kuid sidumine „külalised ei näe CPT-d X" ei ole vaikimisi saadaval. Lahendus koosneb kolmest komponendist: CPT registreerimine, rolli seadistamine ja lugemispiirangu plugin. Neljas (valikuline) komponent on sotsiaalne sisselogimine, et töötajad ei peaks iga kord parooli sisestama.

Lähivõte programmeerimiskoodiga ekraanist, veebiarendus

Allpool on iga komponendi samm-sammuline jaotus koos konkreetsete pluginatega ja seadistustega. Kõik tööriistad on tasuta, saadaval ametlikus WordPress.org kataloogis ega vaja programmeerimist, kuigi artikli lõpus on käsitletud ka puhtalt koodipõhist lähenemist neile, kes soovivad pluginaid vältida.

💡 Kiirülevaade:

  • Registreerige kohandatud postitüüp Custom Post Type UI abil, ilma ühtegi koodirida kirjutamata
  • Looge PublishPress Capabilities'is kohandatud roll ja määrake see töötajatele
  • Piirake CPT-le juurdepääsu külalistele, kasutades WP Access Areas pluginat: volitamata külastajad suunatakse ümber sisselogimislehele
  • Valikuliselt lubage sotsiaalne sisselogimine Super Socializeri kaudu paroolivabaks Google'i kontoga sisselogimiseks

1. Samm: kohandatud postitüübi registreerimine

Esimene ja lihtsaim etapp on CPT enda loomine. Selleks ei pea te functions.php faili puutuma: Custom Post Type UI plugin WordPress.org-is pakub graafilist liidest mis tahes postitüüpide ja taksonoomiate registreerimiseks.

Paigaldamine on standardne: „Plugins → Add New", otsige nime järgi, aktiveerige. Pärast aktiveerimist ilmub külgribale uus menüüpunkt: „CPT UI → Add/Edit Post Types". Täitke väljad: nimetunnus (näiteks equipment), mitmuse ja ainsuse nimed, sildid ja klõpsake „Add Post Type".

Custom Post Type UI plugina liides kohandatud postitüübi loomiseks

Plugin kutsub automaatselt välja register_post_type() koos õigete parameetritega. Käsitsi koodi pole vaja: saate täielikult funktsionaalse postitüübi koos redaktori toe, arhiivide ja REST API-ga. Kui teil on hiljem vaja registreerimine functions.php faili üle viia, kuvab CPT UI vahekaardil „Tools" genereeritud PHP koodi.

Registreerimise ajal pöörake tähelepanu kahele kriitilisele turvalisusega seotud valikule. CPT UI seadete plokis on lipp „Publicly Queryable", mis määrab, kas postitusi saab avada otseviidete kaudu. See on vaikimisi tõene (true) ja isegi pärast lugemise piiramist pluginaga peaksite selle lubatuks jätma; vastasel juhul tagastab WordPress sisselogimislehele ümbersuunamise asemel 404 vea ja kasutajad ei saa aru, mis juhtus. Teine parameeter, „Has Archive", lubab arhiivilehe, kus loetletakse kõik CPT postitused. Kui te arhiivi ei vaja, keelake see, et otsingumootorid ei indekseeriks teeninduslehte piiratud dokumentide eelvaadetega.

2. Samm: kohandatud rolli loomine

Lihtsalt CPT-le juurdepääsu piiramine külalistest ei ole piisav: teil on vaja rolli, millel see juurdepääs on. Vaikimisi pakub WordPress kindlat komplekti: administraator, toimetaja, autor, kaastööline, tellija. Loome uue rolli, kasutades PublishPress Capabilities pistikprogrammi (endise nimega Capability Manager Enhanced, sama slug, sama funktsionaalsus, lihtsalt uue kaubamärgi all).

Rollihalduse leht PublishPress Capabilities pluginas

Pärast aktiveerimist minge jaotisesse „Capabilities → Roles". Ekraani paremal küljel leiate ploki „Create New Role":

Vorm uue kohandatud rolli loomiseks PublishPress Capabilities pluginas

Sisestage nimi (näiteks „Equipment Reader"), valige kloonimiseks baasroll (parim on Subscriber, minimaalsete õigustega) ja klõpsake „Create". Uus roll on nüüd olemas ja saate sellele õigusi lisada. CPT lugemiseks piisab standardsest kombinatsioonist read + read_equipment (CPT UI poolt registreeritud õigus).

Määrake loodud roll töötajatele, kes vajavad juurdepääsu piiratud sisule. Pärast seda saate pistikprogrammi deaktiveerida: rollid ja õigused jäävad WordPressi andmebaasi ega sõltu PublishPress Capabilities'i aktiivsest olekust.

Rollide ligipääsuõiguste seadistuspaneel PublishPress Capabilities pluginas

Samm 3: CPT lugemisõiguse piiramine

See on võtmetähtsusega samm. WP Access Areas pistikprogramm võimaldab täpselt määratleda, kes saab iga tüüpi postitusi lugeda, muuta ja kommenteerida, kuni üksikute lehtedeni välja. Sellel on tagasihoidlikult 400 aktiivset paigaldust ja see pole mõnda aega suuremaid uuendusi saanud, kuid ülesande „külalistelt CPT piiramine" jaoks töötab see prognoositavalt ja konfliktideta.

WP Access Areas plugina leht WordPressi kataloogis

Pärast paigaldamist minge jaotisesse „Settings → Access Areas". Jaotises „Default Behaviour" valige:

„If not logged in, redirect to login. Otherwise redirect to the fallback page."

See säte saadab volitamata kasutajad lehele wp-login.php, kui nad üritavad avada mõnda kaitstud CPT lehte.

WP Access Areas plugina peamised käitumisseaded

Järgmisena on seal tabel kõigi registreeritud postitüüpidega. Oma CPT jaoks valige veerus „Reading" rippmenüüst „Logged in Users". See ongi kõik: alates sellest hetkest suunatakse iga külaline, kes järgib otselinki CPT lehele, autoriseerimisvormile.

Oluline märkus: tabeli kaudu tehtud sätted kehtivad ainult uutele postitustele. Juba loodud lehtede jaoks peate õigused käsitsi määrama redaktori külgribal, kus kuvatakse plokk „Access Areas". Pärast seadistamist kontrollige tulemust kindlasti brauseri inkognito režiimis: kaitstud CPT lehe otselingi avamine peaks teile näitama wp-login.php, mitte sisu.

Lugemisõiguste seadete plokk WordPressi postituse redaktoris

Alternatiivid WP Access Areasile, kui vajad aktiivsemalt hooldatavat lahendust: PublishPress Permissions (tasuta versioon katab CPT-d ja rollid) või ContentGate (kerge plugin, mille reeglid põhinevad sisselogimise staatusel ja rollidel).

Samm 4: sotsiaalne sisselogimine (valikuline)

Pidev kasutajanime ja parooli sisestamine ettevõtte portaalis tekitab asjatut hõõrdumist. Loogiline lahendus: ühe klõpsuga sisselogimine Google'i konto kaudu. Super Socializer plugin haldab seda ülesannet enam kui 20 000 aktiivse paigaldusega ning toetab Google'it, Facebooki, X-i (Twitterit) ja tosinat muud teenusepakkujat.

Super Socializer plugina sotsiaalse sisselogimise funktsioonide ülevaade

Pärast aktiveerimist mine jaotisse „Super Socializer → Social Login":

Sotsiaalse sisselogimise seadete sakk Super Socializer pluginas

Põhiseaded: märgi linnuke valiku „Disable user registration via social networks" ette. See on oluline, et sotsiaalvõrgustike kaudu saaksid sisse logida ainult olemasolevad kontod, mitte ei loodaks uusi. Seejärel vali teenusepakkuja (Google) ning sisesta Client ID ja Client Secret. Kust neid saada:

  • Ava Google Cloud Console, loo projekt (või vali olemasolev)
  • Jaotises „APIs & Services → Credentials" klõpsa „Create Credentials → OAuth client ID"
  • Rakenduse tüüp on Web application; väljale Authorized redirect URIs kleebi tagasikutsumise URL Super Socializeri seadetest
  • Salvesta, et saada oma Client ID ja Client Secret
OAuth-kliendi loomine Google Cloudi konsoolis sotsiaalseks autoriseerimiseks

Kopeeri võtmed plugina väljadele:

Kliendi ID ja kliendi salajase võtme väljade täitmine Google'i autoriseerimiseks Super Socializeris

Kriitiline punkt: väljal Authorized redirect URIs ei tohi olla lõpus kaldkriipsu, muidu saad vea redirect_uri_mismatch. Pärast salvestamist ilmub sisselogimislehele nupp „Sign in with Google".

Oluline: selle postituse algne versioon (2020) kirjeldas integratsiooni Google+-iga, mis suleti 2019. aasta aprillis. Kaasaegne Super Socializer kasutab standardset Google OAuth 2.0 protokolli Google Identity Services'i kaudu. Google Cloud Console'i liides on sellest ajast uuenenud, kuid sammude loogika (projekt → Credentials → OAuth client ID → redirect URI) on jäänud samaks.

Alternatiivne lähenemine: kõik koodis

Kui lisamoodulid on ebasoovitavad, saab ülesande lahendada teema functions.php failis või alamteemas. Kood registreerib CPT, loob rolli ja haagib autoriseerimiskontrolli malli külge:

1// Registering a custom post type
2function register_equipment_cpt() {
3 register_post_type('equipment', [
4 'labels' => ['name' => 'Equipment', 'singular_name' => 'Equipment'],
5 'public' => true,
6 'has_archive' => true,
7 'supports' => ['title', 'editor', 'thumbnail'],
8 'capability_type' => 'equipment',
9 'map_meta_cap' => true,
10 ]);
11}
12add_action('init', 'register_equipment_cpt');
13
14// Creating a role on theme activation
15function add_equipment_reader_role() {
16 add_role('equipment_reader', 'Equipment Reader', ['read' => true, 'read_equipment' => true]);
17}
18add_action('after_switch_theme', 'add_equipment_reader_role');
19
20// Redirecting guests from CPT to login page
21function restrict_equipment_to_logged_in() {
22 if (is_singular('equipment') && !is_user_logged_in()) {
23 wp_redirect(wp_login_url(get_permalink()));
24 exit;
25 }
26}
27add_action('template_redirect', 'restrict_equipment_to_logged_in');

Mida see kood teeb: esimene plokk registreerib CPT equipment oma võimekuse tüübiga (capability_type). Teine plokk loob teema aktiveerimisel rolli Equipment Reader koos õigustega seda CPT-d lugeda. Kolmas plokk kontrollib autoriseerimist template_redirect konksul ja saadab külalised wp-login.php lehele.

Koodilähenemise eelis: null lisamoodulit, täielik kontroll. Puudus: sotsiaalne sisselogimine vajab endiselt moodulit (OAuth integratsiooni käsitsi kirjutamine on aeganõudev ja ebaturvaline) ning iga rollide muudatus tähendab koodi redigeerimist.

⁉️🤔 Korduma kippuvad küsimused

Kas ma saan CPT-d piirata ilma mooduliteta, ainult functions.php** faili kaudu?**

Jah. Kombinatsioon register_post_type() + add_role() + template_redirect konks koos is_user_logged_in() kontrolliga on täiesti toimiv lahendus. Kood on toodud ülaltoodud jaotises. Sotsiaalne sisselogimine ilma moodulita on oluliselt keerulisem teostada: käsitsi OAuth integratsioon nõuab tokenite, oleku ja turvalisuse haldamist.

Miks WP Access Areas, mitte uuem moodul nagu ContentGate?

WP Access Areas on minimalistlik tööriist konkreetseks ülesandeks: „piirata postituse tüüpi külaliste eest". See ei too kaasa reeglite koostajat, visuaalseid redaktoreid ega tellimusi. Kui vajate keerukamat loogikat (näiteks erinevaid juurdepääsutasemeid erinevatele rollidele samal CPT-l), kasutage ContentGate'i või PublishPress Permissionsit, mida aktiivselt uuendatakse. Selle juhendi põhistsenaariumi jaoks on WP Access Areas piisav.

Mida teha, kui külalised näevad pärast seadistamist endiselt CPT lehti?

Kolm tüüpilist põhjust. Esiteks: WP Access Areas tabeli säte „Logged in Users" kehtib ainult uutele postitustele; olemasolevate lehtede jaoks tuleb õigused määrata käsitsi redaktori külgriba kaudu. Teiseks: vahemällu salvestamise moodul serveerib külalistele lehe vahemällu salvestatud versiooni; tühjendage vahemälu ja seadistage kaitstud CPT jaoks välistused. Kolmandaks: CPT on registreeritud parameetriga 'publicly_queryable' => true ja selle nimetus kattub avaliku lehega; kontrollige konflikte.

Kas ma saan Super Socializerit kasutada ainult sisselogimiseks, ilma jagamise ja kommentaarideta?

Jah, mooduli moodulid on sõltumatud. Vahekaardil „Social Sharing" eemaldage kõik linnukesed ja „Share" nupud kaovad. Vahekaardil „Social Commenting" keelake integratsioon. Jätke alles ainult „Social Login" koos vajalike teenusepakkujatega. Moodul on kerge ja mittevajalike moodulite keelamine ei mõjuta jõudlust.

Kas PublishPress Capabilitiesi deaktiveerimine pärast rolli loomist on ohutu?

Jah. WordPressi rollid ja võimekused salvestatakse wp_options tabelisse (wp_user_roles säte) ega sõltu neid loonud moodulist. Pärast PublishPress Capabilitiesi deaktiveerimist säilivad kõik loodud rollid ja antud õigused. Kui teil on hiljem vaja õigusi muuta, saate mooduli uuesti aktiveerida.

Kas kirjutada koodi või jääda moodulite juurde

Valik moodulite ja functions.php vahel taandub kahele tegurile: kaitstavate CPT-de arv ja see, kui sageli õigused muutuvad.

Kui teil on ainult üks CPT (nagu seadmete näide), rollid on stabiilsed ja olete nõus üks kord kirjutama 30 rida koodi, on functions.php lähenemine puhtam: see ei tekita mooduleid, ei sõltu kolmandate osapoolte uuendustest ja on täiesti läbipaistev. Super Socializeri saate jätta sotsiaalseks sisselogimiseks, kuna see lahendab kitsa ülesande ega lähe vastuollu kohandatud koodiga.

Kui teil on mitu CPT-d, õigusi muudetakse sageli või saiti haldab mitte-arendaja, valige moodulite kombinatsioon. CPT UI + PublishPress Capabilities + WP Access Areas (või ContentGate) saab administraatori paneelis seadistada 15 minutiga ilma koodi puudutamata. Lisaks varundab PublishPress Capabilities automaatselt rollid iga muudatusega, võimaldades kahe klõpsuga tagasipööramist.

Iga stsenaariumi korral järgige põhimõtet: üks tööriist ühe ülesande jaoks. Ärge paigaldage võimsat kõik-ühes lahendust ühe linnukese pärast ja ärge leiutage jalgratast, kui olemasolev moodul teeb täpselt sama asja kiiremini ja turvalisemalt.

Versioonihaldus väärib eraldi käsitlemist. Kood functions.php failist elab teema repositooriumis, muudatusi jälgitakse Giti kaudu ja saidi migreerimisel luuakse rollid automaatselt uuesti after_switch_theme konksul. Moodulite lähenemine seda läbipaistvust ei paku: rollid salvestatakse andmebaasis ning lavastuskoopia juurutamisel või uuele domeenile üleviimisel tuleb need uuesti luua käsitsi või migratsiooniskripti abil. See tegur saab sageli määravaks koodi kasuks meeskondades, kes praktiseerivad CI/CD-d ja Giti-põhist juurutamist.