Audi præsenterer: Lad det gå

Chrome:

"Skrifttype fra oprindelse 'https://eksempel.com' er blokeret for indlæsning af cross-origin ressourcedelingspolitik: Ingen 'Access-Control-Allow-Origin' -overskrift er til stede på den anmodede ressource. Oprindelse 'https: // www.example.com 'har derfor ikke adgang. "

My .htaccess file looks like this: RewriteEngine on RewriteCond %{HTTP_HOST} ^www.example.com [NC] RewriteRule ^(.*)$ https://example.com/$1 [L,R=301,NC] Redirect 301 / https://example.com 

Derefter tilføjede jeg dette i bunden af ​​filen:

Header add Access-Control-Allow-Origin '*' 

... og ryddet cache samme problem.

... derefter pr. denne artikel: Skrifttype blokeret for indlæsning af Cross-Origin Resource Sharing-politik: Ingen 'Access-Control-Allow-Origin'

Jeg tilføjede disse linjer og erstattede mit domæne med example.com:

  Header set Access-Control-Allow-Origin 'https://example.com'     Header set Access-Control-Allow-Origin 'https://www.example.com'   

Min hele .htaccess ser sådan ud:

RewriteEngine on RewriteCond %{HTTP_HOST} ^www.example.com [NC] RewriteRule ^(.*)$ https://example.com/$1 [L,R=301,NC] Redirect 301 / https://example.com Header add Access-Control-Allow-Origin '*'   Header set Access-Control-Allow-Origin 'https://example.com'     Header set Access-Control-Allow-Origin 'https://www.example.com'   

Er der nogen hjælp her?

  • 1 Det Redirect Direktivet ser ud af sted ... som enten resulterer i en omdirigeringssløjfe, men mangler et bagudvendt skråstreg på mål-URL'en (hvilket vil resultere i en forkert formet anmodning ?!), eller brugeren / anmodningen omdirigeres til en "anden server "så de resterende direktiver udføres ikke ?!
  • Hej, tak for din hjælp. Jeg sætter en skråstreg fremad i slutningen af ​​domænerne i ... eksempel.com, ... www.eksempel.com ... element. Men til ingen fly. Da jeg både har www.example.com og example.com som domæner, behandler Google dem som to separate sider. Så jeg tilføjede en .htaccess-fil til doc-roden (/var/www/example.com/public_html) omdirigerer anmodninger om www til eksemplet.com. Webstedet hostes på en CentOS 7-server med Apache. Interessant: Jeg får ikke fejl, hvis jeg går til example.com. Bare www.example.com. Skal jeg bumpe for at omdirigere problemet her?
  • 1 Formentlig linker du til https://www.example.com/... i hele din ansøgning? Hvorfor har du 2 indpakninger? Sekundet Header set vil simpelthen overskrive den første. (Dog er jeg stadig fast ved det tidligere Redirect direktiv - jeg kan slet ikke se, hvordan dette fungerer?)
  • Det er et rigtig godt spørgsmål. Jeg tror, ​​fordi jeg ville dække både www.example.com og example.com bare i tilfælde af. Emneartiklen, som jeg fik kodeeksemplet fra, havde ikke helt det nøjagtige problem, som jeg har, så jeg ville dække begge domæner, der er det samme sted (applikation), hvis det var det, du mente med "applikation". Også .htaccess-filen (som formodes at pege på www.example.com anmoder om at omdirigere til eksempel.com-domænet, og den fungerer slet ikke. Jeg har endnu ikke løst problemet.

Indstilling af to Access-Control-Allow-Origin overskrifter fungerer ikke. Hvis du vil tillade to forskellige underdomæner (bare domæne og "www"), foreslår dette StackOverflow-svar, at du gør dette:

 SetEnvIf Origin '^http(s)?://(.+\.)?example\.com$' origin_is=$0 Header always set Access-Control-Allow-Origin %{origin_is}e env=origin_is  

Du skal derefter faktisk teste for at se, om det fungerer. Du kan bruge curl på kommandolinjen:

$ curl --header 'Origin: https://www.example.com/' --head https://example.com/my-font.woff 

Som det fremgår af kommentarerne, ser din .htaccess-fil ud som om den umuligt kan fungere. Det Redirect 301 regel derinde er ubetinget, så det bør omdirigere enhver anmodning. Mit gæt er, at det slet ikke anvendes. Måske redigerer du den forkerte fil. Måske har du filnavnet forkert. Måske er du i den forkerte mappe. Det er også muligt, at Apache er konfigureret til ikke at bruge .htaccess. Apache giver filen mulighed for at have et andet navn, hvis der er konfigurationslignende AccessFileName '.config'. De er også deaktiveret som standard. Konfigurationen har brug for en AllowOverride direktiv indstillet til noget lignende All for til dit bibliotek.

  • Tak alle for de vidunderlige svar. Jeg har ikke længere fejlen. Problemet var i Chrome, men / Apache / 2.4.6 (CentOS) OpenSSL / 1.0.1e-fips PHP / 5.4.16-problemet. Fix: (fra ovenstående råd og hostingfirma) Jeg tog den originale kode ud i .htaccess og ringede til mit hostingfirma. De foreslog, at jeg bruger nedenstående kode til min fil, der løste fejlen: RewriteEngine On RewriteBase / RewriteCond% {HTTP_HOST} ^ www \. (. *) $ [NC] RewriteRule ^ (. *) $ Https: //% 1 / $ 1 [R = 301, L]
  • 1 Denne kode ser ud til at den bare omdirigerer andre domæner og underdomæner til dit hoveddomæne. Du har muligvis haft et problem med at ringe til skrifttyper ved hjælp af absolutte links på et domæne, der muligvis ikke matcher det aktuelle.

arbejdet for dig: Charles Robertson | Ønsker du at kontakte os?