alchemycms / alchemy-devise Goto Github PK

I'm afraid the bug still exists. I have installed Alchemy exactly as instructed and received undefined method 'ssl_required' at http://localhost:3000. Then I created a user at http://localhost:3000/admin/signup and everything worked until I logged out. After that I received the following error messages.
http://localhost:3000: Alchemy::Page not found "/"
http://localhost:3000/admin/login: undefined method `ssl_required?

Originally posted by @AnniMel in https://github.com/AlchemyCMS/alchemy-devise/issue_comments/679072637

After upgrading AlchemyCMS, this can be seen in the admin backend.

It should be a person instead of a module.

Currently, I have forked the branch and clone to my machine. Getting some errors on testing and would love a quick start portion in the readme.

This may or may not be an "issue" with Alchemy-devise; excuse my limited knowledge of devise here.

But for our application, which we're slowly upgrading to latest alchemy gems, we hit upon a surprise in Alchemy 4.5

We are using SAML, and the devise_saml_authenticatable gem, which means we end up defining our own routes to the saml controller this provides, but use the devise_for :users statement in our routes files.

After the upgrade to 4.5, we found users being logged in were getting returned to the root_path (/) rather than the alchemy dashboard.

After some digging, it was found the reason for this was in the method https://github.com/heartcombo/devise/blob/main/lib/devise/controllers/helpers.rb#L169-L186

This method uses the scope (user) to construct a path name (user_root_path) which used to be defined in Alchemy-devise 4.4

But after the upgrade to Alchemy 4.5, this gets moves into the admin namespace, which means it gets renamed to admin_user_root_path - and so devise can't find user_root_path and falls back to root_path

Our workaround is to use a different devise scope name (:saml_user) and define saml_user_root_path ourselves, which perhaps is more of an indication we aren't using this gem for it's full purpose and a reflection of our usage. But equally, given the issue came from devise (not explictly the SAML gem) I was surprised this renaming of the user path helpers didn't affect other users of this gem, so wanted to raise it?

As I say, more likely my lack of familiarity with these gems than a real issue, but would appreciate any feedback, and thought it still worth raising in case the change of route naming wasn't deliberate (although given the age of v4.5+, I think it's very likely to not be an issue!)

On a number of machines during a workshop, we experienced Undefined method: 'ssl_required'. Could this be due to this commit 6f694ab ?

When we set Alchemy.login_path and Alchemy.logout_path we do not take Alchemy::MountPoint into account.

If one mounts Alchemy at /cms and wants to log into admin, Alchemy redirects to /admin/login, not /cms/admin/login.

We should change that to "#{Alchemy::MountPoint.get}/admin/login".

all other pages seem to redirect to the home page but viewing all users seems to work if the url is typed in manually. It does not look like this is intended.
Using 4.0 master.

Currently, the gem is not compatible with the latest stable release of Alchemy. I understand that the only reason for this is that the current master has not been released to RubyGems. Could you release it?

I actually have another issue (coming up!), but in order to provide a PR, I'd like to be able to run the current tests, but I can't. This is what happens:

$ rake alchemy:spec:prepare
[Migrations...]

/home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/configuration.rb:37:in `pwd': No such file or directory - getcwd (Errno::ENOENT)
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/configuration.rb:37:in `project_root_path'
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/configuration.rb:28:in `application_root_path'
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/application.rb:246:in `loaded_application_features'
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/application.rb:105:in `ensure in preload'
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/application.rb:112:in `preload'
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/application.rb:143:in `serve'
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/application.rb:131:in `block in run'
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/application.rb:125:in `loop'
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/application.rb:125:in `run'
    from /home/anselm/.rvm/gems/ruby-2.1.1/gems/spring-1.2.0/lib/spring/application/boot.rb:18:in `<top (required)>'
    from /home/anselm/.rvm/rubies/ruby-2.1.1/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /home/anselm/.rvm/rubies/ruby-2.1.1/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from -e:1:in `<main>'

When I remove spring from the Gemfile, the task runs through, but the tests don't run:

$ rspec
/home/anselm/.rvm/gems/ruby-2.1.1/gems/activerecord-4.1.9/lib/active_record/migration.rb:389:in `check_pending!':  (ActiveRecord::PendingMigrationError)

Migrations are pending. To resolve this issue, run:

    bin/rake db:migrate RAILS_ENV=test
...

When I run the migrations, I get a duplicate migration error. That's a bit frustrating...

Hello

Something I've noticed just now. I'm going to use Rails 5.2 for now, but I thought you might like to know.

Steps to reproduce

• Create a rails 6.0.0 app with rails new
• Follow https://github.com/AlchemyCMS/alchemy_cms/tree/4.3-stable using the following lines in Gemfile when prompted by the guide:
  • gem 'alchemy_cms', github: 'AlchemyCMS/alchemy_cms', branch: '4.3-stable'
  • gem 'alchemy-devise', github: 'AlchemyCMS/alchemy-devise', branch: '4.3-stable'

Expected behavior

When running bin/rake alchemy_devise:install:migrations, the generator should succeed.

Actual behavior

An error spoils the fun (this is not the case when using latest Rails 5.2 and performing the same steps):

usr/local/bundle/gems/zeitwerk-2.2.0/lib/zeitwerk/loader/callbacks.rb:17:in `on_file_autoloaded': expected file /usr/local/bundle/bundler/gems/alchemy-
devise-63797cf129ae/app/controllers/alchemy/base_controller_extension.rb to define constant Alchemy::BaseControllerExtension, but didn't (NameError)

System configuration

• Alchemy / alchemy-devise from GitHub, branch 4.3-stable
• Rails Version: 6.0.0
• Ruby: 2.6.3p62

@tvdeyen I tried to add more devise modules in an engine but it didn't worked

# engines/engine_name/app/models/user_extension.rb

Alchemy::User.module_exec do
  Alchemy::User::DEVISE_MODULES.push(:confirmable)
end

Can you tell me if this is the right approach or how it should be done.

Thanks it advance

I know Alchemy for rails 6 is unstable and under development, however I believe this module is not compatible.

I managed to successfully set everything up and create an account, however now that my session has expired I am getting the following:

undefined local variable or method `current_alchemy_user' for #<Alchemy::Admin::UserSessionsController:0x00000000018e70>

I never did run rails g alchemy:devise:install, that task does not exist. I assume this is what is going on. Does rails g alchemy:install create the default devise tables? Given that I have them.

As I have upgraded my rails 3.2/ devise app to rails 4.03, I have installed alchemy-cms 3.0 & alchemy-devise, I get this error when try to sign in:

ActiveModel::MassAssignmentSecurity::Error in Devise::SessionsController#create
Can't mass-assign protected attributes for Alchemy::User: password

Can you please tell me how to solve this problem?

Edit:

I think that the problem is that I am not extending User at your gem?
Currently my User model extends ActiveRecord::Base like:

class User <  ActiveRecord::Base

So, what shall it be?

Edit:

My pre-existing project has already devise installed and working, I installed Alchemy-CMS, but my User is already set and has custom methods at my app, how can I integrate my app User into this gem User?

The latest version released to rubygems is 2.1.0, also the readme links to a non existing 3.2.0 on rubygems.

Could you please release the current version to rubygems?

The new generator moves the devise initializer to your host app and generate a new secret token and pepper in that new initializer. This new thing broke login on an installation I had - all the passwords already in the database couldn't be verified anymore, resulting in users not being able to log in.

I see two paths around this:

1. (not that elegant) move the tokens in the template all the way to the top and add a comment saying: delete these lines if you're upgrading from a previous version of alchemy-devise so your passwords keep on working
2. (more elegant) have a generator alchemy:devise:upgrade that does all the necessary stuff but does not generate new tokens, but warns the user of a possible security risk because the old initializer did not have salt and pepper

What do you think?

Made an update alchemy cms (v3.0.0rc4) / alchemy-devise (2.0.0rc1)

Get this error when i try to open the user module

 NoMethodError undefined method `link_to_confirmation_window' 
   /alchemy-devise/app/views/alchemy/admin/users/_user.html.erb:15

Regards Thomas

Security issue from Hakiri: A security bug (CVE-2015-8314) has been reported in Devise’s remember me system.Devise implements the “Remember me” functionality by using cookies. While this functionality works across multiple devices, Devise ended-up generating the same cookie for all devices. Consequently, if a malicious user was able to steal a remember me cookie, the cookie could be used to gain access to the application indefinitely unless the user changed his password (which may not be a frequent event).Although all Devise versions are vulnerable to this bug, the bug can only be exploited if the attacker can steal cookies in the first place. Regardless, we recommend all users to upgrade to the latest Devise version.Devise 3.5.4 has been released with a fix. This release adds a timestamp to the cookie, guaranteeing cookies can be expired on a case-by-case basis instead of an all or nothing approach.

Dear Alchemy Team,

I can't log into my production site because of ssl_required? not being defined. Strangely, this does not happen in the development environment. Where does that method come from? What's happening?

Log:

I, [2015-05-03T14:32:15.673792 #16797]  INFO -- : Started GET "/admin/login" for 37.120.87.253 at 2015-05-03 14:32:15 +0200
I, [2015-05-03T14:32:15.675759 #16797]  INFO -- : Processing by Alchemy::UserSessionsController#new as HTML
I, [2015-05-03T14:32:15.683792 #16797]  INFO -- : Completed 500 Internal Server Error in 8ms (ActiveRecord: 0.0ms)
F, [2015-05-03T14:32:15.698341 #16797] FATAL -- : 
NoMethodError (undefined method `ssl_required?' for #<Alchemy::UserSessionsController:0x007f2ad0f10a20>):
  /var/www/virtual/htholen/rails/ptw/shared/bundle/ruby/2.2.0/bundler/gems/alchemy-devise-9acd927cc1e5/app/controllers/alchemy/user_sessions_controller.rb:6:in `block in <class:UserSessionsController>'
  activesupport (4.2.1) lib/active_support/callbacks.rb:446:in `instance_exec'
  activesupport (4.2.1) lib/active_support/callbacks.rb:446:in `block in make_lambda'
  activesupport (4.2.1) lib/active_support/callbacks.rb:145:in `call'
  activesupport (4.2.1) lib/active_support/callbacks.rb:145:in `block in halting_and_conditional'
  activesupport (4.2.1) lib/active_support/callbacks.rb:504:in `call'
  activesupport (4.2.1) lib/active_support/callbacks.rb:504:in `block in call'
  activesupport (4.2.1) lib/active_support/callbacks.rb:504:in `each'
  activesupport (4.2.1) lib/active_support/callbacks.rb:504:in `call'
  activesupport (4.2.1) lib/active_support/callbacks.rb:92:in `_run_callbacks'
  activesupport (4.2.1) lib/active_support/callbacks.rb:776:in `_run_process_action_callbacks'
  activesupport (4.2.1) lib/active_support/callbacks.rb:81:in `run_callbacks'
  actionpack (4.2.1) lib/abstract_controller/callbacks.rb:19:in `process_action'
  actionpack (4.2.1) lib/action_controller/metal/rescue.rb:29:in `process_action'
  actionpack (4.2.1) lib/action_controller/metal/instrumentation.rb:32:in `block in process_action'
  activesupport (4.2.1) lib/active_support/notifications.rb:164:in `block in instrument'
  activesupport (4.2.1) lib/active_support/notifications/instrumenter.rb:20:in `instrument'
  activesupport (4.2.1) lib/active_support/notifications.rb:164:in `instrument'
  actionpack (4.2.1) lib/action_controller/metal/instrumentation.rb:30:in `process_action'
  actionpack (4.2.1) lib/action_controller/metal/params_wrapper.rb:250:in `process_action'
  activerecord (4.2.1) lib/active_record/railties/controller_runtime.rb:18:in `process_action'
  actionpack (4.2.1) lib/abstract_controller/base.rb:137:in `process'
  actionview (4.2.1) lib/action_view/rendering.rb:30:in `process'
  actionpack (4.2.1) lib/action_controller/metal.rb:196:in `dispatch'
  actionpack (4.2.1) lib/action_controller/metal/rack_delegation.rb:13:in `dispatch'
  actionpack (4.2.1) lib/action_controller/metal.rb:237:in `block in action'
  actionpack (4.2.1) lib/action_dispatch/routing/route_set.rb:74:in `call'
  actionpack (4.2.1) lib/action_dispatch/routing/route_set.rb:74:in `dispatch'
  actionpack (4.2.1) lib/action_dispatch/routing/route_set.rb:43:in `serve'
  actionpack (4.2.1) lib/action_dispatch/routing/mapper.rb:49:in `serve'
  actionpack (4.2.1) lib/action_dispatch/journey/router.rb:43:in `block in serve'
  actionpack (4.2.1) lib/action_dispatch/journey/router.rb:30:in `each'
  actionpack (4.2.1) lib/action_dispatch/journey/router.rb:30:in `serve'
  actionpack (4.2.1) lib/action_dispatch/routing/route_set.rb:819:in `call'
  railties (4.2.1) lib/rails/engine.rb:518:in `call'
  railties (4.2.1) lib/rails/railtie.rb:194:in `public_send'
  railties (4.2.1) lib/rails/railtie.rb:194:in `method_missing'
  actionpack (4.2.1) lib/action_dispatch/routing/mapper.rb:51:in `serve'
  actionpack (4.2.1) lib/action_dispatch/journey/router.rb:43:in `block in serve'
  actionpack (4.2.1) lib/action_dispatch/journey/router.rb:30:in `each'
  actionpack (4.2.1) lib/action_dispatch/journey/router.rb:30:in `serve'
  actionpack (4.2.1) lib/action_dispatch/routing/route_set.rb:819:in `call'
  warden (1.2.3) lib/warden/manager.rb:35:in `block in call'
  warden (1.2.3) lib/warden/manager.rb:34:in `catch'
  warden (1.2.3) lib/warden/manager.rb:34:in `call'
  rack (1.6.0) lib/rack/etag.rb:24:in `call'
  rack (1.6.0) lib/rack/conditionalget.rb:25:in `call'
  rack (1.6.0) lib/rack/head.rb:13:in `call'

Steps to reproduce

Try to configure the devise modules used in Alchemy::User as described in Alchemy/devise.rb by adding a initializer that adds devise modules to Alchemy.devise_modules.

# config/initializers/alchemy.rb
Alchemy.devise_modules << :fantastic_module

Expected behavior

Alchemy::User.devise_modules should include :fantastic_module

Actual behavior

No matter what modules are added to Alchemy.devise_modules in the initializer, Alchemy::User.devise_modules will always stay the same since initializers are executed after framework and library stuff is loaded and Alchemy::User already has its configured devise modules.

System configuration

• Alchemy Version: 4.3.1
• Rails Version: 5.2.1

I actually need to remove the :validatable module from Alchemy::User since i want to add :secure_validatable from devise-security but i cannot find a good way to configure the used devise modules.

I pick up the discussion from #51 to continue the conversation in a separate thread.

Quoting myself:

As a feature suggestion: We could provide a alchemy/config.yml in alchemy-devise that only includes the devise modules and we read from that in the Alchemy::User class.

# Alchemy::User
DEVISE_MODULES = Alchemy::Config.get(:devise_modules)

Alchemy CMS would need to know that there is a config.yml - not sure if that would work...

Quoting @tvdeyen

That is a good idea (we had this once the user model was still in the core, remember?), but to achieve that there is more involved, because Alchemy does not support to add something to the config via an plugin.

We could add a app/config/alchemy/devise.yml, but then we need to duplicate all the configuration reading code from the core.

A solution could be to patch the core so it loads all app/config/alchemy/*.config.yml files and merges them together. So we could then have a app/config/alchemy/devise.config.yml file and use the configuration code from the core. (We can't just load all *.yml files in the app/config/alchemy folder, because the elements.yml and page_layouts.yml files also are in this folder.)

Or: Change the configuration file to app/config/alchemy.yml and then load all app/config/alchemy.*.yml files into the configuration. This would follow rails conventions, but is a bigger change for existing sites.

WDYT?

There are two simple issues.

When using devise for example :email as authentication key, the validation for uniqueness of :login is still present. There should be an easy way to turn this off.

When you DO want unique :login attributes, nil is currently an acceptable unique value, so validates_uniqueness_of :login should also include validates_presence_of :login

In order to solve this, I removed Alchemy Validators (two at the moment) and reinserted one I wanted to keep. The devise validators were untouched.

Alchemy::User.class_eval do
  clear_validators!
    validates_presence_of :alchemy_roles
  devise *Alchemy::User::DEVISE_MODULES += [:registerable]
end

A proposed solution would be to add some helper method in user.rb

validates_presence_of :login,  if: used_for_authentication?
validates_uniqueness_of :login, if: used_for_authentication?
  def used_for_authentication?
    Devise.authentication_keys.include?(:login)
  end

I'm noticing that inside of Alchemy Devise that when a general user signs up, its done through the admin sign up form seen here.

Are we able to abstract this away so that there is a form for the general user role and another form for the admin role?

This is an issue because on a general application, I signup is causing the notification message to read "successfully signed up admin user" and, for me, there was a redirect to the signup page (done onpurpose from my routes) where the form asked if they wanted to signup with different roles.

To get back to the point, are we able to separate or abstract the signups for each alchemy role? A member would use the member signup form, an admin would use the admin signup form, and so on... I believe this would bring an enormous amount of functionality.

We are way to far behind latest devise. That should be fixed asap.

When running rspec spec there were some deprication warnings such as:

--------------------------------------------------------------------------------
rspec-rails 3 will no longer automatically infer an example group's spec type
from the file location. You can explicitly opt-in to this feature using this
snippet:

RSpec.configure do |config|
  config.infer_spec_type_from_file_location!
end

If you wish to manually label spec types via metadata you can safely ignore
this warning and continue upgrading to RSpec 3 without addressing it.
--------------------------------------------------------------------------------

These will probably need to be looked at and updated.

See AlchemyCMS/alchemy-demo#11