Defect #3969
closed
Plugins loaded before config/initializers/session_store.rb ?
0%
Description
This bug is related to issue #2815, and applies to redmine trunk with rails 2.2.3, before rails 2.3 migration.
The cookie session name has the default value (session_id) with BotsFilter plugin,
and the right value (_redmine_session) without.
How to reproduce :
- login to redmine, installed without plugins
- check which cookies are defined in your browser for that domain,
you should see "_redmine_session"
- logout
- stop redmine, install the BotsFilter plugin, restart redmine
- login again
- now the cookie name is _session_id, not _redmine_session.
Updated by Jérémy Lal about 15 years ago
ActionController is loaded by BotsPlugin, before
session_store.rb sets ActionController::Base.session, that's why
it has no effect.
I can't find a way around this...
Updated by Jérémy Lal about 15 years ago
- Assignee set to Jean-Philippe Lang
this seems to be a BotsPlugin issue...
Updated by Jan Wagner about 15 years ago
In production.log:
/!\ FAILSAFE /!\ 05/10/2009
Status: 500 Internal Server Error
A secret is required to generate an integrity hash for cookie session data. Use config.action_controller.session = { :session_key => "_myapp_session", :secret => "some secret phrase of at least 30 characters" } in config/environment.rb
The problem also occures also at least with: redmine_code_review and redmine_local_avatars
Updated by Jérémy Lal about 15 years ago
Adding config.action_controller.session to config/environment.rb would fix this problem,
but it is not consistent with
rake config/initializers/session_store.rb
which is a good way of generating the secret key.
It also hides other (potentially) similar situations with the other files in config/initializers/
I found a working solution, however it can't be applied to any plugin, only those where predefining
a singleton is NOT what is wanted :
mv vendor/plugins/redmine-botsfilter-1.00/init.rb config/initializers/z-plugins/redmine_bots_filter.rb
z-plugins dirname is to make sure plugin initialization happens after every other initializer.
Updated by Jean-Philippe Lang about 15 years ago
- Status changed from New to Closed
- Resolution set to Wont fix
This is not reproductible with latest trunk and Rails 2.3.4.