GithubHelp home page GithubHelp logo

solidusio / solidus_auth_devise Goto Github PK

View Code? Open in Web Editor NEW
53.0 16.0 124.0 1.11 MB

🔑 Devise authentication for your Solidus store.

Home Page: http://solidus.io

License: BSD 3-Clause "New" or "Revised" License

Ruby 87.25% HTML 10.47% Shell 2.27%
solidus ecommerce ecommerce-platform solidus-extensions hacktoberfest

solidus_auth_devise's Introduction

Solidus Auth Devise

CircleCI codecov

Provides authentication services for Solidus, using the Devise gem.

Usage

Installation

Add solidus_auth_devise to your Gemfile:

gem 'solidus_auth_devise'

Then, run bundle install.

After that's done, you can install and run the necessary migrations, then seed the database:

bundle exec rake solidus_auth:install:migrations
bundle exec rake db:migrate
bundle exec rake db:seed

Default Username/Password

As part of running the above installation steps, you will be asked to set an admin email/password combination. The default values are [email protected] and test123, respectively.

Confirmable

To enable Devise's Confirmable module, which will send the user an email with a link to confirm their account, you must do the following:

  • Add this line to an initializer in your Rails project (typically config/initializers/spree.rb):
Spree::Auth::Config[:confirmable] = true
  • Add a Devise initializer to your Rails project (typically config/initializers/devise.rb):
Devise.setup do |config|
  # Required so users don't lose their carts when they need to confirm.
  config.allow_unconfirmed_access_for = 1.days

  # Add any other devise configurations here, as they will override the defaults provided by solidus_auth_devise.
end

Using in an existing application

If you are installing Solidus inside of a host application in which you want your own permission setup, you can do this using the register_ability method.

First create your own CanCan Ability class following the CanCan documentation.

For example: app/models/super_abilities.rb

class SuperAbilities
  include CanCan::Ability

  def initialize user
    if user.is? "Superman"
      can :stop, Bullet
    end
  end
end

Then register your class in your spree initializer: config/initializers/spree.rb

Spree::Ability.register_ability(SuperAbilities)

Inside of your host application you can then use CanCan like you normally would.

<% if can? :stop Bullet %>
  ...
<% end %>

Development

Testing the extension

First bundle your dependencies, then run bin/rake. bin/rake will default to building the dummy app if it does not exist, then it will run specs. The dummy app can be regenerated by using bin/rake extension:test_app.

bin/rake

To run Rubocop static code analysis run

bundle exec rubocop

When testing your application's integration with this extension you may use its factories. Simply add this require statement to your spec/spec_helper.rb:

require 'solidus_auth_devise/testing_support/factories'

Or, if you are using FactoryBot.definition_file_paths, you can load Solidus core factories along with this extension's factories using this statement:

SolidusDevSupport::TestingSupport::Factories.load_for(SolidusAuthDevise::Engine)

Running the sandbox

To run this extension in a sandboxed Solidus application, you can run bin/sandbox. The path for the sandbox app is ./sandbox and bin/rails will forward any Rails commands to sandbox/bin/rails.

Here's an example:

$ bin/rails server
=> Booting Puma
=> Rails 6.0.2.1 application starting in development
* Listening on tcp://127.0.0.1:3000
Use Ctrl-C to stop

Updating the changelog

Before and after releases the changelog should be updated to reflect the up-to-date status of the project:

bin/rake changelog
git add CHANGELOG.md
git commit -m "Update the changelog"

Releasing new versions

Please refer to the dedicated page on Solidus wiki.

License

Copyright (c) 2022 Solidus Team, released under the New BSD License.

solidus_auth_devise's People

Contributors

adammathys avatar aitbw avatar aldesantis avatar bbuchalter avatar brchristian avatar elia avatar forkata avatar futhr avatar gsmendoza avatar huoxito avatar jacobherrington avatar jdutil avatar jhawthorn avatar jordan-brough avatar jtapia avatar kennyadsl avatar mamhoff avatar peterberkenbosch avatar petergoldstein avatar radar avatar reinaris avatar schof avatar sinetheta avatar spaghetticode avatar stewart avatar swcraig avatar tvdeyen avatar waiting-for-dev avatar westonplatter avatar yono avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

solidus_auth_devise's Issues

Cant locate devise.rb file to locate secret key.

Hi guys I am brand new to programming and im working on creating a new solidus project. It doesnt seem to create this devise.rb file that contains the secret key. If it does I cant seem to find it. Maybe we could create a pull request to update the documentation on how to easily access this?

No CHANGELOG for this repo

It's time to start a changelog file on this repo for each release. Perhaps we could backfill it between v1.1 and the latest release for v1.4?

When adding solidus_frontend and solidus_auth_devise I am getting an exception

When add these two gems together on my Gemfile:

solidus_frontend (~> 2.9.0)
solidus_auth_devise

I am getting the error below when trying to start the server
Before process_action callback :setup_for_current_state has not been defined (ArgumentError)
The only way we found to fix this is by doing this change to this file

lib/controllers/frontend/spree/checkout_controller_decorator.rb

-      base.skip_before_action :setup_for_current_state, only: [:registration, :update_registration]
+      base.skip_before_action :setup_for_current_state, only: [:registration, :update_registration], raise: false

Is this happening to someone else? Am I doing something wrong?

Zeitwerk Issue on Rails 6.1

Someone reported an issue over here where the Spree::User model wasn't present when installing Solidus. It was solved by returning to the classic autoloader. This suggests to me that we may have an issue with Zeitwerk loading in recent versions.

I've not investigated this any further, but didn't want to forget so I opened this issue.

Non compatible with Turbo

Turbo requires redirects on form submissions, or in the case on render :new when login fails, the status on unprocessable_entity as the response code.

Is it possible to update this in this gem?

User.login can’t be modified once set

I’m using a vanilla Solidus 2.4.2 store with solidus_auth_devised.

It looks like the default user created has email: [email protected] and login: [email protected]. If I go to the /account/edit page, I can modify the User’s email.

Now I have a situation where I have email: [email protected] and login: [email protected]. It seems there is simply no way to modify the login attribute once the user is created. What’s slightly weirder, it is email, not login, that is used to log in. :)

What should we do here?

My suggestion would be that if this extension is built to use the email attribute as the login by default, than we should either:

  1. leave the actual login attribute as nil when creating a new user.
  2. save any new changes to the email field to the login attribute as well.

@jhawthorn perhaps you can weigh in here. I’d be happy to prepare a PR once we settle on what we think the behavior should be. I’m just finding it weird to have accounts with this legacy login field set to whatever the initial value was and not able to be modified later. Let me know what you think!

Devise Encryptor, why authlogic_sha512?

I was surprised to see the default encryptor for Devise was overwritten in this gem. Is there a good reason for this?

When I attempted to export my solidus user database to another platform, Firebase Auth, I couldn't find a solution for importing the passwords using the SHA512 examples found in their docs: https://firebase.google.com/docs/auth/admin/import-users

Perhaps someone here might have a clue how to get passwords over to Firebase Auth.

Here's where the encryptor is being set in this repo.

config.encryptor = 'authlogic_sha512'

Make solidus_auth_devise for backend work without solidus_frontend

I see a few commits that address frontend specific things being loaded but as far as I can tell solidus_auth_devise is still broken when only solidus_core and solidus_backend are installed.

For the inital issue report please see: solidusio/solidus#1286

What I have found so far:
Because the :spree_user scope for backend is created in the :admin namespace devise will create it and its helpers as admin_spree_user.

In lib/spree/authentication_helpers.rb on master there are conditionals for the paths but spree_current_user is defined to use current_spree_user (the default Devise helper) which does not exist in the described setup.

Changing current_spree_user to current_admin_spree_user fixes this part of the issue so there should probably be another conditional included here.

This makes the authentication function able to find the current spree user. However, this confuses Devise because in config/routes.rb the paths for the admin scope are defined on the spree_user scope instead of the admin_spree_user scope and thus they can not be found. (devise_for does take any namespaces into account when determining what to pass to devise_scope but this is not done in the manual invocation of devise_scope in the routes file).

By changing devise_scope on line 50 to :admin_spree_user this error is fixed.

We are now at a point where the initial navigation to /admin will redirect to /admin/login.

A new error occurs here: on line 28 of lib/views/backend/spree/admin/user_sessions/new.html.erb the helper function recover_password_path is called. However the recover_password path is never defined for the admin user scope. It is however defined when the frontend is available.

There are two possible fixes:
Either remove the link from the admin login page which is easiest or copy the routes from the frontend to also be used on the backend scope.

Choosing for now the simplest option and removing the links I continue my quest. The login screen is correctly presented however it won't properly submit because of a call to authenticate_spree_user! in Spree::Admin::UserSessionsController. Changing the scope here and on the if statement that checks if authentication was succesful (line 15) will fix the errors upon login form submission.

I would be glad to provide a pull request with all the changes. My main problem is that I'm not sure about the intentions in the initial implementation:

  • Should there be two different scopes so admins and base users are properly separated?
  • Should there be just one scope but have two inadvertently been created.

This is the point at which I'm stuck. My feeling says that the second option is intended. My fixes however are intended towards the first option. As an alternative, setting the admin namespace as: nil will prevent Devise from prefixing the scope with admin. This however breaks other places that do use admin_login_path.

What is the intended way forward?
Apologies for the wall of text, I've tried to document my research best as possible.

Asset compilation crashes on 2.5.0

I just updated solidus_auth_devise to 2.5.0 and noticed that my push to Heroku failed with the following:

Sprockets::FileNotFound: couldn't find file 'spree/backend/solidus_auth' with type 'application/javascript'
Checked in these paths: 
[...]
/tmp/build_e249da96/vendor/bundle/ruby/2.6.0/gems/solidus_backend-2.10.2/app/assets/config/solidus_backend_manifest.js:3
/tmp/build_e249da96/vendor/assets/javascripts/spree/backend/all.js:11

Any idea what might be going on here?

Using:
Ruby 2.6.6
Rails 5.1.7
Solidus 2.10.2
solidus_auth_devise 2.5.0

How to access current_user?

I am trying to create an ability class like the readme, but couldn't access the current_user.
And where did the is? method come from. Here is my implementation ( which doesn't work )

class Ability
  include CanCan::Ability
  def initialize user
    if is? 'web_manager'
      can :assign_roles, Spree::User
    elsif is? 'sales_manager'
    ...
    end
  end

  private
  def is?(role)
    user.has_spree_role(role)
  end
end

Spree.user_class not using my specific class

Hi,

I'm following the guidelines to set a custom auth system on my app's backend.

I have this line in my config/initializers/spree.rb file :

Spree.user_class = 'User'

but when booting the app or running the rails console, hitting Spree.user_class still returns Spree::User.

I believe this is due to this line, that is executed after loading the initializers, thus setting Spree.user_class back to Spree::User.

I've been able to workaround this issue by overriding the related initializer declaration in my main config file:

# config/application.rb
initializer "solidus_auth_devise.set_user_class", after: :load_config_initializers do
  Spree.user_class = "User"
end

Questions

  • Did I have the wrong interpretation and I could have messed something up in my app?
  • Otherwise, should the custom generator instead generate the block I wrote above?

Thanks in advance!

This line doesn't do anything

Like the title says, this line doesn't do anything. Spree::Core::ControllerHelpers is the namespace with all the helper concerns in it and they are already included in this class since it inherits from Spree::StoreController.

Missing `config.secret_key_base` from default devise.rb?

I'm using the default Devise initializer provided by the gem. When starting up a rails server, I get the following warning from Devise. Is this intentional to use a pepper without a secret_key?

# devise.rb
Devise.setup do |config|

... 

  # ==> Configuration for :database_authenticatable
  # For bcrypt, this is the cost for hashing the password and defaults to 10. If
  # using other encryptors, it sets how many times you want the password re-encrypted.
  config.stretches = 20
  config.encryptor = 'authlogic_sha512'

  # Setup a pepper to generate the encrypted password.
  config.pepper = Rails.configuration.secret_token

...

end
# rails server log 
=> Booting WEBrick
=> Rails 4.2.5 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
[WARNING] You are not setting Devise.secret_key within your application!
You must set this in config/initializers/devise.rb. Here's an example:

Devise.secret_key = "a12b4c26be470f7d49ee8e852aab31e8f0fa20794136b817c1387ad6a2bc77e33a9655657d3630b37f064ca989265e655ba7"

Zeitwerk::NameError

(expected file /home/maddy/Sites/DeviceMailer/app/controllers/registrations_controller.rb to define constant RegistrationsController, but didn't):

Autoload issue

Description

We upgraded Solidus from 2.11 to 3.1.0 and we have an user model decorator, after the upgrade we started noticiting that if change and reload any code related to user decorator, it triggers an autoload error
undefined local variable or method acts_as_paranoid for Spree::User:Class

for some reason here https://github.com/solidusio/solidus_auth_devise/blob/master/app/models/spree/user.rb#L11= is not finding the Spree::SoftDeletable module, tried to use acts_as_paranoid but all the references were removed here 11b9fa9

Gemfile

gem 'rails', '6.1.4.1'
gem 'solidus', '3.1.0'
gem 'solidus_support'
gem 'solidus_auth_devise'
gem 'solidus_paypal_commerce_platform'

Decorator

module Decorators
  module Spree
    module User
      def self.prepended(base)
        base.class_eval do
          ...
          ...
        end
      end
    end
  end
end

Log

Started GET "/account/products" for ::1 at 2022-07-26 12:08:03 -0500

NameError (undefined local variable or method `acts_as_paranoid' for Spree::User:Class
Did you mean?  acts_as_list):

activerecord (6.1.4.1) lib/active_record/dynamic_matchers.rb:22:in `method_missing'
solidus_auth_devise (2.5.4) app/models/spree/user.rb:14:in `<class:User>'
solidus_auth_devise (2.5.4) app/models/spree/user.rb:4:in `<module:Spree>'
solidus_auth_devise (2.5.4) app/models/spree/user.rb:3:in `<main>'
bootsnap (1.12.0) lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:39:in `load'
bootsnap (1.12.0) lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:39:in `load'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:523:in `block in load_file'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:715:in `new_constants_in'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:522:in `load_file'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:419:in `block in require_or_load'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:39:in `block in load_interlock'
activesupport (6.1.4.1) lib/active_support/dependencies/interlock.rb:14:in `block in loading'
activesupport (6.1.4.1) lib/active_support/concurrency/share_lock.rb:151:in `exclusive'
activesupport (6.1.4.1) lib/active_support/dependencies/interlock.rb:13:in `loading'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:39:in `load_interlock'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:402:in `require_or_load'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:558:in `load_missing_constant'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:213:in `const_missing'
activesupport (6.1.4.1) lib/active_support/inflector/methods.rb:288:in `const_get'
activesupport (6.1.4.1) lib/active_support/inflector/methods.rb:288:in `block in constantize'
activesupport (6.1.4.1) lib/active_support/inflector/methods.rb:284:in `each'
activesupport (6.1.4.1) lib/active_support/inflector/methods.rb:284:in `inject'
activesupport (6.1.4.1) lib/active_support/inflector/methods.rb:284:in `constantize'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:636:in `get'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:667:in `constantize'
devise (4.8.1) lib/devise.rb:318:in `get'
devise (4.8.1) lib/devise/mapping.rb:83:in `to'
devise (4.8.1) lib/devise/mapping.rb:78:in `modules'
devise (4.8.1) lib/devise/mapping.rb:95:in `routes'
devise (4.8.1) lib/devise/mapping.rb:162:in `default_used_route'
devise (4.8.1) lib/devise/mapping.rb:72:in `initialize'
devise (4.8.1) lib/devise.rb:354:in `new'
devise (4.8.1) lib/devise.rb:354:in `add_mapping'
devise (4.8.1) lib/devise/rails/routes.rb:243:in `block in devise_for'
devise (4.8.1) lib/devise/rails/routes.rb:242:in `each'
devise (4.8.1) lib/devise/rails/routes.rb:242:in `devise_for'
solidus_auth_devise (2.5.4) config/routes.rb:5:in `block in <main>'
actionpack (6.1.4.1) lib/action_dispatch/routing/mapper.rb:655:in `instance_exec'
actionpack (6.1.4.1) lib/action_dispatch/routing/mapper.rb:655:in `block in with_default_scope'
actionpack (6.1.4.1) lib/action_dispatch/routing/mapper.rb:901:in `scope'
actionpack (6.1.4.1) lib/action_dispatch/routing/mapper.rb:654:in `with_default_scope'
actionpack (6.1.4.1) lib/action_dispatch/routing/route_set.rb:425:in `eval_block'
actionpack (6.1.4.1) lib/action_dispatch/routing/route_set.rb:409:in `draw'
solidus_auth_devise (2.5.4) config/routes.rb:3:in `<main>'
bootsnap (1.12.0) lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:39:in `load'
bootsnap (1.12.0) lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:39:in `load'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:326:in `block in load'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:299:in `load_dependency'
activesupport (6.1.4.1) lib/active_support/dependencies.rb:326:in `load'
railties (6.1.4.1) lib/rails/application/routes_reloader.rb:47:in `block in load_paths'
railties (6.1.4.1) lib/rails/application/routes_reloader.rb:47:in `each'
railties (6.1.4.1) lib/rails/application/routes_reloader.rb:47:in `load_paths'
railties (6.1.4.1) lib/rails/application/routes_reloader.rb:21:in `reload!'
railties (6.1.4.1) lib/rails/application/routes_reloader.rb:35:in `block in updater'
activesupport (6.1.4.1) lib/active_support/file_update_checker.rb:83:in `execute'
railties (6.1.4.1) lib/rails/application/routes_reloader.rb:10:in `execute'
railties (6.1.4.1) lib/rails/application/finisher.rb:208:in `block (2 levels) in <module:Finisher>'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:427:in `instance_exec'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:427:in `block in make_lambda'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:198:in `block (2 levels) in halting'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:604:in `block (2 levels) in default_terminator'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:603:in `catch'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:603:in `block in default_terminator'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:199:in `block in halting'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:512:in `block in invoke_before'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:512:in `each'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:512:in `invoke_before'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:105:in `run_callbacks'
activesupport (6.1.4.1) lib/active_support/execution_wrapper.rb:111:in `run!'
activesupport (6.1.4.1) lib/active_support/reloader.rb:114:in `run!'
activesupport (6.1.4.1) lib/active_support/execution_wrapper.rb:73:in `block in run!'
<internal:kernel>:90:in `tap'
activesupport (6.1.4.1) lib/active_support/execution_wrapper.rb:70:in `run!'
activesupport (6.1.4.1) lib/active_support/reloader.rb:63:in `run!'
actionpack (6.1.4.1) lib/action_dispatch/middleware/executor.rb:12:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/actionable_exceptions.rb:18:in `call'
sentry-rails (5.4.1) lib/sentry/rails/rescued_exception_interceptor.rb:9:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/debug_exceptions.rb:29:in `call'
web-console (4.2.0) lib/web_console/middleware.rb:132:in `call_app'
web-console (4.2.0) lib/web_console/middleware.rb:28:in `block in call'
web-console (4.2.0) lib/web_console/middleware.rb:17:in `catch'
web-console (4.2.0) lib/web_console/middleware.rb:17:in `call'
sentry-ruby (5.4.1) lib/sentry/rack/capture_exceptions.rb:13:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
railties (6.1.4.1) lib/rails/rack/logger.rb:37:in `call_app'
railties (6.1.4.1) lib/rails/rack/logger.rb:26:in `block in call'
activesupport (6.1.4.1) lib/active_support/tagged_logging.rb:99:in `block in tagged'
activesupport (6.1.4.1) lib/active_support/tagged_logging.rb:37:in `tagged'
activesupport (6.1.4.1) lib/active_support/tagged_logging.rb:99:in `tagged'
railties (6.1.4.1) lib/rails/rack/logger.rb:26:in `call'
sprockets-rails (3.4.2) lib/sprockets/rails/quiet_assets.rb:13:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/request_id.rb:26:in `call'
rack (2.2.4) lib/rack/method_override.rb:24:in `call'
rack (2.2.4) lib/rack/runtime.rb:22:in `call'
activesupport (6.1.4.1) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/executor.rb:14:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/static.rb:24:in `call'
rack (2.2.4) lib/rack/sendfile.rb:110:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/host_authorization.rb:98:in `call'
webpacker (5.4.3) lib/webpacker/dev_server_proxy.rb:25:in `perform_request'
rack-proxy (0.7.2) lib/rack/proxy.rb:67:in `call'
railties (6.1.4.1) lib/rails/engine.rb:539:in `call'
rack-reverse-proxy (0.11.0) lib/rack_reverse_proxy/roundtrip.rb:19:in `call'
rack-reverse-proxy (0.11.0) lib/rack_reverse_proxy/middleware.rb:25:in `call'
puma (4.3.12) lib/puma/configuration.rb:228:in `call'
puma (4.3.12) lib/puma/server.rb:727:in `handle_request'
puma (4.3.12) lib/puma/server.rb:476:in `process_client'
puma (4.3.12) lib/puma/server.rb:332:in `block in run'
puma (4.3.12) lib/puma/thread_pool.rb:134:in `block in spawn_thread'

Install migration task not working

I see the following error upon installation

› bundle exec rake solidus_auth:install:migration
RubyDep: WARNING: Your Ruby is outdated/buggy. (To disable warnings, set RUBY_DEP_GEM_SILENCE_WARNINGS=1)
RubyDep: WARNING: Your Ruby is: 2.3.0 (buggy). Recommendation: install 2.3.1.
rake aborted!
Don't know how to build task 'solidus_auth:install:migration' (see --tasks)
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/cli/exec.rb:63:in `load'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/cli/exec.rb:63:in `kernel_load'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/cli/exec.rb:24:in `run'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/cli.rb:304:in `exec'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor.rb:359:in `dispatch'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor/base.rb:440:in `start'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/cli.rb:11:in `start'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/exe/bundle:27:in `block in <top (required)>'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/lib/bundler/friendly_errors.rb:98:in `with_friendly_errors'
/Users/sinetheta/.gem/ruby/2.3.0/gems/bundler-1.12.5/exe/bundle:19:in `<top (required)>'
/Users/sinetheta/.gem/ruby/2.3.0/bin/bundle:23:in `load'
/Users/sinetheta/.gem/ruby/2.3.0/bin/bundle:23:in `<main>'
(See full trace by running task with --trace)

Although bin/rails railties:install:migrations worked fine. Also, I should probably upgrade ruby ;)

Requiring gem, on API only projects, throws LoadError (sass/rails)

Requiring this gem on Rails 5 API only projects throws LoadError.

Steps to reproduce

  1. Create a Rails 5 API only project rails new store --api
  2. Add solidus_auth_device to Gemfile and install it
  3. run any rake tasks. Like rake db:create

output

rails aborted!
LoadError: cannot load such file -- sass/rails
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/activesupport-5.0.2/lib/active_support/dependencies.rb:293:in `require'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/activesupport-5.0.2/lib/active_support/dependencies.rb:293:in `block in require'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/activesupport-5.0.2/lib/active_support/dependencies.rb:259:in `load_dependency'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/activesupport-5.0.2/lib/active_support/dependencies.rb:293:in `require'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/solidus_auth_devise-1.6.2/lib/solidus_auth_devise.rb:4:in `<top (required)>'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/bundler-1.14.3/lib/bundler/runtime.rb:91:in `require'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/bundler-1.14.3/lib/bundler/runtime.rb:91:in `block (2 levels) in require'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/bundler-1.14.3/lib/bundler/runtime.rb:86:in `each'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/bundler-1.14.3/lib/bundler/runtime.rb:86:in `block in require'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/bundler-1.14.3/lib/bundler/runtime.rb:75:in `each'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/bundler-1.14.3/lib/bundler/runtime.rb:75:in `require'
/home/gabriel/.rvm/gems/ruby-2.3.0/gems/bundler-1.14.3/lib/bundler.rb:107:in `require'
/home/gabriel/Projects/suppl-api/config/application.rb:17:in `<top (required)>'
/home/gabriel/Projects/suppl-api/Rakefile:4:in `require_relative'
/home/gabriel/Projects/suppl-api/Rakefile:4:in `<top (required)>'
...

Gems verion

  • Rails 5.0.2
  • solidus_auth_token 1.6.2

Bug: NameError

rails version : 6.0.0

solidus Version: 2.10.0.beta1

solidus_auth_devise Version: 2.3.0

Running RAILS_ENV=production bundle exec rails s results in the following error with a fresh install of solidus. It could be something I've misconfigured so please let me know

NameError: expected file /usr/local/bundle/gems/solidus_auth_devise-2.3.0/app/overrides/auth_shared_login_bar.rb to define constant AuthSharedLoginBar, but didn't
bundler: failed to load command: puma (/usr/local/bundle/bin/puma)
NameError: expected file /usr/local/bundle/gems/solidus_auth_devise-2.3.0/app/overrides/auth_shared_login_bar.rb to define constant AuthSharedLoginBar, but didn't
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader/callbacks.rb:17:in `on_file_autoloaded'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:17:in `block in require'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:16:in `tap'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:16:in `require'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:351:in `const_get'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:351:in `block (2 levels) in eager_load'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:679:in `block in ls'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:676:in `foreach'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:676:in `ls'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:346:in `block in eager_load'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:338:in `synchronize'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:338:in `eager_load'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:449:in `each'
  /usr/local/bundle/gems/zeitwerk-2.1.10/lib/zeitwerk/loader.rb:449:in `eager_load_all'
  /usr/local/bundle/gems/railties-6.0.0/lib/rails/application/finisher.rb:122:in `block in <module:Finisher>'
  /usr/local/bundle/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `instance_exec'
  /usr/local/bundle/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `run'
  /usr/local/bundle/gems/railties-6.0.0/lib/rails/initializable.rb:61:in `block in run_initializers'
  /usr/local/lib/ruby/2.6.0/tsort.rb:228:in `block in tsort_each'
  /usr/local/lib/ruby/2.6.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
  /usr/local/lib/ruby/2.6.0/tsort.rb:431:in `each_strongly_connected_component_from'
  /usr/local/lib/ruby/2.6.0/tsort.rb:349:in `block in each_strongly_connected_component'
  /usr/local/lib/ruby/2.6.0/tsort.rb:347:in `each'
  /usr/local/lib/ruby/2.6.0/tsort.rb:347:in `call'
  /usr/local/lib/ruby/2.6.0/tsort.rb:347:in `each_strongly_connected_component'
  /usr/local/lib/ruby/2.6.0/tsort.rb:226:in `tsort_each'
  /usr/local/lib/ruby/2.6.0/tsort.rb:205:in `tsort_each'
  /usr/local/bundle/gems/railties-6.0.0/lib/rails/initializable.rb:60:in `run_initializers'
  /usr/local/bundle/gems/railties-6.0.0/lib/rails/application.rb:363:in `initialize!'
  /app/config/environment.rb:5:in `<top (required)>'
  config.ru:3:in `require_relative'
  config.ru:3:in `block in <main>'
  /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:55:in `instance_eval'
  /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:55:in `initialize'
  config.ru:in `new'
  config.ru:in `<main>'
  /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:49:in `eval'
  /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:49:in `new_from_string'
  /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:40:in `parse_file'
  /usr/local/bundle/gems/puma-3.12.1/lib/puma/configuration.rb:320:in `load_rackup'
  /usr/local/bundle/gems/puma-3.12.1/lib/puma/configuration.rb:245:in `app'
  /usr/local/bundle/gems/puma-3.12.1/lib/puma/runner.rb:147:in `load_and_bind'
  /usr/local/bundle/gems/puma-3.12.1/lib/puma/single.rb:98:in `run'
  /usr/local/bundle/gems/puma-3.12.1/lib/puma/launcher.rb:186:in `run'
  /usr/local/bundle/gems/puma-3.12.1/lib/puma/cli.rb:80:in `run'
  /usr/local/bundle/gems/puma-3.12.1/bin/puma:10:in `<top (required)>'
  /usr/local/bundle/bin/puma:23:in `load'
  /usr/local/bundle/bin/puma:23:in `<top (required)>'

Shouldn't order history be inside solidus repo?

Hello, I am integrating Solidus ecommerce in an existing app, so I need to use the existing User table.
I am not actually using this gem, but I found out that the user orders history (routes, views and so on) are inside this repo.
I am a bit confused about it, because authentication does not really concern orders, IMHO these parts of code may better belong inside solidus codebase. What's your opinion on this matter?

The update action of the password controller from devise makes my app go into a loop.

In my app https://github.com/shcyiza/tozakitoko
When I was testing out the password recovery i felt upon this problem.
The process is smooth, until i got to the password edit page. When i submit a new password the app gets to the update action. The action actually update my password, log me in en then it tries to go back to the edit page and it starts looping like u can see in this sample of my server below.

Redirected to http://localhost:3000/user/spree_user/password/edit?reset_password_token=CRQYbC5B8TyLPifHX9za
Completed 302 Found in 101ms (ActiveRecord: 6.6ms)


Started GET "/user/spree_user/password/edit?reset_password_token=[FILTERED]" for 127.0.0.1 at 2017-01-14 21:44:47 +0100
Processing by Spree::UserPasswordsController#edit as HTML
  Parameters: {"reset_password_token"=>"[FILTERED]"}
  Spree::User Load (0.5ms)  SELECT  "spree_users".* FROM "spree_users" WHERE "spree_users"."deleted_at" IS NULL AND "spree_users"."id" = $1  ORDER BY "spree_users"."id" ASC LIMIT 1  [["id", 9]]
default_url_options is passed options: {}

Redirected to http://localhost:3000/user/spree_user/password/edit?
from there it just load this page again and again and again...

I fixed it with by overriding the update action from your extension like this:

Spree::UserPasswordsController.class_eval do

   def update
      if params[:spree_user][:password].blank?
        super
      else
        self.resource = resource_class.reset_password_by_token(resource_params)
        yield resource if block_given?
        if resource.errors.empty?
          resource.unlock_access! if unlockable?(resource)
          if Devise.sign_in_after_reset_password
            flash_message = resource.active_for_authentication? ? :updated : :updated_not_active
            set_flash_message!(:notice, flash_message)
            sign_in(resource_name, resource)
          else
              redirect_to :back
              set_flash_message!(:notice, :updated_not_active)
          end
          respond_with resource, location: root_path(resource)
        else
          set_minimum_password_length
          respond_with resource
        end
      end
    end

  end

Sinds i don't have this issue with other app using devise, i think this controller might not be adapted to some update of devise. You guys should check that out and if the problem comes from my app please let me know.

KR

Issue redirecting to Spree routes

I was having an issue redirecting unauthenticated users to the correct URL: new_spree_user_session_url. Because this route is mounted within Spree, it doesn't detect this route and the FailureApp falls back to redirecting users to the homepage.

To fix this, the router_name config option for Spree::User must be set to :spree. This is already mentioned in the README as a fix for Confirmation errors (997382f#diff-04c6e90faac2675aa89e2176d2eec7d8R59). If this is in fact a global fix that's required, could the router_name be specified in the SpreeUser Devise setup in routes (https://github.com/solidusio/solidus_auth_devise/blob/master/config/routes.rb#L7) like so:

    devise_for(:spree_user, {
      class_name: 'Spree::User',
      controllers: {
        sessions: 'spree/user_sessions',
        registrations: 'spree/user_registrations',
        passwords: 'spree/user_passwords',
        confirmations: 'spree/user_confirmations'
      },
      skip: [:unlocks, :omniauth_callbacks],
      path_names: { sign_out: 'logout' },
      path_prefix: :user,
      router_name: :spree
    })

Problematic Default Configuration for Devise.secret_key

Currently the default behavior when generating a Solidus application using the generator and including Solidus Auth Devise is to set the Devise.secret_key to a random value at application boot.

This is handled by lib/generators/solidus/auth/install/templates/config/initializers/devise.rb and creates the following code in config/initializers/devise.rb.

# frozen_string_literal: true

Devise.secret_key = SecureRandom.hex(50).inspect

This creates problematic behavior, because the secret key base used to generate password reset tokens uses an ephemeral key which is lost on application reboot, and is not known across different instances of the same application (for example multiple Kubernetes pods running the app). As a result, all password reset links are invalidated when the application is restarted, and password reset links will fail to function if a different replica of the application handles the request to set the password from the replica that initiated the reset.

By default, Devise uses Rails.application.secret_key_base if you do not set Devise.secret_key explicitly which is generally stable across restarts and (if correctly configured) different replicas of the application. Accepting this as the default behavior by not setting Devise.secret_key at all would prevent these problems that the default behavior currently produces.

Solidus Version: 4.3.4

To Reproduce
The behavior is reproduced when creating a new solidus application using the solidus generator.

Adding omniauthable to to Spree::User

Hi everyone, I've been having a few issues after adding omniauthable to the Spree::User class.

I used a module to prepend calls to devise and add any necessary extra methods, the problem happens on development when classes are reloaded.

I believe (haven't checked yet) that routes are reloaded before the core classes, so as soon as my routes file is read, it will setup the omniauthable routes, and load the Spree::User class but without my prepended module.
This causes every class reload on development require a full server restart.

I tried solving this by creating a ::User class, inherit from Spree::User and setting Spree.user_class = "::User" but apparently constantize thinks that means Spree::User :(

One thing that could help would be a hook to add extra parameters to the devise call, which would then correctly load omniauthable even before my prepended modules.

What do you guys think? Am I doing some glaring stupid mistake?

RuntimeError: Can't modify frozen hash

When calling user.really_destroy! the following error raises

RuntimeError: Can't modify frozen hash

This is due to scramble_email_and_password method.

When really destroying the method, this callback attempts to save a record which is deleted.

See: https://github.com/solidusio/solidus_auth_devise/blob/master/app/models/spree/user.rb#L53

Solution:

Place at the top of the method

def scramble_email_and_password
  return if destroyed?

  # Rest of code
end

This way, if we're actually destroying the record. save won't get called.

Rails 6 and Solidus AuthDevise issues?

When loading my new Rails 6 app which uses Solidus, I get a warning about autoloading parts of the Solidus library. It seems like this is something which is not ideal, given that the warning states the autoload behavior is potentially going away in the future:

DEPRECATION WARNING: Initialization autoloaded the constants Spree::AuthConfiguration.

Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.

Reloading does not reboot the application, and therefore code executed during
initialization does not run again. So, if you reload Spree::AuthConfiguration, for example,
the expected changes won't be reflected in that stale Class object.

These autoloaded constants have been unloaded.

Please, check the "Autoloading and Reloading Constants" guide for solutions.

Any advice on how to fix this? Is this something with local setup? Or something specifically with the devise configuration? It seems likely this something related to how Zweitwork stuff is configured in this gem, but it's not immediately obvious.

Solidus Version:

[3] pry(main)> Spree.solidus_version
=> "2.10.0"

Gem versions:
rails (6.0.2.2)
solidus_api (2.10.0)
solidus_auth_devise (2.4.0)
solidus_backend (2.10.0)
solidus_core (2.10.0)

Let's use more Devise defaults for routing

The level of customization in the routes for solidus_auth_devise seems unnecessarily complex and confusing. As a first step to reducing complexity, I suggest we try to eliminate the devise_scope :spree_user block and allow Devise's defaults to do what they should.

Deface Override requires solidus_frontend

If solidus_frontend is not included in the application (as is likely the case with most stores, as custom frontends are common), the auth_shared_login_bar Deface override fails to compile:

Unable to precompile 'spree/shared/_nav_bar' due to:
Missing template spree/shared/_nav_bar with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:erb, :builder, :raw, :ruby, :coffee, :haml, :rabl], :versions=>[:v10, :v9, :v8, :v7, :v6, :v5, :v4, :v3, :v2, :v1]}. Searched in:
  * "/home/stewart/dev/store/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/teaspoon-1.1.5/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/solidus_auth_devise-1.5.0/lib/views/backend"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/devise-4.2.0/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/solidus_braintree-1.1.0/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/bundler/gems/solidus-bfe4b247b961/backend/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/bundler/gems/solidus-bfe4b247b961/api/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/bundler/gems/solidus-bfe4b247b961/core/app/views"
  * "/home/stewart/dev/store/vendor/bundle/ruby/2.2.0/gems/kaminari-0.17.0/app/views"

This could possibly be fixed by only applying the override if solidus_frontend is present.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.