Introduksjon til XML-RPC. Programmeringskonkurranser Hva er synlig i serverloggene
Innlegget hans viser også hvordan du gjør nettleserautentisering, som nedenfor:
$request = xmlrpc_encode_request ("metodenavn", array("metodeParam"));
$auth = base64_encode ($brukernavn . ":" . $passord );
$header = (version_compare(phpversion(), "5.2.8"))
? array("Content-Type: text/xml" , "Authorization: Basic $auth " )
: "Innholdstype: text/xml\r\nAutorisasjon: Grunnleggende$auth " ; //
$context = stream_context_create (array("http" => array(
"method" => "POST" ,
"header" => $header ,
"content" => $forespørsel
)));
$webservice = "http://www.example.com/rpc";
$fil = file_get_contents($webtjeneste, falsk, $kontekst);
$respons = xmlrpc_decode ($file);
if (xmlrpc_is_fault($response)) (
return "xmlrpc: $respons [faultString] ($response [faultCode])" ;
) annet (
returnere $respons ;
}
?>
1 - REDAKTØR MERK: DETTE ER EN LØSNING FRA "SandersWang dt php at gmail dot com"
16 år siden
Binære strenger (sett med xmlrpc_set_type) går inn i en
Selv om det er dumt, forårsaker det virkelige problemer for noen XML-RPC-servere, for eksempel http://jakarta.apache.org/xmlrpc/ (nee Helma). Å fjerne disse enhetene med noe sånt som
$req = preg_replace("/ /", "", xmlrpc_encode_request("min.metode", $args));
fungerer rundt problemet.
11 år siden
Det skal bemerkes at koding ikke ser ut til å kode noe, bare spesifiser hva som skal inn i XML-overskriften.
Vi hadde problemer med at dobbeltkodede UTF-strenger ble lagret i databasen når vi brukte denne funksjonen, sendte den til en apache xml-rpc-servlet og lagrer den i mysql-databasen. Det ble løst ved å sette "escaping" til bare "markup" og "encoding" til "UTF-8" (ikke glem å sette "utf-8" i xmlrpc_decode også).
Det ser ut til at UTF-8-kodede strenger blir escaped med deres byte som enheter i stedet for tegnene som entiteter.
9 år siden
Har du noen gang prøvd å overføre en matrise som følgende med xmlrpc?
$var1=array(7=>14,9=>18);
Utdatamatrisen ser ganske annerledes ut! Det vil se slik ut:
$var2=array(14,18);
Den eneste løsningen jeg fant er å sette et mellomrom foran indeksen:
$var3=array(" 7"=>14," 9"=>18);
Ved å bruke den metoden får du det riktige resultatet. ($var1)
16 år siden
Denne funksjonen skal brukes av en XML-RPC-klient for å lage en XML-nyttelast for en XML-RPC-forespørsel;
$params = "system.methodSignatur" ;
$method = "system.methodHelp" ;
$request = xmlrpc_encode_request ($metode, $params);
echo ($request);
?>
Produserer;
Det andre argumentet gjenkjenner typen variabel og genererer riktig XML-RPC-struktur. Se xmlrpc_encode() for flere detaljer.
12 år siden
Enkel OO-klient med funksjon Overload:
php-metoden test_helloworld er oversatt til xmlrpc-metoden test.helloworld.
klasse RpcClient(
private $_metoder;
privat $_context;
privat $_url;
Funksjon __construct ($url, $user, $passwd) (
$auth = base64_encode(sprintf("%s:%s", $user,$passwd));
$this->_context = stream_context_create(array(
"http" => array(
"method" => "POST",
"header" => "Innholdstype: text/xml\r\n".
"Autorisasjon: Grunnleggende $auth" ,
)
));
$this->_url = $url;
$this->registerMethod("Test_HelloWorld");
Funksjon __call($methodName, $params) (
if (array_key_exists($methodName,$this->_methods)) (
// på appelle la fonction RPC
$m = str_replace("_", ".", $metodenavn);
$r = xmlrpc_encode_request($m, $params,array("verbosity"=>"newlines_only"));
$c = $this->_context;
stream_context_set_option($c,"http","content",$r);
$f = file_get_contents($this->_url,false,$c);
$resp = xmlrpc_decode($f);
returnere $resp;
) annet (
// på appelle la fonction de l"objet
call_user_method_array($methodName, $this,$params);
}
}
Privat funksjonsregisterMethod ($method) (
$this->_methods[$method] = sant;
}
Introduksjon til XML-RPC
Det er mange forskjellige ressurser på Internett som gir brukerne viss informasjon. Dette betyr ikke vanlige statiske sider, men for eksempel data hentet fra en database eller arkiver. Dette kan være et arkiv med finansielle data (valutakurser, verdipapirkursdata), værdata eller mer omfangsrik informasjon - nyheter, artikler, meldinger fra fora. Slik informasjon kan presenteres for den besøkende på siden, for eksempel gjennom et skjema, som et svar på en forespørsel, eller den kan genereres dynamisk hver gang. Men vanskeligheten er at slik informasjon ofte ikke er nødvendig av sluttbrukeren - en person, men av andre systemer og programmer som vil bruke disse dataene til sine beregninger eller andre behov.
Ekte eksempel: en side på et banknettsted som viser valutakurser. Hvis du går inn på siden som en vanlig bruker, gjennom en nettleser, ser du all sidedesign, bannere, menyer og annen informasjon som "rammer inn" den sanne hensikten med søket - valutakurser. Hvis du trenger å legge inn disse sitatene i nettbutikken din, er det ingenting annet å gjøre enn å velge de nødvendige dataene manuelt og overføre dem til nettstedet ditt via utklippstavlen. Og du må gjøre dette hver dag. Er det virkelig ingen vei utenom?
Hvis du løser problemet direkte, oppstår en løsning umiddelbart: et program (skript på et nettsted) som trenger data mottar en side fra serveren som en "vanlig bruker", analyserer (parser) den resulterende html-koden og trekker ut nødvendig informasjon fra den. Dette kan gjøres enten med et regulært regulært uttrykk, eller ved å bruke en hvilken som helst html-parser. Vanskeligheten med tilnærmingen ligger i dens ineffektivitet. For det første, for å motta en liten del av data (data om valutaer er bokstavelig talt et dusin eller to tegn), må du motta hele siden, som er minst flere titalls kilobyte. For det andre, med enhver endring i sidekoden, for eksempel designet har endret seg eller noe annet, må parsingalgoritmen vår gjøres om. Og dette vil kreve en god del ressurser.
Derfor kom utviklerne til en beslutning - det er nødvendig å utvikle en slags universell mekanisme som vil tillate gjennomsiktig (på protokoll- og overføringsmediumnivå) og enkel utveksling av data mellom programmer som kan lokaliseres hvor som helst, skrives på hvilket som helst språk og kjøres under alle operativsystemer, systemer og på hvilken som helst maskinvareplattform. En slik mekanisme kalles nå de høylytte begrepene "Webtjenester", "SOAP", "tjenesteorientert arkitektur". For datautveksling brukes åpne og tidstestede standarder - HTTP-protokollen brukes til å overføre meldinger (selv om andre protokoller kan brukes - for eksempel SMTP). Selve dataene (i vårt eksempel valutakurser) overføres pakket i et tverrplattformformat - i form av XML-dokumenter. For dette formålet ble en spesiell standard oppfunnet - SOAP.
Ja, nå er webtjenester, SOAP og XML på alles lepper, de begynner å bli aktivt implementert, og store selskaper som IBM og Microsoft slipper nye produkter designet for å hjelpe den totale implementeringen av webtjenester.
Men! For vårt eksempel med valutakurser som må overføres fra bankens nettside til nettbutikkmotoren, vil en slik løsning være svært vanskelig. Tross alt tar beskrivelsen av SOAP-standarden alene opp over halvannet tusen sider, og det er ikke alt. For praktisk bruk må du også lære å jobbe med tredjeparts biblioteker og utvidelser (bare fra PHP 5.0 inkluderer det et bibliotek for arbeid med SOAP), og skrive hundrevis og tusenvis av linjer med din egen kode. Og alt dette for å få noen bokstaver og tall er åpenbart veldig tungvint og irrasjonelt.
Derfor finnes det en annen, kan man si, alternativ standard for informasjonsutveksling - XML-RPC. Den ble utviklet med deltakelse av Microsoft av UserLand Software Inc og er designet for enhetlig dataoverføring mellom applikasjoner over Internett. Det kan erstatte SOAP når du bygger enkle tjenester der alle "enterprise"-funksjonene til ekte webtjenester ikke er nødvendige.
Hva betyr forkortelsen XML-RPC? RPC står for Remote Procedure Call. Dette betyr at en applikasjon (enten det er et skript på serveren eller en vanlig applikasjon på klientdatamaskinen) transparent kan bruke en metode som er fysisk implementert og utført på en annen datamaskin. XML brukes her for å gi et universelt format for å beskrive de overførte dataene. Som en transport brukes HTTP-protokollen til å overføre meldinger, som lar deg sømløst utveksle data gjennom alle nettverksenheter - rutere, brannmurer, proxy-servere.
Og så, for å bruke må du ha: en XML-RPC-server som gir en eller flere metoder, en XML-RPC-klient som kan generere en korrekt forespørsel og behandle serversvaret, og også kjenne serverparametrene som er nødvendige for vellykket drift - adresse, metodenavn og beståtte parametere.
Alt arbeid med XML-RPC skjer i "request-response"-modus, dette er en av forskjellene mellom teknologien og SOAP-standarden, hvor det er både konseptet med transaksjoner og muligheten til å foreta forsinkede anrop (når serveren lagrer forespørselen og svarer på den på et bestemt tidspunkt i fremtiden). Disse tilleggsfunksjonene er mer nyttige for kraftige bedriftstjenester; de kompliserer utviklingen og støtten til servere betydelig, og stiller ytterligere krav til utviklere av klientløsninger.
Prosedyren for å arbeide med XML-RPC begynner med å lage en forespørsel. En typisk forespørsel ser slik ut:
POST /RPC2 HTTP/1.0
Brukeragent: eshop-test/1.1.1 (FreeBSD)
Vert: server.localnet.com
Innholdstype: tekst/xml
Innholdslengde: 172
De første linjene danner standard HTTP POST-forespørselshode. Nødvendige parametere inkluderer vert, datatype (MIME-type), som må være tekst/xml, og meldingslengde. Standarden spesifiserer også at feltet User-Agent må fylles ut, men kan inneholde en vilkårlig verdi.
Deretter kommer den vanlige overskriften til XML-dokumentet. Rotelementet i forespørselen er
Linje
Deretter settes de overførte parameterne. Denne delen brukes til dette.
Beskrivelsen av alle parametere etterfølges av avsluttende tagger. Forespørselen og svaret i XML-RPC er vanlige XML-dokumenter, så alle tagger må lukkes. Men det er ingen enkeltkoder i XML-RPC, selv om de finnes i XML-standarden.
La oss nå se på serverens svar. HTTP-svarhodet er normalt; hvis forespørselen behandles vellykket, returnerer serveren et HTTP/1.1 200 OK-svar. Akkurat som i forespørselen, må du spesifisere MIME-type, meldingslengde og genereringsdato for svar.
Selve responsorganet er som følger:
Nå i stedet for root-taggen
Hvis det oppstod en feil under behandlingen av forespørselen din, i stedet for Svaret vil inneholde elementet
La oss nå ta en kort titt på datatyper i XML-RPC. Det er 9 datatyper totalt - syv enkle typer og 2 komplekse. Hver type er beskrevet med sin egen tag eller sett med tagger (for komplekse typer).
Enkle typer:
Hele tall- stikkord
Boolsk type- stikkord
ASCII-streng- beskrevet av tag
Flytende kommatall- stikkord
dato og tid- beskrevet av tag
Den siste enkle typen er base64-kodet streng, som er beskrevet av taggen
Komplekse typer er representert av strukturer og matriser. Strukturen bestemmes av rotelementet
Arrays har ingen navn og beskrives av taggen
Selvfølgelig vil noen si at en slik liste over datatyper er veldig dårlig og "ikke lar deg utvide." Ja, hvis du trenger å overføre komplekse objekter eller store datamengder, er det bedre å bruke SOAP. Og for små, lite krevende applikasjoner er XML-RPC ganske egnet; dessuten viser seg ofte at til og med evnene er for mange! Med tanke på den enkle utrullingen, et veldig stort antall biblioteker for nesten alle språk og plattformer, og bred støtte i PHP, så har XML-RPC ofte rett og slett ingen konkurrenter. Selv om det ikke umiddelbart kan anbefales som en universalløsning - må det i hvert enkelt tilfelle avgjøres etter omstendighetene.
XML-RPC-teknologi brukes i WordPress-systemet for ulike fine funksjoner som pingbacks, trackbacks, ekstern nettstedsadministrasjon uten å logge inn på adminpanelet, etc. Dessverre kan angripere bruke den til å utføre DDoS-angrep på nettsteder. Det vil si at du lager vakre, interessante WP-prosjekter for deg selv eller på bestilling, og samtidig, uten å mistenke noe, kan du være en del av et DDoS-botnett. Ved å koble titusenvis og hundretusenvis av nettsteder sammen, skaper dårlige mennesker et kraftig angrep på offeret. Selv om nettstedet ditt samtidig lider, fordi... lasten går til hostingen der den er plassert.
Bevis på slik dårlig aktivitet kan være i serverloggene (access.log in nginx), som inneholder følgende linjer:
103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"
Men la oss gå tilbake til XML-RPC-sårbarheten. Visuelt manifesterer det seg i sakte åpning av nettsteder på serveren din eller manglende evne til å laste dem i det hele tatt (502 Bad Gateway-feil). Den tekniske støtten til FASTVPS-verten min bekreftet mine gjetninger og ga råd:
- Oppdater WordPress til siste versjon sammen med plugins. Generelt, hvis du følger, har du kanskje lest om behovet for å installere den nyeste 4.2.3. på grunn av sikkerhetskritikk (akkurat som tidligere versjoner). Kort sagt, det er greit å oppdatere.
- Installer Deaktiver XML-RPC Pingback-plugin.
Deaktiverer XML-RPC i WordPress
Tidligere ser det ut til at alternativet for å aktivere/deaktivere XML-RPC var et sted i systeminnstillingene, men nå finner jeg det ikke der. Derfor er den enkleste måten å bli kvitt det på å bruke passende plugin.
Finn og last ned Deaktiver XML-RPC Pingback eller installer det direkte fra systemadministrasjonspanelet. Du trenger ikke konfigurere noe ekstra, modulen begynner å fungere umiddelbart. Den fjerner metodene pingback.ping og pingback.extensions.getPingbacks fra XML-RPC-grensesnittet. I tillegg fjerner den X-Pingback fra HTTP-hoder.
I en av bloggene fant jeg et par flere alternativer for å fjerne XML-RPC-deaktiveringen.
1. Deaktiver XML-RPC i malen.
For å gjøre dette, legg til følgende linje i temaets functions.php-fil:
Jeg personlig brukte ikke de to siste metodene, fordi... Jeg koblet til Deaktiver XML-RPC Pingback-plugin - jeg tror det vil være nok. Bare for de som ikke liker unødvendige installasjoner, foreslo jeg alternative alternativer.
Fra og med middag på lørdag begynte serveren min, hvor omtrent 25 Wordpress-sider er vert, å oppleve alvorlige nedganger. Siden jeg klarte å overleve de tidligere angrepene ( , ) uten å bli lagt merke til, forsto jeg ikke umiddelbart hva som skjedde.
Da jeg skjønte det, viste det seg at passord ble brute-forced + mange forespørsler til XMLRPC.
Som et resultat klarte vi å kutte det hele, men ikke umiddelbart. Her er tre enkle triks for hvordan du unngår dette.
Disse teknikkene er mest sannsynlig kjent for alle, men jeg tråkket på et par feil som jeg ikke fant i beskrivelsene - kanskje dette vil spare noen tid.
1. Stopp søket, installer Limit Login Attempts-pluginen - installer den, siden andre beskyttelser bremser serveren kraftig, for eksempel når du bruker Login Security Solution-pluginen, døde serveren etter en halvtime, plugin-en belaster databasen tungt .
I innstillingene, sørg for å slå på "For proxy"-avmerkingsboksen - ellers vil den bestemme IP-en til serveren din for alle og automatisk blokkere alle.
OPPDATERING, takk, detaljer er nedenfor i kommentarene - aktiver "For proxy" avmerkingsboksen bare hvis definisjonen ikke fungerer når "Direkte tilkobling" er aktivert
2. Deaktiver XML-RPC - Deaktiver XML-RPC-plugin (det er enkelt å aktivere og det er det).
3. Lukk wp-login.php - hvis du får tilgang til siden via IP, fungerer ikke plugin-en og velgerne fortsetter å krasje siden. For å unngå dette, legg til i .htaccess:
Vi kopierer wp-login-filen, omdøper den til et hvilket som helst merkelig navn, for eksempel poletnormalny.php, og inne i filen bruker vi autokorrektur for å endre alle wp-login.php-inskripsjonene til poletnormalny.php.
Det er det, nå kan du bare få tilgang til administrasjonspanelet ved å bruke filen din.
Etter disse 3 enkle trinnene begynte sidene å fly igjen og freden kom.
Vel, plutselig er det interessant
Et av alternativene er å se om du blir angrepet. Dette kan sees i nginx-loggene (her er for eksempel banen til Debian /var/log/nginx access.log-filen).WordPress har alltid hatt et innebygd verktøy for ekstern tilgang til nettstedet ditt. Noen ganger må du faktisk komme til nettstedet ditt, men datamaskinen din er langt unna deg. Lenge var løsningen en fil kalt xmlrpc.php. Imidlertid har denne filen de siste årene blitt mer et problem enn en løsning.
Nedenfor skal vi se nærmere på xmlrpc.php og hvorfor det ble opprettet. Vi vil også se på de vanlige sikkerhetsproblemene det kan forårsake og hvordan du kan fikse dem for WordPress-nettstedet ditt.
XML-RPC er en WordPress-funksjon som tillater dataoverføring, med HTTP som transport og XML for koding. Siden WordPress ikke er et lukket system og ofte kommuniserer med andre systemer, har man funnet løsninger på dette problemet.
La oss for eksempel si at du vil legge ut innlegg på nettstedet ditt fra mobiltelefonen din. Du må bruke fjerntilgangen fra xmlrpc.php.
Hovedfunksjonaliteten til xmlrpc.php er muligheten til å koble til nettstedet fra en smarttelefon, implementering av trackbacks og linkbacks fra andre nettsteder, og noen funksjoner relatert til Jetpack-pluginen.
Hvorfor ble Xmlrpc.php opprettet og hvordan ble det brukt?
Implementeringen av XML-RPC går langt tilbake til de første dagene av WordPress og til og med før WordPress ble WordPress.
Tilbake i de tidlige dagene av internett var forbindelsene veldig trege og prosessen med å ta opp og publisere på nettet var mye vanskeligere og mer tidkrevende. I stedet for å gjøre endringer direkte gjennom nettleseren, gjorde de fleste dem offline og deretter kopierte og limte inn innholdet deres på nettet. Og denne prosessen var langt fra ideell.
Løsningen (den gang) var å lage en offline bloggeklient hvor du kunne komponere innholdet ditt, deretter koble til bloggen din og publisere den. Denne forbindelsen ble gjort via XML-RPC. Med kjerne-XML-RPC-funksjonalitet ga tidlige applikasjoner som brukte disse forbindelsene folk muligheten til å få tilgang til WordPress-nettstedene deres fra andre enheter.
XML-RPC i dag
I 2008, med versjon 2.6 av WordPress, ble det introdusert et alternativ for å aktivere eller deaktivere XML-RPC. Med utgivelsen av WordPress iPhone-appen ble imidlertid XML-RPC-støtte aktivert som standard, og det var ingen mulighet for å deaktivere den. Det er fortsatt slik i dag.
Selvfølgelig har funksjonaliteten gitt av denne filen redusert betydelig over tid, og filstørrelsen har gått ned fra 83kb til 3kb, den spiller ikke lenger en slik rolle som før.
XML-RPC-egenskaper
Med det nye WordPress Application Programming Interface (API) kan vi forvente at XML-RPC blir fullstendig deaktivert. I dag er denne nye API-en fortsatt i testing og kan bare aktiveres via en spesiell plugin.
Selv om du kan forvente at API-en blir inkludert direkte i WordPress-kjernen i fremtiden, eliminerer behovet for xmlrpc.php helt.
Det nye API-et er ikke perfekt, men det gir god, pålitelig sikkerhet, i motsetning til xmlrpc.php.
Hvorfor deaktivere Xmlrpc.php
Det største problemet med XML-RPC er sikkerhet. Problemet er ikke direkte relatert til XML-RPC, men det kan brukes til å aktivere et angrep på nettstedet ditt.
Selvfølgelig kan du beskytte deg selv med et veldig sterkt passord og WordPress-sikkerhetsplugins. Men den beste beskyttelsesmodusen er å ganske enkelt slå den av.
Det er to hovedsvakheter ved XML-RPC som har blitt utnyttet tidligere.
Den første bruker brute force-angrep for å få tilgang til nettstedet ditt. Angriperen vil prøve å få tilgang til nettstedet ditt ved å bruke xmlrpc.php ved å prøve forskjellige kombinasjoner av brukernavn og passord. De kan effektivt bruke én kommando til å teste hundrevis av forskjellige passord. Dette lar dem omgå sikkerhetsverktøy som normalt vil oppdage og blokkere brute force-angrep.
Den andre er å ta nettstedet offline gjennom et DDoS-angrep. Hackere vil bruke omvendt varsling i WordPress for å sende den til tusenvis av nettsteder samtidig. Denne xmlrpc.php-funksjonaliteten gir hackere et nesten uendelig antall IP-adresser for å spre et DDoS-angrep.
For å sjekke om XML-RPC fungerer på nettstedet ditt, kan du kjøre det ved å bruke et verktøy som heter XML-RPC Validator. Kjør nettstedet ditt med verktøyet, og hvis du får en feil, betyr det at du ikke har XML-RPC-støtte.
Hvis du mottar en suksessmelding, kan du stoppe xmlrpc.php ved å bruke en av de to metodene nedenfor.
Metode 1: Deaktiver Xmlrpc.php ved hjelp av en plugin
Å deaktivere XML-RPC på WordPress-siden din er utrolig enkelt.
Gå til seksjon Plugins › Legg til ny i WordPress-administrasjonskonsollen. Finn en plugin Deaktiver XML-RPC og installer det, ser det ut som på bildet nedenfor:
Aktiver plugin-en og du er ferdig. Denne plugin vil automatisk sette inn den nødvendige koden for å deaktivere XML-RPC.
Husk imidlertid at installerte plugins kan bruke deler av XML-RPC, og deaktivering av det kan føre til en konflikt mellom plugins eller deres individuelle deler og ta dem ut av arbeidsmodus.
Hvis du bare vil deaktivere individuelle XML-RPC-elementer, men la andre plugins og funksjoner fungere, kan du se til plugins som disse:
- Stopp XML-RPC-angrep. Dette pluginet vil stoppe alle XML-RPC-angrep, men det vil tillate plugins som Jetpack og andre automatiserte verktøy og plugins å fortsette å kjøre ved å gi dem tilgang til xmlrpc.php-filer.
- Kontroller XML-RPC-publisering. Dette lar deg opprettholde kontrollen og publisere eksternt.
Metode 2: Deaktiver Xmlrpc.php manuelt
Hvis du ikke vil bruke en plugin og foretrekker å gjøre det manuelt, følg denne tilnærmingen. Den vil stoppe alle innkommende xmlrpc.php-forespørsler før den sendes til WordPress.
Åpne .htaccess-filen. Du må kanskje aktivere "vis skjulte filer" i filbehandleren eller FTP-klienten for å finne denne filen.
Lim inn denne koden i filen .htaccess:
# Blokker WordPress xmlrpc.php-forespørsler
Siste tanker
Totalt sett var XML-RPC en solid løsning på noen av problemene som fulgte med ekstern publisering på WordPress-siden din. Men samtidig dukket det opp noen sikkerhetshull som viste seg å være ganske farlige for enkelte WordPress-eiere.
For å holde nettstedet ditt sikkert, anbefales det å deaktivere xmlrpc.php helt med mindre du trenger noen av funksjonene som kreves av ekstern publisering og Jetpack-plugin. Du kan deretter bruke midlertidige plugins som lar deg bruke disse funksjonene mens du lapper sikkerhetshullene.
Over tid kan vi forvente at XML-RPC-funksjonalitet blir integrert i et nytt WordPress API som vil støtte ekstern tilgang uten å ofre sikkerheten.
Har du blokkert tilgang til XML-RPC via en plugin eller manuelt? Eller var det noen sikkerhetsproblemer fordi den tidligere var aktiv? Del opplevelsen din i kommentarene nedenfor.
