sql >> Database teknologi >  >> RDS >> Database

Fejlfinding:For mange omdirigeringer

Fejlen "for mange omdirigeringer" betyder, at hjemmesiden bliver ved med at blive omdirigeret mellem forskellige adresser på en måde, der aldrig bliver fuldført. Ofte er dette resultatet af konkurrerende omdirigeringer, hvor en forsøger at tvinge HTTPS (SSL) og en anden omdirigerer tilbage til HTTP (ikke-SSL), eller mellem www- og ikke-www-former af URL'en.

Hvis du bruger et CMS som Wordpress, Magento osv., der bruger en base_url eller URL-type-konfiguration på webstedet, kan du ende med, at konfigurationen i koden eller databasen er i konflikt med en omdirigering i en .htaccess-fil. Disse modstridende omdirigeringer vil flip flop frem og tilbage og aldrig fuldføre.

Din browser beskytter dig mod dette ved kun at tillade et vist antal omdirigeringer (ofte ti eller deromkring), før den giver op og rapporterer fejlmeddelelsen "for mange omdirigeringer." Dette vises forskelligt mellem Chrome, Firefox og andre browsere.

Firefox

Siden omdirigerer ikke korrekt. Der opstod en fejl under en forbindelse til

Chrome

Denne side fungerer ikke omdirigerede dig for mange gange

Selv testværktøjet curl giver op efter 50 omdirigeringer som standard.

Krølle: Maksimalt (X) omdirigeringer fulgt 

curl -svILk https://www.example.com
 ....
 * Maximum (50) redirects followed

Det første trin:Cache og cookies

Som det fremgår af browserfejlene ovenfor, kan disse looping-omdirigeringer også være forårsaget af cookies i browseren, der cacher gamle omdirigeringer. Det første trin i testen ville være at rydde din cache og cookies i din browser. Hvis du allerede har ryddet cache og cookies i browseren, så er det tid til at gå videre til noget mere avanceret fejlfinding.

Brug af udviklerværktøjer til omdirigeringsløkker

Det næste trin i fejlfinding af disse former for omdirigeringsløkker er at bruge udviklerværktøjerne i Firefox eller Chrome. Disse værktøjer åbnes almindeligvis ved at trykke på F12-tasten. Sørg for at vælge Netværk fanen i en af ​​disse, og genindlæs derefter den side, du har et problem med.

Når du har genindlæst siden, bør du se rækken af ​​omdirigeringer opført for dig i det nye vindue. Når du ser på omdirigeringerne, kan du se, om de omdirigerer mellem et par forskellige ting eller omdirigerer til den samme ting. Uanset hvad, kan du se de trin, der fører op til fejlen, i stedet for blot slutbrugerens browserfejl.

Udviklerværktøjer i Firefox

Brug af cURL til omdirigeringsløkker

Som en del af at skrive denne artikel har vi sammensat et ret simpelt Bash-script, der kan bruges på ethvert Unix-lignende system med krøllen kommando. At bruge curl er rart, fordi det ikke cacher ting på samme måde som browsere gør, så det kan nogle gange give dig et andet perspektiv, når du fejlfinder.

Kopier følgende til dit foretrukne tekstredigeringsprogram, og gem det som redirects.sh .

#!/bin/bash
 echo
 for domain in $@; do
 echo --------------------
 echo $domain
 echo --------------------
 curl -sILk $domain | egrep 'HTTP|Loc' | sed 's/Loc/ -> Loc/g'
 echo
 done

Marker derefter redirects.sh fil som eksekverbar.

chmod +x redirects.sh

Du kan køre vores script, som eksemplerne nedenfor, ved at tilføje dit domæne efter scriptnavnet. Det kan endda kontrollere flere domæner, og det vil kontrollere omdirigeringerne af hver URL, igen og sætte en header mellem separate domæner, der testes.

Eksempel på output 
./redirects.sh liquidweb.com
 --------------------
 liquidweb.com
 --------------------
 HTTP/1.1 301 Moved Permanently
 -> Location: https://liquidweb.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.liquidweb.com/
 HTTP/1.1 200 OK
Eksempel på en uendelig omdirigering fra HTTP til HTTPS 
./redirects.sh http://www.example.com
 --------------------
 http://www.example.com
 --------------------
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 ....
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
En sidebemærkning om omdirigeringstyper

Ser på krøllen output ovenfor kan du se, at HTTP-svarkoden er 301. 301-redirects er "Permanent" omdirigering, hvilket betyder, at noget er permanent flyttet, og du eller din browser skal slå det op på den nye placering både nu og i fremtiden. 302-omdirigeringer er "midlertidige" omdirigeringer, hvilket betyder, at noget har flyttet sig for nu, men måske ikke altid er på den nye placering.

301-omdirigeringer bliver oftere end ikke skrevet ud som omdirigerings- eller omskrivningsindgange i en .htaccess-fil. 302-omdirigeringer, enten efter design eller konvention, genereres dog ofte inden for koden på et websted. Så en god tommelfingerregel er, at 301'er er i .htaccess-filer, og 302'er er i webstedskode. Dette er måske ikke altid sandt, men det er en god ting at huske på.

Omdirigeringer i .htaccess-filen

.htaccess-filen er en konfigurationsfil, der bruges til at ændre Apache-serveradfærd pr. mappe på en hjemmeside/server. Dette er en konfigurationsfil på brugerniveau, og kun nogle Apache-konfigurationer kan redigeres her, selvom omdirigeringer er almindelig brug.

Du kan have flere .htaccess-filer, der går over en række mapper. Hvis du har en .htaccess i en overordnet mappe, og en anden i en undermappe, vil de begge påvirke undermappen. I disse tilfælde er det vigtigt at huske, hvor du har og ikke har .htaccess-filer, for at forhindre konflikter mellem .htaccess-filer på forskellige niveauer.

Nedenfor er en række eksempler på omdirigering og vil hjælpe med at identificere omdirigeringer i din .htaccess-fil. Dette er ikke de eneste måder at udføre denne slags omdirigeringer på, men disse bør vise dig, hvordan de mest almindelige omdirigeringer ser ud, så du kan genkende dem, hvis de er i en .htaccess-fil, du arbejder med.

Tving HTTPS

.htaccess-koden nedenfor kontrollerer først, om anmodningen kom ind på serveren ved hjælp af HTTP eller HTTPS. Hvis anmodningen ikke brugte HTTPS, vil konfigurationen bede browseren om at omdirigere til HTTPS-versionen af ​​det samme websted og den samme URL, som blev anmodet om før.

RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Force HTTPS:When Behind a Load Balancer eller Proxy (CloudFlare/Incapsula/Sucuri/etc.)

Nogle gange bruger du muligvis en proxy, som en load balancer eller en web-firewall, som CloudFlare, Incapsula eller Sucuri. Disse kan konfigureres til at bruge SSL på frontend, men ikke bruge SSL på bagenden. For at tillade dette at fungere korrekt, skal du ikke kun tjekke for HTTPS i anmodningen, men også om proxyen har videregivet den originale HTTPS-anmodning til serveren ved hjælp af kun HTTP. Denne følgende regel kontrollerer, om anmodningen blev videresendt fra HTTPS, og i så fald forsøger den ikke at omdirigere en ekstra gang.

RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteCond %{HTTP:X-Forwarded-Proto} =http
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Tving ikke-www

Denne omdirigering kontrollerer kun, om webstedsnavnet blev anmodet om med www i starten af ​​domænenavnet. Hvis www er inkluderet, omskriver den anmodningen og beder browseren om at omdirigere til den ikke-www-version af domænenavnet.

RewriteEngine On
 RewriteCond %{HTTP_HOST} ^www\. [NC]
 RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Tving www

Denne sidste omdirigering kontrollerer, om webstedsnavnet ikke blev anmodet om med www i starten af ​​domænenavnet. Hvis www ikke er inkluderet, omskriver den anmodningen og beder browseren om at omdirigere til www-versionen af ​​domænet.

RewriteEngine On
 RewriteCond %{HTTP_HOST} !^www\. [NC]
 RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

WordPress

WordPress CMS bruger en .htaccess-fil til at omskrive URL'er til index.php fil, men den definerer webstedets URL som en værdi i databasen. Hvis du ikke allerede kender navnet på den database, der bruges på webstedet, kan du slå det op i hovedkonfigurationen for WordPress (wp-config.php ).

Du kan også åbne filen i en teksteditor og se efter disse værdier, men fra en SSH-forbindelse kan du bruge programmet grep . Dette giver dig mere end blot databasenavnet, men databasenavnet er det vigtigste for, hvad vi skal gøre næste gang.

grep DB wp-config.php

define('DB_NAME', 'wordpress_database');
 define('DB_USER', 'wordpress_username');
 define('DB_PASSWORD', 'Password');
 define('DB_HOST', 'localhost');
 define('DB_CHARSET', 'utf8');
 define('DB_COLLATE', '');
Wp_options-tabellen

Når du kender navnet på databasen, kan du se på indstillingstabellen i Wordpress-databasen for at se, hvad URL'en er sat til i databasen. Indstillingstabellen kan have et hvilket som helst præfiks i begyndelsen af ​​tabelnavnet, men det er ofte "wp_" som standard, så det fulde navn på indstillingstabellen er normalt wp_options . De to linjer, der er vigtige, er hjemmet og siteurl linjer i indstillingstabellen. Du kan finde disse ved at bruge phpMyAdmin , eller et andet databasestyringsværktøj, men fra kommandolinjen kan du også bare køre følgende mysql kommando.

mysql -e 'show tables' wordpress_database | grep options

prefix_options
Tjekker den konfigurerede URL

Fra kommandolinjen kan du kontrollere, hvad de aktuelle værdier for hjemmet og siteurl linjer i indstillingstabellen. Kommandoen skal sende dig og output som eksemplet nedenfor. Den vigtige del er, at disse matcher hinanden under de fleste omstændigheder, og at de er, hvad du forventer. Hvis de ikke er, hvad du forventer, vil du gerne opdatere dem i overensstemmelse hermed.

mysql -e 'select * from wp_options where option_name rlike "home|siteurl"' wordpress_database
 +-----------+-------------+----------------------------------+----------+
 | option_id | option_name | option_value                     | autoload |
 +-----------+-------------+----------------------------------+----------+
 |        36 | home        | http://www.example.com           | yes |
 |         1 | siteurl     | http://www.example.com           | yes |
 +-----------+-------------+----------------------------------+----------+

Opdatering af den konfigurerede URL

Den følgende kommando vil opdatere de to rækker i wp_options tabel for en given database til en ny URL. Denne kommando bør passe til de fleste situationer, hvor du skal opdatere eller rette den URL, der er konfigureret til et Wordpress-websted. Opdatering af base_urls konfigureret i et Wordpress Multisite er uden for denne artikels omfang, men vil indebære opdatering af flere wp_option type tabeller.

mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_database

Magento

Magento-databasenavnet er konfigureret i en af ​​følgende filer, local.xml eller env.php . Du kan også konfigurere et præfiks for tabelnavnene i Magento-databasen, men det er normalt ikke indstillet. Så det forventede navn for databasens hovedkonfigurationstabel er bare core_config_data .

# Version 1.x
 app/etc/local.xml

# Version 2.x
 app/etc/env.php
core_config_data-tabellen

Der er mange potentielle webadresser, der kan konfigureres, men de har alle "base_url " som en del af linjen i databasen. De primære konfigurerede URL'er vil være de sikre og usikre URL'er, men du kan også konfigurere URL'er til billeder, temafiler eller endda oprette en separat URL til administrationsområdet på webstedet. Du kan igen finde disse ved hjælp af et databasestyringsværktøj, men fra kommandolinjen kan du køre noget i stil med følgende.

mysql -e 'select * from core_config_data where path rlike "base_url"' magento_database
 +-----------+---------+----------+-----------------------+----------------------------+
 | config_id | scope   | scope_id | path             | value |
 +-----------+---------+----------+-----------------------+----------------------------+
 |         3 | default |        0 | web/unsecure/base_url | http://www.example.com     |
 |         4 | default |        0 | web/secure/base_url   | http://www.example.com   |
 +-----------+---------+----------+-----------------------+----------------------------+

For at opdatere base_urls i Magento-databasen, ville du køre noget som kommandoen nedenfor. Opdatering af base_url'erne for en Magento Multisite ligger også uden for denne artikels omfang, men vil indebære yderligere henvisning til det specifikke scope_id værdi for den givne hjemmeside eller butik konfigureret i Magento-databasen.

mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_database

Afslutter det hele

Med URL'er konfigureret i databasen, som vist ovenfor, er det værd at bemærke, at disse CMS'er også giver deres egne omdirigeringsmetoder inden for webstedskoden. Hvis du for eksempel har en .htaccess-omdirigering, der omdirigerer til en URL, der ikke stemmer overens med det, der er i databasen, kan du ende med den uendelige omdirigeringsløkke som beskrevet tidligere. Men du ved nu, hvordan nogle almindelige .htaccess-omdirigeringer ser ud, og hvor du kan finde de konfigurerede URL'er i nogle CMS-softwaredatabaser. Du er også godt rustet til at teste, undersøge og bekræfte, om disse ting fungerer sammen eller virker mod hinanden, og nogle trin til at løse dem.


  1. Postgresql vælg indtil et bestemt totalbeløb er nået

  2. hvordan man støber hexadecimalen til varchar (datetime)?

  3. Migrering fra MSSQL til PostgreSQL - hvad du bør vide

  4. Relationelle databaser