solidus_backend has no `current_spree_user`

[Kingdutch]

Commands executed:

rails new --skip-test-unit solidus

rails --version 

Rails 4.2.6

Added the following lines to Gemfile

gem 'solidus_core'
gem 'solidus_backend'
gem 'solidus_auth_devise'

Ran

bundle exec g spree:install

A warning about a missing JavaScript runtime (obviously).
Uncomment therubyracer line in Gemfile and run bundle

Try again:

bundle exec rails g spree:install

A warning comes up

[WARNING] You are not setting Devise.secret_key within your application!

We'll fix this later as per #931
For now we follow instructions and create our first admin user

Spree has been installed succesfully and is all ready to go!

(the mention of Spree should perhaps be changed in a different issue).

Next we run the generator to create our Devise configuration:

rails g solidus:auth:install

This looks all green so far!

Finally as per the README.md instructions we install any leftover migrations:

bundle exec rake railties:install:migrations

No effect

Finally we run all migrations to bring our database up to speed before starting the rails server.

bundle exec rake db:migrate
bundle exec rails s

Browsing to localhost:3000/ serves the default Rails welcome page.
This is to be expected as I have nothing set-up that would serve anything here.
All the admin pages are namespaced in /admin. So we browse to /admin

Here however we run into an error

undefined local variable or method `current_spree_user' for #Spree::Admin::RootController:0x000000073f2b98

I did some digging around earlier. As far as I can understand the current_<something> methods are made by Devise for its scopes. However, as far as I could find there is no spree_user scope defined in solidus_backend. There is a admin_spree_user scope that is used and properly This is however not the scope used when browsing to /admin.

I suspect that this doesn't fail in tests because the spree_user scope is defined in solidus_frontend which is in the main solidus repo (See #1285)

The output of rake routes can be found here: https://gist.github.com/Kingdutch/327ea58b892369cfee74f828d8a423a8

Navigating to either /admin/login or /user/spree_user/sign_in gives errors that I've copied to the following gist:
https://gist.github.com/Kingdutch/464369d8aff1284e1f729a54e6bf53d7

[Kingdutch]

I've pushed the code that was created by the steps above to the repo at: https://github.com/Kingdutch/solidus-scope

[Kingdutch]

Typing this up helps to think of possible workarounds:

Indeed installing the solidus_frontend gem and running bundle exec rails g spree:install where I force the overriding of the Spree initializer (I hadn't changed anything to that from stock). Results in an installation that works as expected.

This probably means that the title of the issue should be changed to "solidus backend depends on solidus frontend"

[fredericboivin]

Solidus (the gem) is made of core/backend/frontend/api. Frontend is not only about views, it includes all the logic surrounding browsing products / cart / checking out / some code surrounding users with solidus_auth_devise (which is the issue at hand here).

[Kingdutch]

Does that mean then that solidus_auth_devise actually has a dependency on solidus_frontend?

I went from the following text which is in the first part of the README

It is also possible, however, to use only the pieces you are interested in. For example, you could use just the barebones solidus_core gem and perhaps combine it with your own custom frontend instead of using solidus_frontend.

This gave me the impression that the solidus_backend should just work without having solidus_frontend installed. That way I could later implement the frontend which would indeed have the layout you described but in my initial setup with just one option for a product so no need for a cart.

[tvdeyen]

Does that mean then that solidus_auth_devise actually has a dependency on solidus_frontend?

No it depends on a method call current_spree_user to authenticate with. You can create you're own authentication. The only thing you need to make sure is that it provides a current_spree_user method in you're application controller for instance.

[jasonfb]

I agree with @Kingdutch this seems counter-intuitive and the dependency should be reversed (that is, solidus_auth_devise should implement current_spree_user and solidus_front_end should depend on _anyone_ implementing it, and by _anyone_ I mean the auth strategy of your choice)

@Kingdutch -- devs new to Spree/Solidus often are shocked at how much stuff seems contrary to certain common computer science principles, often having to shrug it off as a leftover or hold-over or hack (which this sounds to me like). For the time being maybe try including the spree_frontend code even if you don't plan to use it, and just not put any of those Spree routes in your routes file to hide all of Spree's native front-end routes, this would be the path of least resistance. Then again, maybe you can be the one to fix it via pull request(s).

[ezekg]

What's the status on this? Like @Kingdutch, I assumed you could implement your own front-end but that doesn't actually seem to be the case, even though the readme makes it sound like it is.

[gbrlcustodio]

Does it still unsolved?

[ericsaupe]

@gcmartins93 this is still unresolved. I just tested it using the original steps and came up with the same error.

[mamhoff]

Seems like this issue is still up for grabs!

[mdesantis]

Hey there, it seems to be fixed now; this is what I get reproducing the steps above:

Solidus gems versions as below:

> bundle show | grep solidus
  * solidus_api (2.8.2)
  * solidus_auth_devise (2.1.0)
  * solidus_backend (2.8.2)
  * solidus_core (2.8.2)
  * solidus_support (0.2.2)

[jacobherrington]

Thanks @mdesantis I think this can be safely closed.