Bonjour, après avoir mis mon site en ligne j'ai rencontré un problème qui ne concerne seulement une de mes pages (un mini-chat). Lorsque je vais sur la page, que le debug mode soit off ou on j'ai un "403 access denied" qui semble être une version récente de l'erreur 505 access denied. J'ai tenté pleins de solutions trouvées sur google:

- Mettre les droits de tout mes dossiers et fichiers en 777 (je les ai remis en 755 après pas de panique)

- Vérifier si ça ne viens pas de ma connexion à la BDD (réponse: non car j'ai d'autres pages utilisant la BDD qui fonctionnent parfaitement)

- Vérifier si mes dossiers htacess ne sont pas corrompus en les copiant à l'exterieur et en les supprimant de l'arborescence, ce n'était pas ça, leur surpression n'a rien changé (je les ai remis ensuite)

Je suis un peu à cours d'idée sur ce coup, c'est une page de chat plutôt simple avec un formulaire pour l'entrée de message si l'utilisateur est connecté et un affichage des derniers messages (qu'il soit connecté ou non), on peut déjà éliminer la piste du formulaire car comme j'ai dis j'ai d'autres pages formulaires et la page bug aussi quand j'y vais sans être connecté (donc quand elle contient seulement l'affichage des messages)

La page marche bien en prod/dev sans mettre le site en ligne donc aucune chance que le problème vienne de mon code.. surtout que c'est un code très simple ou j'utilise le query builder pour récupérer les infos dans la BDD puis les afficher via une boucle twig

Hello,

c'est du Symfony ? du Php brut ? il y a des .haccess ? quelle est ta conf apache?

Attention, 

Tu confonds 403 et 505.

403 : Forbidden

La page que tu demandes t'es interdites, le serveur te lance un entête 403 et bloque la connexion. Là une analyse des droits d'accès aux dossiers / fichiers seraient nécessaires.

505 : HTTP version not supported

L'entête de version HTTP envoyée par ton navigateur n'est pas supportée par le serveur propulsant ton site. Il faut donc arriver à analyser les versions renvoyées par ton navigateur. Là dessus, je ne saurais pas trop d'aiguiller.

L'erreur qui m'est retournée n'est pas 403 Forbidden mais bien 403: Access Denied

L'erreur persiste même si les droits de tout les fichiers sont en 755 ou 777..

Access denied et forbidden sont identiques.

Peux-tu copier coller le .htaccess du dossier dans lequel se trouve le script à appeler, mais aussi les .htaccess des dossiers parents si il y en a ?

Et bien je travail sous Symfony donc de base je ne vois que deux .htacess, celui dans le dossier src:

<IfModule mod_authz_core.c>
    Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
</IfModule>

Et celui dans le dossier web:

# Use the front controller as index file. It serves as a fallback solution when
# every other rewrite/redirect fails (e.g. in an aliased environment without
# mod_rewrite). Additionally, this reduces the matching process for the
# start page (path "/") because otherwise Apache will apply the rewriting rules
# to each configured DirectoryIndex file (e.g. index.php, index.html, index.pl).
DirectoryIndex app.php

# By default, Apache does not evaluate symbolic links if you did not enable this
# feature in your server configuration. Uncomment the following line if you
# install assets as symlinks or if you experience problems related to symlinks
# when compiling LESS/Sass/CoffeScript assets.
# Options FollowSymlinks

# Disabling MultiViews prevents unwanted negotiation, e.g. "/app" should not resolve
# to the front controller "/app.php" but be rewritten to "/app.php/app".
<IfModule mod_negotiation.c>
    Options -MultiViews
</IfModule>

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Determine the RewriteBase automatically and set it as environment variable.
    # If you are using Apache aliases to do mass virtual hosting or installed the
    # project in a subdirectory, the base path will be prepended to allow proper
    # resolution of the app.php file and to redirect to the correct URI. It will
    # work in environments without path prefix as well, providing a safe, one-size
    # fits all solution. But as you do not need it in this case, you can comment
    # the following 2 lines to eliminate the overhead.
    RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
    RewriteRule ^(.*) - [E=BASE:%1]

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect to URI without front controller to prevent duplicate content
    # (with and without `/app.php`). Only do this redirect on the initial
    # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
    # endless redirect loop (request -> rewrite to front controller ->
    # redirect -> request -> ...).
    # So in case you get a "too many redirects" error or you always get redirected
    # to the start page because your Apache does not expose the REDIRECT_STATUS
    # environment variable, you have 2 choices:
    # - disable this feature by commenting the following 2 lines or
    # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
    #   following RewriteCond (best solution)
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
    RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

    # If the requested filename exists, simply serve it.
    # We only want to let Apache serve files and not directories.
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule ^ - [L]

    # Rewrite all other queries to the front controller.
    RewriteRule ^ %{ENV:BASE}/app.php [L]
</IfModule>

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /app.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule>

Mais comme je l'ai dis j'ai déjà essayé de supprimer ces deux dossiers pour vérifier leur importance et ça ne change absolument rien, donc ça m'étonnerais que le problème vienne de là, en plus, ce problème n'est présent que sur une seule page

Up, je vien de me remettre à bosser sur le problème après qq jours de pause et j'ai toujours pas trouvé de solution.. j'ai l'impression que ce problème est insoluble

On peut voir la tête de ta config de firewall symfony ?

et l'url de la page que tu requêtes

-
Edité par ukusan 26 juin 2018 à 20:15:00

Voici l'url (qui est similaire aux url de toutes les autres pages du site):

http://www.piano-passionnement.hebergratuit.net/web/chat

Je comprends pas ce que tu veut dire par config de firewall ?