Comment réparer 403 dans Apache intégré à Mac OS X?

J'essaie de définir un environnement local sur mon nouveau MacBook Air 13 ": Apache intégré avec mes propres DocumentRoot, PHP et MySQL. Je mets généralement à jour /etc/hostsjuste pour exécuter mes sites Web locaux avec un joli permalien:. local/examplePour les références, je vérifier:

• Comment transformer Mac OS X Lion en serveur Web?
• Activation d'Apache dans Mac OS X Mountaion Lion
• Autorisations Apache

Cette fois , je suis tout simplement obtenir un 403 Forbidden erreur chaque fois que je frappe 127.0.0.1, localhostou local. J'ai d'abord vu à travers le terminal qu'Apache et PHP sont en cours d'exécution (même si je ne peux pas afficher les pages PHP); puis j'ai mis à jour toutes les autorisations en fonction des autorisations Apache ; maintenant je suis désespéré. Voici les configurations Apache pertinentes:

• /etc/hosts( voir le fichier - ajouté une ligne)
• /etc/apache2/httpd.conf( voir le fichier - mis à jour le DocumentRoot)
• /etc/apache2/users/joao.conf( voir le fichier - créé ce fichier)
• /etc/apache2/extra/httpd-vhosts.conf( voir le fichier - mis à jour VirtualHost)

Il semble qu'Apache me refuse en quelque sorte l'accès à mon DocumentRoot(ce qui est d'ailleurs ~/Sites). Parce qu'il ~/Sitess'agit en fait d'un lien symbolique, j'ai ensuite essayé de mettre à jour DocumentRootavec les chemins suivants (tous pointant vers le même répertoire):

• ~/Sites
• /Users/joao/Sites
• /Users/joao/Dropbox/Workflow/Sites(le répertoire d' origine )

Lancer encore 403 . Des idées pour résoudre / déboguer cela?

Mise à jour rapide - voici à quoi /var/log/apache2/joao.pt-error_logressemble mon apparence:

[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

J'ai un alias spécifié dans le serveur OSX pointant vers un répertoire utilisateur. J'ai passé beaucoup de temps à chmodding et à jouer avec _www user, à ajouter des autorisations exécutables de manière récursive, à désinstaller macports et toutes sortes de choses essayant de faire fonctionner cela. Aucune idée pourquoi cela ne fonctionnait pas.

Finalement, je viens de cocher la case "dossier partagé" dans le Finder pour ce dossier, et cela a fonctionné , sur le domaine spécifié, avec php actif, comme je le voulais. : / ... donc c'était facile.

Je mets à jour vers macOSS Sierra , version 10.12

Je fais face au même problème, j'ai fait deux choses pour le corriger correctement. Voici mes approches.

1) Veuillez vérifier le fichier " /private/etc/apache2/extra/httpd-userdir.conf ". Changement

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

à

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

2) ** Et modifiez votre " /etc/apache2/httpd.conf"

changement

Options FollowSymLinks Multiviews

à

Options FollowSymLinks Multiviews Indexes

enfin votre racine de document ressemblera à ce qui suit,

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

3) Redémarrez apache

sudo apachectl restart

Toujours vous face au problème, veuillez vérifier comment configurer Apache dans macOS Sierra 10.12

Je règle généralement ce problème en définissant l'utilisateur Apache sur moi-même dans les environnements locaux et sur les machines où le seul utilisateur qui utilise Apache est moi. Dans /private/etc/apache2/httpd.conf, définissez Uservotre nom d'utilisateur _www, par exemple:

User _www

->

User joao

Et puis redémarrez Apache:

$ sudo apachectl restart

Étapes supplémentaires:

1. Si vous avez des sessions actives, elles donneront des erreurs d'autorisation car elles appartiennent toujours à _www. Les posséder:

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

Implications:

Après cela, Apache (et PHP et al.) Fonctionnera comme vous et obtiendra une autorisation de lecture / écriture pour tous les fichiers que vous avez une autorisation de lecture / écriture. Mais comme il ne s'agit que d'un environnement de développement local, cela ne devrait pas être un problème à moins que vous n'ayez pas de règles pour bloquer Apache dans votre pare - feu et laisser des fichiers douteux comme des explorateurs de fichiers, des shells, des scripts qui peuvent contenir des vulnérabilités exécutées sous Apache; dans ce cas, n'importe qui, y compris votre voisin wifi public dans un café, peut entrer http://<your IP>et faire tout ce que ces scripts lui permettent de faire.

En fait, vous devez empêcher cela indépendamment des scripts que vous exécutez ou même si vous ne définissez pas l'utilisateur Apache sur vous-même car vous ne voulez probablement pas que des étrangers aléatoires puissent voir le contenu de votre localhost.

La prévention:

1. Faites qu'Apache n'écoute que localhost. Encore une fois, dans httpd.conf:

   Listen 80
   

   ->

   Listen 127.0.0.1:80
   

   Et redémarrez Apache à nouveau:

   $ sudo apachectl restart
   

2. Désactivez Apache dans le pare-feu de l'application (notez que vous l'avez peut-être déjà désactivé si vous avez cliqué Denysi / quand il vous a été demandé lors de la première exécution d'Apache):

   1. Ouvrez System Preferences» Security & Privacy» Firewall.
   2. Cliquez sur l'icône de verrouillage en bas à gauche et entrez votre mot de passe si nécessaire.
   3. Activez le pare-feu s'il est désactivé.
   4. Cliquez Firewall Options.
   5. Cliquez sur le +bouton.
   6. Appuyez sur cmd ⌘+ ⇧ shift+ Get entrez /usr/sbin/httpdet cliquez Add(si httpdne s'affiche pas, vous pouvez le rechercher dans le terminal par which httpd)
   7. Dans la liste, cliquez httpdet sélectionnez Block incoming connections.
   8. Frappez OK.

   9. Rechargez le pare-feu:

      $ 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. Limitez PHP à la racine du document. Dans php.ini:

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

   ( /var/tmp/pour les sessions)

Utilisez les trois solutions pour vous protéger au cas où l'une d'entre elles serait désactivée pour une raison quelconque.

_{- Notez que comme ma langue active sur ma machine n'est pas l'anglais, sachez que le libellé peut être un peu différent (les options de menu et le libellé peuvent être différents quelle que soit la langue dans les différentes versions d'OS X).}

_{- Les lignes commençant par $doivent être saisies en ligne de commande (Terminal ou iTerm, etc.), avec les $supprimées.}

Je viens de résoudre mon problème en définissant des autorisations non seulement sur le DocumentRootrépertoire, mais également sur tous ses répertoires parents. Voilà comment je l'ai fait .

(13) Autorisation refusée

L'erreur 13 indique un problème d'autorisations du système de fichiers. Autrement dit, Apache s'est vu refuser l'accès à un fichier ou un répertoire en raison d'autorisations incorrectes. Cela n'implique généralement pas de problème dans les fichiers de configuration d'Apache.

Afin de servir des fichiers, Apache doit avoir l'autorisation appropriée accordée par le système d'exploitation pour accéder à ces fichiers. En particulier, l'utilisateur ou le groupe spécifié dans httpd.conf doit être capable de lire tous les fichiers qui seront servis et de rechercher le répertoire contenant ces fichiers, ainsi que tous les répertoires parents jusqu'à la racine du système de fichiers.

Les autorisations typiques sur un système de type Unix pour les ressources n'appartenant pas à l'utilisateur ou au groupe spécifié dans httpd.conf seraient 644 -rw-r - r-- pour les fichiers ordinaires et 755 drwxr-xrx pour les répertoires ou les scripts CGI. Vous devrez peut-être également vérifier les autorisations étendues (telles que les autorisations SELinux) sur les systèmes d'exploitation qui les prennent en charge.

Si vous exécutez la version 2.4, le code d'erreur AH peut vous donner plus d'informations ici.

• AH00132: les autorisations de fichier refusent l'accès au serveur
• AH00035: accès refusé car les autorisations de recherche sont manquantes sur un composant du chemin d'accès Un exemple

Disons que vous avez reçu l'erreur Autorisation refusée lors de l'accès au fichier /usr/local/apache2/htdocs/foo/bar.html sur un système de type Unix.

Vérifiez d'abord les autorisations existantes sur le fichier:

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

Réparez-les si nécessaire:

chmod 644 bar.html

Faites de même pour le répertoire et chaque répertoire parent (/ 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

Sur certains systèmes, l'utilitaire namei peut être utilisé pour rechercher des problèmes d'autorisations en répertoriant les autorisations le long de chaque composant du chemin:

namei -m /usr/local/apache2/htdocs/foo/bar.html Si votre système n'a pas namei, vous pouvez utiliser parsepath. Il peut être obtenu à partir d'ici.

Si toutes les autorisations standard sont correctes et que vous obtenez toujours une erreur Autorisation refusée, vous devez vérifier les autorisations étendues. Par exemple, vous pouvez utiliser la commande setenforce 0 pour désactiver SELinux et vérifier si le problème disparaît. Si tel est le cas, ls -alZ peut être utilisé pour afficher l'autorisation SELinux et chcon pour les corriger.

Dans de rares cas, cela peut être dû à d'autres problèmes, tels qu'un problème d'autorisations de fichiers ailleurs dans votre fichier apache2.conf. Par exemple, une directive WSGIScriptAlias ​​ne mappant pas sur un fichier réel. Le message d'erreur peut ne pas être précis sur le fichier illisible.

NE PAS mettre des fichiers ou des répertoires en mode 777, même "juste pour tester", même si "c'est juste un serveur de test". Le but d'un serveur de test est de bien faire les choses dans un environnement sûr, et non de s'en tirer mal. Tout ce qu'il vous dira, c'est si le problème vient des fichiers qui existent réellement.

Scripts CGI

Bien que l'autorisation de script CGI puisse sembler correcte, le binaire réel spécifié dans le shebang peut ne pas avoir les autorisations appropriées pour être exécuté. (Ou un répertoire sur son chemin, vérifiez avec namei comme expliqué ci-dessus.)

(13) Autorisation refusée: proxy: HTTP: la tentative de connexion à 127.0.0.1:8080 (localhost) a échoué

Cette erreur ne concerne pas vraiment les autorisations de fichiers ou quelque chose comme ça. Ce que cela signifie en réalité, c'est que httpd n'a pas été autorisé à se connecter à cette adresse IP et à ce port.

La cause la plus courante de cela est que SELinux ne permet pas à httpd d'établir des connexions réseau.

Pour le résoudre, vous devez modifier une valeur booléenne SELinux (qui persistera automatiquement lors des redémarrages). Vous pouvez également redémarrer httpd pour réinitialiser le proxy pro, bien que cela ne soit pas strictement requis.

# setsebool -P httpd_can_network_connect 1

Les étapes suivantes ont fonctionné pour moi sur High Sierra exécutant Apache 2.4

(Basé sur l'excellent tutoriel suivant: http://www.cgi101.com/book/connect/mac.html , mis à jour avec des étapes supplémentaires pour les différences de version)

1. Déplacez le fichier vers:

   /Library/WebServer/CGI-Executables
   

2. Vérifiez que le fichier dispose des autorisations d'exécution:

   ls -l  /Library/WebServer/CGI-Executables
   

   Sinon utiliser:

   chmod -x  /Library/WebServer/CGI-Executables/myfile.cgi
   

3. Décommentez les lignes suivantes dans /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. Modifiez également la strophe Répertoire "/ Library / WebServer / CGI-Executables" en:

   <Directory "/Library/WebServer/CGI-Executables">
    AllowOverride None
    Options ExecCGI
    Require all granted
   </Directory>
   

5. Redémarrez ensuite Apache:

   sudo apachectl -k restart
   

Presque avec chaque nouvelle version de macOS, les modifications seront perdues et vous devrez refaire le travail, et même faire différentes étapes pour le corriger. Votre meilleur ami sont les journaux Apache situés dans / var / log / apache2 / (/ var / log / apache2 / error_log)

J'utilisais les ACL pour définir les autorisations, en suivant les instructions de la section « Comment définir les autorisations de fichiers et de répertoires pour Apache sous Mac OS X », mais j'obtenais toujours:

[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

Puis j'ai lu " (13) Permission Denied " (lié à dans la réponse de João Ramos ) et j'ai essayé d'ajouter "execute" à l'ACL. Ça a marché.

Redémarrez votre ordinateur! Cela a fonctionné pour moi.

Mais tout d'abord, j'avais changé l'utilisateur sous apache pour moi-même (de _www), car il s'agit d'un environnement local / test. Donc, finalement, cela a quelque chose à voir avec les autorisations.

Redémarrez ensuite la machine, tout comme Windows;).

OP décrit un problème survenant en essayant de configurer un environnement de serveur Web local sur un Mac, en utilisant Apache, PHP et MySQL, avec un DocumentRoot personnalisé, et en mentionnant l'utilisation de VirtualHost (vhost). OP signale une erreur 403 interdite lors de l'accès à localhost.

Un article sur coolestguidesontheplanet décrit comment la configuration d'hôtes virtuels dans Apache provoque la "perte de l'hôte local". En d'autres termes, la cause première du problème de l'OP pourrait être une activation incomplète des vhosts.

"Une fois que [les hôtes virtuels sont] configurés, vous perdez votre ancienne racine de document précédemment dans / Library / WebServer / Documents ou accessible dans le navigateur à http: // localhost - vous obtenez une erreur interdite 403."

L'article continue en expliquant comment réparer localhost dans un environnement vhost.

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

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

Il explique également comment résoudre les «problèmes d'autorisations avec des choses comme les mises à jour et l'authentification» associées à «l'utilisation du dossier Utilisateurs / nom d'utilisateur / Sites pour les hôtes».

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/