404 après deploy

Version imprimable

23/12/2010, 12h04
jejeman

404 après deploy

Bonjour,

Je viens de terminer (enfin la 1ère phase) mon projet et donc de le déployer en recette. J'utilise le plugin sfguard dans mon projet et j'ai 2 applications : front et back. Les 2 applis sont sécurisées avec le plugin.
En dev, pas de souci, tout marche.
En prod, la partie backend marche impec après authentification...
Par contre le front me fait "404 Not Found -- The requested URL /ogi/web/login was not found on this server." après avoir saisi mon login mot de passe et cliquer sur "envoyer"...
D'où ça peut venir ?
Merci de votre aide.
23/12/2010, 17h14
Michel Rotta

Vérifie si tu n'aurais pas protégé toute ton application y compris le formulaire de login.
27/12/2010, 12h12
jejeman

J'ai vérifié, elle n'est pas trop protégée...
De toute façon, je vois le formulaire de connexion, c'est quand je valide que ca me marque l'erreur...
Mais si c'était un problème de protection, j'aurais un message d'erreur dans ce sens et pas un 404....

J'ai poussé un peu plus mes investigations... ;)
Ca me fait la même chose en DEV si j'appelle la page index.php au lieu de frontend_dev.php...
Je creuse....
27/12/2010, 17h32
jejeman
J'ai trouvé !!!
En fait j'ai fait :
Code:

1 2 3 4 prod: .settings: no_script_name: false logging_enabled: false
le paramètre no_script_name était à true, je l'ai mis à false et c'est bon !!
Maintenant question subsidiaire, à quoi sert ce paramètre ?
Je vais chercher....
27/12/2010, 17h39
dourouc05

Citation:

Envoyé par jejeman

Maintenant question subsidiaire, à quoi sert ce paramètre ?

À afficher ou non le nom du script contrôleur. Quand no_script_name vaut false, on a des URL du genre
http://localhost/controleur.php/parametres
Sinon, on a
http://localhost/parametres
ce qui ne fonctionne correctement que si le contrôleur voulu est défini comme page d'index du répertoire (généralement index.php). C'ets ce qui t'arrivait, probablement : tous les paramètres étaient envoyés à index.php alors que c'était un autre script qui devait les recueillir et les traiter.
12/01/2011, 18h26
guiyomh

Bonjour,

j'ai exactement le même problème.
Lorsque j'utilise le www.mondomaine.loc/frontend_dev.php/ tout fonctionne nickel.
Mais dès que j'essaye de passé sur la version de production en saisissant www.mondomaine.loc/ j'arrive donc sur le formulaire de d'authen. Que je soumet avec les bon identifiants / password. Et je tombe sur une page d'erreur 404.

J'ai donc testé ta solution de mettre no_script_name à false. ça fonctionne j'arrive bien a accéder au site sauf que du coup toute mes urls se transforme en www.domaine.loc/index.php/mon-module/....
je trouve ça un peu disgracieux. J'aurais bien aimé avoir www.domaine.loc/mon-module/....

Ne faut t'il pas ajouter quelque règle de rewrite dans le virtualhost de la version de prod ? je trouve rien sur le site de symfony.
Je trouve ça bizzard.
13/01/2011, 09h33
Michel Rotta

Le problème provient d'apache et de sa configuration.

En effet c'est le module "mod_rewrite" qui prend en charge la réécriture de l'url et notamment le rajout de index.php dans celle-ci. Accessoirement, il prend aussi en charge le cache de bas niveau.

Quant on passe avec le contrôleur de dev, généralement "frontend_dev.php" il n'y a pas de besoins d'utiliser le "mod_rewrite", vu que l'url est viable.

L'activation du "mod_rewrite" se fait dans le ".htaccess" il faut donc veiller à ce qu'il soit pris en compte. Notamment, il doit, sous linux, être précéder d'un point et, sous windows, être en fichier caché.

Vérifier aussi que le module "mod_rewrite" soit bien actif dans apache.

Une fois cela fait, vous ne devriez plus avoir de problèmes.

Bonjour,

oui je suis d'accord, je suis pas expert, mais j'ai un peux d'expérience la dessus.
J'ai déjà essayer ce que tu as dis mais ça n'as pas fonctionner.

Pour info je suis sur un serveur ubuntu 10.10 config LAMP. Qui passe par un reverse proxy ngnix.
Au début je faisait les test avec le reverse proxy. Mais je me suis dis que c'est lui qui avais peut être un soucis. Donc maintenant j'attaque Apache en direct.

Mais j'ai le même soucis. Mais comme je le dis je suis pas expert en réécriture. ci dessous vous trouverez mon virtualhost apache. J'ai peut-être une coquille dedans :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 <VirtualHost *:80> ServerName www.warsa.local DocumentRoot "/home/gcamus/PROJETS/warsa/web" DirectoryIndex index.php <Directory "/home/gcamus/PROJETS/warsa/web"> AllowOverride All Allow from All </Directory> Alias /sf /home/gcamus/PROJETS/warsa/lib/vendor/symfony/data/web/sf <Directory "/home/gcamus/PROJETS/warsa/lib/vendor/symfony/data/web/sf"> AllowOverride All Allow from All </Directory> RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ index.php [NC,L] </VirtualHost>

13/01/2011, 10h10
Michel Rotta

Comme je l'ai dis plus haut,

Il faut vérifier que le .htaccess soit pris en compte et que le "mod_rewrite" soit chargé dans apache.

Si tu arrives à fonctionner avec le contrôleur frontend_dev.php c'est que la configuration pour accéder à ton site (proxy et apache donc virtuel) est bonne.

Bonjour le problème ne venais pas du mode rewrite non actif.
J'ai réussit à corrigé le problème en désactivant le .htaccess car je trouve ça pas nickel pour un server de prod.

pour infos voici mon virtual host :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
<VirtualHost *:80>
        ServerAdmin     me@local
        ServerName      www.warsa.loc
        DocumentRoot    /home/dtv/warsa/web
 
        DirectoryIndex  index.php index.htm index.html
 
        <Directory /home/admindtv/warsa/web>
                AllowOverride None
                Allow from All
        </Directory>
        Alias /sf /home/dtv/warsa/lib/vendor/symfony/data/web/sf
        <Directory /home/dtv/warsa/lib/vendor/symfony/data/web/sf>
                 AllowOverride None
                 Allow from All
         </Directory>
 
        ErrorLog /var/log/apache2/error-warsa.log
 
        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn
 
        CustomLog /var/log/apache2/access-warsa.log combined
 
        RewriteEngine On
 
        #Activation des log de réécriture (A activé au besoin)
        RewriteLog /var/log/apache2/rewrite-warsa.log
        RewriteLogLevel 9
 
        #suppression du path du reverse proxy
        RewriteCond %{REQUEST_URI} ^/warsa(.+)$
        RewriteRule ^/warsa(.+)?$ $1
 
        #réécriture vers l'index
        RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -s [OR]
        RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -l [OR]
        RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d
        RewriteRule ^.*$ - [NC,L]
 
        RewriteRule ^.*$ /index.php [NC,L]
 
</VirtualHost>

Alors pour infos je passe par un revers proxy ngnix car j'ai qu'un seul domaine. Mais pour gérer plusieurs site sur différente machine j'ai mis en place un petit proxy et du coup je peux me faire des url du genre www.mondomaine.com/warsa/
www.mondomaine.com/toto/
[...]

c'est pour ça que j'ai ces lignes de réécriture :

Code:

1
2
3
4
 
#suppression du path du reverse proxy
        RewriteCond %{REQUEST_URI} ^/warsa(.+)$
        RewriteRule ^/warsa(.+)?$ $1

il faudra surement les supprimer pour chez vous, si vous reprenez le VH.

cdt.

16/01/2011, 10h27
Michel Rotta

Là tu joues sur les mots.

Le fait reste que le problème venait de la non prise en compte des lignes de redirection qui sont, normalement, prise en compte dans le .htaccess avec symfony.

Tu as choisi de les déplacer dans le vhost, ce qui est un bon choix, et c'est bien leur activation qui a permis de faire fonctionner ton application.

Juste une remarque, ceci ne peut fonctionner que pour un serveur sur lequel on a la total maitrise et qui héberge peu de site. En effet, la modification d'un vhost implique d'avoir accès à ce même vhost (ce qui n'est pas le cas dans de nombreuses configurations d'hébergements mutualisés) et de rebooter apache, donc de stoper temporairement tous les sites hébergés sur le serveur. C'est pour cela que, dans la majorité des cas, l'utilisation du .htaccess reste à préconiser.
16/01/2011, 14h28
guiyomh
Non je joue pas sur les mots.
Le mod_rewrite était activé.

Le problème venait de la redirection vers l'index.php qui était comme ceci avant :

Code:

RewriteRule ^.*$ index.php [NC,L]

et que j'ai transformé en :

Code:

RewriteRule ^.*$ /index.php [NC,L]

avec un slash devant l'index, et tout à fonctionner.

Je m'en suis rendu compte en activant les log de réécriture avec :
Code:

1 2 3 #Activation des log de réécriture (A activé au besoin) RewriteLog /var/log/apache2/rewrite-warsa.log RewriteLogLevel 9
Log qui n'aurais pas fonctionner si le mod_rewrite n'avais pas été activer.
16/01/2011, 22h51
Michel Rotta

Je n'avais pas vu le "/" dans le lot de ligne.

Étonnant. Je n'ai jamais eu, ni vu cela.

On est bien d'accord que le fichier index.php est dans le dossier /home/dtv/warsa/web ?

Et que ton url fait bien référence à la racine. Ce qui semble le cas dans les exemples que tu as donnés.

Je ne vois qu'une explication, il y a un paramètre sur apache qui est particulier à ta configuration. Lequel ? Bonne question.

Reste que pour l'intérêt de positionner les informations de rewrite dans le vhost, je maintiens qu'elle sont très bien dans le .htaccess.