Bonjour,
J’ai un problème avec une application.
En local tout marche mais sur l’environnement déployé j’ai une action
create qui ne fonctionne pas (j’ai une redirection vers ma page
d’index).
Voici ce que jai fait pour essayer de diagnostiquer.
- j’ai supprimé l’Ajax pour n’être qu’en pur HTML
- J’ai mis un logger.info sur la première ligne de l’action create et
je me rends compte que je n’y passe pas
- j’ai du coup supprimé le before_filter (qui me testait les
autorisations), mais le problème persiste
A priori il reste comme possibilité Restful_authentication qui est
appelé systématiquement (et que je ne peux pas supprimer facilement),
mais je ne vois pas pourquoi il y a une redirection sur l’index.
Un problème avec mes sessions?
A votre avis qu’est ce que j’ai pu oublier dans mon déploiement (fait
avec Webistrano/Capistrano) qui explique cette erreur.
Merci de votre aide
PS : je ne veux pas donner le lien sur cette liste (par superstition),
mais si quelqu’un veut voir ce que ça donne je peux lui envoyer l’url
par mail.
rake db:sessions:create a bien été fait sur le serveur quand tu déploie?
Non, mais je n’utilise pas les sessions en table mais en cokies
On Jan 17, 3:00 pm, Tony C. [email protected] wrote:
Tranquiliste wrote:
Non, mais je n’utilise pas les sessions en table mais en cokies
Que t’indique ton log? Si effectivement il y a redirection, tu dois voir
les 2 actions
Je vois les 2 actions “new” d’abord puis “index” sans passer par la
create
Un autre point a vérifer, la fonction redirect_back_or_default de
Restful_authentication te renvoi sur l’index si ton url de retour n’a
pas été mise en session via store_location
C’est ce qui me fait penser à un problème avec Restful_authentication.
Mais je ne vois pas pourquoi (le problème ne se produisant pas en
local)
–
Posted viahttp://www.ruby-forum.com/.
En fait tout se passe comme si le “post” n’était pas envoyé et donc,
c’était l’action index qui était executée et non pas create.
Tranquiliste wrote:
Non, mais je n’utilise pas les sessions en table mais en cokies
Que t’indique ton log? Si effectivement il y a redirection, tu dois voir
les 2 actions
Un autre point a vérifer, la fonction redirect_back_or_default de
Restful_authentication te renvoi sur l’index si ton url de retour n’a
pas été mise en session via store_location
Dans le log, tu peux voir si ton appel se fait en POST. Si
effectivement, tu n’as pas quelque chose du style :
Processing SessionsController#create (for 127.0.0.1 at 2009-01-17
00:47:16) [POST]
C’est que ton formulaire pose soucis.
On Jan 17, 3:16 pm, Guillaume B. [email protected]
wrote:
Je tente le truc tout con à 2 balles : il m’arrive régulièrement de ne
jamais passer dans le “create” apres un “new” : c’est que je n’ai pas
relancé le serveur après un migrate.
Je l’ai relancé après chaque déploiement. Via mon interface d’admin,
j’ai un bouton pour tuer le process fcgi.
Ce doit être un bête problème d’environnement, mais je n’arrive pas à
trouver.
Je tente le truc tout con à 2 balles : il m’arrive régulièrement de ne
jamais passer dans le “create” apres un “new” : c’est que je n’ai pas
relancé le serveur après un migrate.
gUI
–
Pour la santé de votre ordinateur, préférez les logiciels libres.
Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/
Browser le web : http://www.mozilla-europe.org/fr/products/firefox/
Suite bureautique : http://fr.openoffice.org/
On Jan 17, 3:17 pm, Tony C. [email protected] wrote:
Dans le log, tu peux voir si ton appel se fait en POST. Si
effectivement, tu n’as pas quelque chose du style :
Processing SessionsController#create (for 127.0.0.1 at 2009-01-17
00:47:16) [POST]
C’est que ton formulaire pose soucis.
C’est un peu ça le problème car le formulaire donne ça en local
Processing BuildingsController#create (for 127.0.0.1 at 2009-01-17
15:32:16) [POST]
Session ID:
BAh7CToOcmV0dXJuX3RvMDoMdXNlcl9pZGkGOgxjc3JmX2lkIiVhNTEwZmI1
ZDhlMmMzZTM0MjBjNjM1NmNmYTdlMTUxOSIKZmxhc2hJQzonQWN0aW9uQ29u
dHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA==–
b6dd4e4a55052f3ca9b1c203169b26e1e32d2552
Je vois bien le create [post]
et ça en prod
Processing BuildingsController#index (for 81.57.101.152 at 2009-01-17
15:22:48) [GET]
Session ID:
BAh7CToMY3NyZl9pZCIlZjI4YzU4MmZhOGY0OGE2MzdiN2JjZGFkMGQ2ZGJm
Yjc6DnJldHVybl90bzA6DHVzZXJfaWRpBiIKZmxhc2hJQzonQWN0aW9uQ29u
dHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsGOgtub3RpY2UiLUlsIG4neSBh
IHBhcyBkJ2ltbWV1YmxlIGF2ZWMgY2UgbnVtw6lyby4GOgpAdXNlZHsGOwlU–4f84c64f7564341c0de3658535aa5332236d3105
Parameters: {“action”=>“index”, “controller”=>“buildings”}
C’est index qui est exécuté et pas le create
Je continue mon diag mais toujours sans trouver.
Avec firebug activé, j’obtiens en local un :
POST Buildings avec un 200 ok
et en prod
POST buildings avec un 301 moved permanently
suivi d’un
GET buildings.
Donc apparemment il fait bien le post (bien que ça n’apparaisse pas
dans les logs) mais avec une redirection.
a part le log_level a :debug, quels sont les autres moyens de voir ce
qui se passe sur ce post?
Merci
Une nuit de réflexion ne m’a pas vraiment
aidé.
Toujours avec firebug, je vois que j’ai 3 fois le cookie
_monAppli_session avec des valeurs différentes alors qu’il n’y est
qu’une fois en local
Cookie
_NotreImmeuble_session=BAh7CToMY3NyZl9pZCIlNGQwZjA1MzVlZTRmZmFiM2E2NjRjMjJmOWM3ZjVk
%0AMDU6DnJldHVybl90bzA6DHVzZXJfaWRpBiIKZmxhc2hJQzonQWN0aW9uQ29u
%0AdHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA%3D
%3D–0356eb11bbc440d9a68ac9d4acaf3c13a502832e
;
_NotreImmeubleINT_session=BAh7CToMY3NyZl9pZCIlYzkyYjA5NTdlNzNkMjdhMDgwYzg4OTBjZWYzNTk2%0AMzA6DnJldHVybl90bzA6DHVzZXJfaWRpBiIKZmxhc2hJQzonQWN0aW9uQ29u
%0AdHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA%3D
%3D–0a031a03cd7d6639ae5bfd18ec80b83051ceed3a
;
NotreImmeublesession=BAh7CToMY3NyZl9pZCIlZTEyYWNmYjM3OWVhZGFjMWJiNzBlNmQ4OTc0ODFm
%0AZGE6DnJldHVybl90bzAiCmZsYXNoSUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZs
%0AYXNoOjpGbGFzaEhhc2h7AAY6CkB1c2VkewA6DHVzZXJfaWRpBg%3D
%3D–3f808c20225f331332b6fee17e68f41d8904c6a
7
Je n’arrive toujours à rien.Quel moyen j’ai pour faire du debug en
prod?
- Je vais risquer de dire une bétise mais tant pis :
Ton bug me rappelle confusément des déboires qui me sont arrivés en
débutant
un appli avec les sessions dans les cookies (défaut Rails actuel).
Je crois m’en être débarassé en repassant les sessions en DB.
(comme, pour être honnête, j’ai toujours pas capté l’avantage
incontournable
des cookies, ça me manque pas 
Ca mange pas pain d’essayer…
- A chaque fois qu’on observe une différence DEV/PROD il faut creuser
cette
même piste :
Qu’est-ce qui est rafraîchi à chaque requète en DEV mais pas en PROD et
qui
peut faire la différence ?
J’ai fait un test avec les sessions en base et ça ne marche toujours
pas
On Jan 18, 6:03 pm, “philippe lachaise” [email protected]
wrote:
Ca mange pas pain d’essayer…
C’est ce que je vais esayer de faire, mais j’avais cru comprendre que
c’était moins bien que les cookies (je ne sais plus pourquoi)
- A chaque fois qu’on observe une différence DEV/PROD il faut creuser cette
même piste :
Qu’est-ce qui est rafraîchi à chaque requète en DEV mais pas en PROD et qui
peut faire la différence ?
Je ne sais pas 
et c’est sans doute ça mon problème
Hello,
Ma modeste contribution, au cas où ça pourrait aider :
J’essayerais de comparer tous les fichiers sur le serveur de prod avec
ceux
qui sont en local.
Comparer les tailles déja, pour assurer que c’est pas un raté durant un
déploiement.
Autrement, ce genre de soucis me fait penser au routage…Mais je
n’explique
pas pourquoi ca marcherait en local et pas sur le serveur de prod.
2009/1/18 Tranquiliste [email protected]
A priori ce n’est pas un problème de fichier non déployés. J’ai fait
un déploiement “bestial” via ftp et j’ai la même erreur.
J’ai cependant une question, car une des différences est le freeze de
rails qui est en local comme je n’ai pas paramétré en local le
ENV[‘GEM_PATH’] = ‘#{current_path}/vendor/gems/’
Ce qui est executé c’est le rails installé en gem. Je vais voir ce que
ça donne.
On Jan 18, 11:47 pm, Tranquiliste [email protected]
wrote:
A priori ce n’est pas un problème de fichier non déployés. J’ai fait
un déploiement “bestial” via ftp et j’ai la même erreur.
J’ai cependant une question, car une des différences est le freeze de
rails qui est en local comme je n’ai pas paramétré en local le
ENV[‘GEM_PATH’] = ‘#{current_path}/vendor/gems/’
Je fatigue, ça n’a rien à voir
On Jan 18, 9:13 pm, “Frédéric Jay” [email protected] wrote:
Hello,
Ma modeste contribution, au cas où ça pourrait aider :
J’essayerais de comparer tous les fichiers sur le serveur de prod avec ceux
qui sont en local.
Comparer les tailles déja, pour assurer que c’est pas un raté durant un
déploiement.
Autrement, ce genre de soucis me fait penser au routage…Mais je n’explique
pas pourquoi ca marcherait en local et pas sur le serveur de prod.
Intéressant, j’ai regardé mon dossier vendor dans lequel j’ai freezé
rail et mes gems et il en fait que 7,5mo alors que en local il fait
27,2mo. Je me souviens que j’avais eu pas mal de problème avec mes
commit et que j’ai été obligé de m’y reprendre à plusieurs fois.
J’utilise svn avec Netbeans. Je vais regarder de ce côté.
Pour résumer,
En local ça marche mais pas sur l’environnement déployé (il sappelle
integration) et les principales différences/caractérisitiques sont
- je déploie avec Capistrano/Webistrano, mais j’ai aussi essayé de
faire un déploiement par ftp
- Sur intégration je peux créer un utilisateur, recevoir les mails
d’activation, me connecter, c’est quand je veux créer un des modèles
que j’ai une redirection sur l’action index du controleur (au lieu de
create)
- Même sans les before_filter, ça ne change rien
- j’utilise restful_authentication
- j’ai freezé rails mais ça a l’air de fonctionner en local (si j’ai
bien compris par defaut il va d’abord chercher dans vendor/rails)
- mon fichier environnement sur le site déployé est comme suit
ENV[‘RAILS_ENV’] ||= ‘integration’
ENV[‘GEM_PATH’] = ‘#{current_path}/vendor/gems/’
ENV[‘HOME’] = ‘/home/notreimmeuble/www/’
Specifies gem version of Rails to use when vendor/rails is not
present
RAILS_GEM_VERSION = ‘2.1.0’ unless defined? RAILS_GEM_VERSION
require File.join(File.dirname(FILE), ‘boot’)
Rails::Initializer.run do |config|
config.log_level = :debug
config.action_controller.session = {
:session_key => ‘_NotreImmeuble_session’,
:secret =>
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
}
config.active_record.observers = :user_observer
# Custom gem requirements
config.gem ‘mislav-will_paginate’, :version => ‘~> 2.3.3’,
:lib => “will_paginate”,
:source => ‘http://
gems.github.com’
config.gem ‘uuid’, :version => ‘~> 2.0.1’
config.gem ‘macaddr’, :version => ‘~> 1.0.0’
end
ExceptionNotifier.exception_recipients = %w([email protected])
- le fichier integration.rb du répertoire environments contient (j’ai
essayé d’activer tous les logs, pas de cache, …)
config.cache_classes = true
config.whiny_nils = true
Show full error reports and disable caching
config.log_level = :debug
config.action_controller.consider_all_requests_local = true
config.action_view.debug_rjs = true
config.action_controller.perform_caching = false
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
:address => “smtp.alwaysdata.com”,
:port => 25,
:domain => “notreimmeuble.alwaysdata.net”,
:authentication => :login,
:user_name => “[email protected]”,
:password => “xxxxxxxxxx”
}
config.action_mailer.default_charset = “utf-8”
- j’ai modifié les fichier dispacthc.fcgi et .htaccess comme indiqué
par mon hébergeur
- j’ai essayé de passer les sessions en base au lieu de cookie, mais
ça n’a rien changé
- j’ai essayé à partir d’un autre ordinateur et une autre adresse
Et là tout de suite je suis à sec et je ne vois toujours d’ou vient ce
redirect vers l’action index.