Come risolvere 403 in Mac OS X integrato Apache?


25

Sto cercando di impostare un ambiente locale sul mio nuovo MacBook Air 13 ": Apache integrato con il mio DocumentRoot, PHP e MySQL. Di solito aggiorno /etc/hostssolo per gestire i miei siti Web locali con un permalink piuttosto:. local/examplePer riferimenti, di solito dai un'occhiata:

Questa volta sto semplicemente ottenere un Forbidden 403 di errore ogni volta mi ha colpito 127.0.0.1, localhosto local. Per prima cosa ho visto attraverso il terminale che sia Apache che PHP sono in esecuzione (anche se non riesco a visualizzare le pagine PHP); quindi ho aggiornato tutte le autorizzazioni in base alle autorizzazioni di Apache ; ora sono solo disperato. Ecco le configurazioni di Apache rilevanti:

Sembra che Apache in qualche modo mi stia negando l'accesso al mio DocumentRoot(che tra l'altro è ~/Sites). Perché in ~/Sitesrealtà è un collegamento simbolico, ho quindi provato ad aggiornare DocumentRootcon i seguenti percorsi (tutti puntando alla stessa directory):

  • ~/Sites
  • /Users/joao/Sites
  • /Users/joao/Dropbox/Workflow/Sites(la directory originale )

Lancio ancora 403 . Qualche idea su come risolvere / eseguire il debug?

Aggiornamento rapido : ecco /var/log/apache2/joao.pt-error_logcome appare il mio :

[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to / denied
[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:47 2013] [error] [client ::1] (13)Permission denied: access to / denied
[Sun Jul 07 12:50:47 2013] [error] [client ::1] (13)Permission denied: access to / denied
[Sun Jul 07 12:50:48 2013] [error] [client ::1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:48 2013] [error] [client ::1] (13)Permission denied: access to /favicon.ico denied

Risposte:


19

Ho un alias specificato nel server OSX che punta a una directory utente. Ho passato molto tempo a fare confusione e scherzare con l'utente di _www, aggiungendo permessi eseguibili in modo ricorsivo, disinstallando macport e ogni sorta di cose cercando di farlo funzionare. Non ho idea del perché non funzionasse.

Alla fine, ho appena spuntato la casella di controllo "cartella condivisa" nel Finder per quella cartella, e ha funzionato , sul dominio specificato, con php attivo, come volevo. : / ... così è stato facile.


Non ha funzionato per me. Ho creato una cartella /Sites(nella mia /cartella principale ) e ho messo i miei file lì, configurando le opzioni Alias ​​e Directory di conseguenza. Ha funzionato bene.
jpenna,

11

Aggiornamento a macOSS Sierra , versione 10.12

Devo affrontare lo stesso problema, ho fatto due cose per risolverlo correttamente. Di seguito sono i miei approcci.

1) Controllare il file " /private/etc/apache2/extra/httpd-userdir.conf ". Modificare

#Include /private/etc/apache2/users/*.conf

a

Include /private/etc/apache2/users/*.conf

2) ** E modifica il tuo " /etc/apache2/httpd.conf"

modificare

Options FollowSymLinks Multiviews

a

Options FollowSymLinks Multiviews Indexes

infine la tua radice del documento sarà simile alla seguente,

DocumentRoot "/Library/WebServer/Documents"
<Directory "/Library/WebServer/Documents">
Options FollowSymLinks Multiviews Indexes
MultiviewsMatch Any
AllowOverride All
Require all granted

3) Riavvia apache

sudo apachectl restart

Stai ancora affrontando il problema, controlla gentilmente come configurare Apache in macOS Sierra 10.12


9

In genere risolvo questo problema impostando l'utente Apache su me stesso negli ambienti locali e nelle macchine in cui l'unico utente che utilizza Apache sono io. In /private/etc/apache2/httpd.conf, imposta il Usertuo nome utente da _www, ad esempio:

User _www

->

User joao

E quindi riavviare Apache:

$ sudo apachectl restart

Passaggi aggiuntivi:

  1. Se hai sessioni attive, queste daranno errori di autorizzazione poiché sono ancora di proprietà di _www. Possederli:

    $ sudo chown joao: /var/tmp/sess_*
    

implicazioni:

Successivamente, Apache (e PHP et al.) Funzioneranno come te e otterranno l'autorizzazione in lettura / scrittura per tutti i file che hai l'autorizzazione in lettura / scrittura. Ma poiché si tratta solo di un ambiente di sviluppo locale, ciò non dovrebbe costituire un problema a meno che non si disponga di regole per bloccare Apache nel firewall e consentire l'esecuzione di file discutibili come esploratori di file, shell, script che potrebbero contenere vulnerabilità in Apache; nel qual caso chiunque, incluso il tuo vicino wifi pubblico in un bar, può entrare http://<your IP>e fare qualunque cosa gli script gli facciano fare.

In effetti, dovresti impedirlo indipendentemente dagli script che esegui o anche se non imposti l'utente Apache su te stesso poiché probabilmente non vuoi che gli estranei casuali siano in grado di vedere il contenuto del tuo localhost.

Prevenzione:

  1. Fai in modo che Apache ascolti solo localhost. Ancora una volta, in httpd.conf:

    Listen 80
    

    ->

    Listen 127.0.0.1:80
    

    E riavvia nuovamente Apache:

    $ sudo apachectl restart
    
  2. Disabilita Apache nel firewall dell'applicazione (tieni presente che potresti averlo disabilitato se hai fatto clic Denyse / quando ti è stato chiesto durante la prima esecuzione di Apache):

    1. Apri System Preferences» Security & Privacy» Firewall.
    2. Fai clic sull'icona del lucchetto in basso a sinistra e inserisci la password, se necessario.
    3. Attiva il firewall se è disabilitato.
    4. Fare clic Firewall Options.
    5. Fai clic sul +pulsante
    6. Premi cmd ⌘+ ⇧ shift+ Ge inserisci /usr/sbin/httpde fai clic Add(Se httpdnon viene visualizzato lì, puoi cercarlo nel terminale vicino which httpd)
    7. Nell'elenco fare clic httpde selezionare Block incoming connections.
    8. Hit OK.
    9. Ricarica il firewall:

      $ launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
      $ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist
      $ launchctl load /System/Library/LaunchAgents/com.apple.alf.useragent.plist
      $ sudo launchctl load /System/Library/LaunchDaemons/com.apple.alf.agent.plist
      
  3. Limita PHP alla radice del documento. In php.ini:

    open_basedir = /Users/joao/Sites/:/var/tmp/
    

    ( /var/tmp/è per sessioni)

Utilizzare tutte e tre le soluzioni per proteggersi nel caso in cui una di esse venga disabilitata per qualche motivo.

- Si noti che, poiché la mia lingua attiva nella mia macchina non è l'inglese, lo so, la formulazione potrebbe essere leggermente diversa (le opzioni di menu e la formulazione possono essere diverse a prescindere dalla lingua in varie versioni di OS X).

- Le righe che iniziano con $devono essere inserite nella riga di comando (Terminale, iTerm ecc.), Con la $rimozione.


5

Ho appena risolto il mio problema impostando le autorizzazioni non solo per la DocumentRootdirectory, ma anche per tutte le sue directory principali. È così che l'ho fatto .

(13) Autorizzazione negata

L'errore 13 indica un problema con le autorizzazioni del filesystem. Cioè, ad Apache è stato negato l'accesso a un file o una directory a causa di autorizzazioni errate. In generale, non implica un problema nei file di configurazione di Apache.

Per poter servire i file, Apache deve avere le autorizzazioni appropriate concesse dal sistema operativo per accedere a quei file. In particolare, l'utente o il gruppo specificato in httpd.conf deve essere in grado di leggere tutti i file che verranno serviti e di cercare nella directory contenente tali file, insieme a tutte le directory principali fino alla radice del filesystem.

Le autorizzazioni tipiche su un sistema simile a unix per le risorse non di proprietà dell'utente o del gruppo specificate in httpd.conf sarebbero 644 -rw-r - r-- per i file ordinari e 755 drwxr-xrx per directory o script CGI. Potrebbe anche essere necessario controllare le autorizzazioni estese (come le autorizzazioni SELinux) sui sistemi operativi che le supportano.

Se si esegue 2.4, il codice di errore AH potrebbe fornire ulteriori informazioni qui.

  • AH00132: le autorizzazioni dei file negano l'accesso al server
  • AH00035: accesso negato perché mancano le autorizzazioni di ricerca su un componente del percorso Un esempio

Diciamo che hai ricevuto l'errore di autorizzazione negata quando accedi al file /usr/local/apache2/htdocs/foo/bar.html su un sistema simile a unix.

Innanzitutto controlla le autorizzazioni esistenti sul file:

cd /usr/local/apache2/htdocs/foo
ls -l bar.htm

Riparali se necessario:

chmod 644 bar.html

Quindi fai lo stesso per la directory e ciascuna directory principale (/ usr / local / apache2 / htdocs / foo, / usr / local / apache2 / htdocs, / usr / local / apache2, / usr / local, / usr):

ls -la
chmod +x .
cd ..
# repeat up to the root

Su alcuni sistemi, l'utilità namei può essere utilizzata per trovare problemi di autorizzazioni elencando le autorizzazioni lungo ciascun componente del percorso:

namei -m /usr/local/apache2/htdocs/foo/bar.html Se il tuo sistema non ha namei, puoi usare parsepath. Può essere ottenuto da qui.

Se tutte le autorizzazioni standard sono corrette e si continua a ricevere un errore Autorizzazione negata, è necessario verificare le autorizzazioni estese. Ad esempio è possibile utilizzare il comando setenforce 0 per disattivare SELinux e verificare se il problema scompare. In tal caso, ls -alZ può essere usato per visualizzare i permessi di SELinux e chcon per risolverli.

In rari casi, ciò può essere causato da altri problemi, ad esempio un problema di autorizzazioni dei file altrove nel file apache2.conf. Ad esempio, una direttiva WSGIScriptAlias ​​che non esegue il mapping a un file effettivo. Il messaggio di errore potrebbe non essere preciso su quale file era illeggibile.

NON impostare file o directory sulla modalità 777, anche "solo per testare", anche se "è solo un server di prova". Lo scopo di un server di prova è di sistemare le cose in un ambiente sicuro, non di farle sbagliare. Tutto ciò che ti dirà è se il problema riguarda i file che esistono effettivamente.

Script CGI

Sebbene l'autorizzazione dello script CGI possa sembrare corretta, il file binario specificato nello shebang potrebbe non disporre delle autorizzazioni appropriate per essere eseguito. (O qualche directory sul suo percorso, controlla con namei come spiegato sopra.)

(13) Autorizzazione negata: proxy: HTTP: tentativo di connessione a 127.0.0.1:8080 (localhost) non riuscito

Questo errore non riguarda le autorizzazioni per i file o qualcosa del genere. Ciò che effettivamente significa è che a httpd è stata negata l'autorizzazione a connettersi a quell'indirizzo IP e quella porta.

La causa più comune di ciò è SELinux che non consente a httpd di effettuare connessioni di rete.

Per risolverlo, è necessario modificare un valore booleano SELinux (che persisterà automaticamente al riavvio). È inoltre possibile riavviare httpd per ripristinare il proxy worker, sebbene ciò non sia strettamente necessario.

# setsebool -P httpd_can_network_connect 1


1
Potresti riassumere i punti di base nella tua risposta? Grazie!
Matt

2
Concedere l'accesso a tutta la sua directory padre sarebbe un'enorme violazione della sicurezza!
Julian F. Weinert,

1
Questa risposta non è utile. La soluzione alternativa funziona con macchine / configurazioni linux. OSX ha una struttura di directory diversa, specialmente per apache (che si trova in / Library / WebServer) la soluzione fornita non è per OSx, come fa apple.stackexchange.
Juan,

3

I seguenti passaggi hanno funzionato per me su High Sierra con Apache 2.4

(Basato sul seguente eccellente tutorial: http://www.cgi101.com/book/connect/mac.html , aggiornato con passaggi aggiuntivi per le differenze di versione)

  1. Sposta il file in:

    /Library/WebServer/CGI-Executables
    
  2. Verifica che il file disponga delle autorizzazioni di esecuzione:

    ls -l  /Library/WebServer/CGI-Executables
    

    In caso contrario utilizzare:

    chmod -x  /Library/WebServer/CGI-Executables/myfile.cgi
    
  3. Rimuovi il commento dalle seguenti righe in /etc/apache2/httpd.conf

    AddHandler cgi-script .cgi .pl
    
    AddType text/html .shtml
    AddOutputFilter INCLUDES .shtml
    
    LoadModule cgi_module libexec/apache2/mod_cgi.so
    
  4. Modificare anche la stanza della directory "/ Library / WebServer / CGI-Executables" in:

    <Directory "/Library/WebServer/CGI-Executables">
     AllowOverride None
     Options ExecCGI
     Require all granted
    </Directory>
    
  5. Quindi riavviare Apache:

    sudo apachectl -k restart
    

Quasi con ogni nuova versione di macOS, le modifiche andranno perse e dovrai rifare il lavoro e persino fare diversi passaggi per risolverlo. I tuoi migliori amici sono i log di Apache che si trovano in / var / log / apache2 / (/ var / log / apache2 / error_log)


1
Non una risposta ma un'osservazione. Istruzione n. 1 sopra: sposta il file in: quale file?
Pam,

0

Stavo usando gli ACL per impostare le autorizzazioni, seguendo le istruzioni in " Come impostare le autorizzazioni per file e directory per Apache su Mac OS X ", ma continuavo a ottenere:

[Wed Feb 12 15:43:51 2014] [error] [client ::1] (13)Permission denied: access to /trace/trace.php denied (filesystem path '/Library/WebServer/Documents/trace/trace.php') because search permissions are missing on a component of the path

Poi ho letto " (13) Autorizzazione negata " (collegato alla risposta di João Ramos ) e ho provato ad aggiungere "esegui" all'ACL. Ha funzionato


0

Riavvia il tuo computer! Questo ha funzionato per me.

Ma prima di tutto avevo cambiato l'utente sotto apache a me stesso (da _www), poiché si tratta di un ambiente locale / di test. Quindi alla fine ha qualcosa a che fare con le autorizzazioni.

Quindi riavviare la macchina, proprio come Windows;).


0

OP descrive un problema che si presenta durante il tentativo di configurare un ambiente di server Web locale su un Mac, utilizzando Apache, PHP e MySQL, con un DocumentRoot personalizzato e includendo una menzione dell'utilizzo di VirtualHost (vhost). OP segnala un errore 403 proibito durante l'accesso a localhost.

Un articolo su coolestguidesontheplanet descrive come la configurazione di host virtuali in Apache provoca "Perdita di Localhost". In altre parole, la causa principale del problema del PO potrebbe essere un'abilitazione incompleta dei vhosts.

"Una volta impostato [host virtuali], si perde la radice del documento precedente in precedenza in / Library / WebServer / Documents o si accede nel browser all'indirizzo http: // localhost - viene visualizzato un errore 403 proibito."

L'articolo continua spiegando come riparare localhost in un ambiente vhost.

Add these lines to file /etc/apache2/extra/httpd-vhosts.conf:

   <VirtualHost *:80> 
   ServerName localhost 
   DocumentRoot /Library/WebServer/Documents/ 
   </VirtualHost>

Spiega anche come risolvere "problemi di autorizzazioni con elementi come aggiornamenti e autenticazione" associati a "utilizzo della cartella Users / username / Sites per vhosts".

Instead of using the default UID _www, use your own User and Group.

In the terminal, enter command 

    id

Find your UID and GID. 
Update file httpd.conf
In section <IfModule unixd_module>
Change User and Group to your local UID and GID.

https://coolestguidesontheplanet.com/set-virtual-hosts-apache-mac-osx-10-10-yosemite/


La ringrazio per la risposta. :) Sfortunatamente, risposte brevi come questa non forniscono dettagli o contesti sufficienti per aiutare molti utenti. Invece, potresti modificare la tua risposta per includere un riepilogo del contenuto a cui stai collegando? Ciò renderà la tua risposta più autonoma e contribuirà a preservarla per altri utenti in futuro.
Monomeeth

Grazie, Monomeeth. Apprezzo il feedback. Aggiornato la risposta.
BobK77,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.