Custom authentication #1512

Closed
wants to merge 303 commits into from
@radar
Spree Commerce member

Another month, another large pull request. Not content with ripping out pieces from the components of Spree, I decided to rip out an entire component. Particularly, the auth component.

The reason for this was because attempting to use Spree in application that already had authentication proved troublesome. By ripping this component out and adding in hooks (Spree.user_class and Spree.current_user_method) to core for user things, we can allow for people to embed Spree into their applications and to use their application's authentication setup, rather than forcing them to use Devise.

I am about to start working on a guide to document how you would go about doing this, and hopefully that would make it more clear how you could integrate Spree and the custom authentication from an application.

Consider this the first draft for the custom authentication solution.

@tvdeyen
Spree Commerce member

YEEEEEEEEEEES! Epic! This is one huuge step!
❤️ @radar

@Spaceghost

@radar You are a gentleman and a scoundrel. I salute you.

@BDQ
Spree Commerce member
BDQ commented May 8, 2012

This looks great, I love pull requests that delete 23 times more code than they add!

There's a couple of points we need to address:

1) For people who don't have an existing application, and just want a "store", will still need to provide all the basics (like signup, login, password reset, etc). I think we need an external extension that provides this, and the spree installer should prompt to install or not (default to yes).

3) How do we handle migrations for existing stores? I've been thinking we should start to include an upgrade generator with each release that can make some of the necessary changes, in this case install the external auth extension.

@radar
Spree Commerce member

@BDQ:

For people who just want a store and the basics, there's radar/spree_auth_devise for that. We could make that an official extension as you suggest and prompt to install it or not. There's some failing tests on that project that I've not gotten around to fixing just yet.

For existing stores, all they'll need to do is use the spree_auth_devise gem. It will work as it did before. At least, that is the intention.

@jipiboily

Love you @radar.

@BDQ: what happened to your #2? 1 and 3 huh? :)

Point 3 will be quite important to manage in some way. +1 for the upgrade generator.

@robyurkowski

This is astounding work, Radar.

@BDQ
Spree Commerce member
BDQ commented May 8, 2012

@radar - I'd say make that an official extension, and please do include it in the install generator.

@jipiboily - I never liked #2.

@knewter

Hot damn, this is huge. 👍

@JDutil
Spree Commerce member

👍

@radar
Spree Commerce member

All the tests are passing on Travis for this branch. I will do the guide writeup this afternoon and then people can look through it and suggest improvements.

@radar
Spree Commerce member

First draft of authentication guide is here. spree_auth_devise has one failing test (to do with the user signup promotion) and if someone else wants to be a champ and solve that before I do, that'd be awesome.

Other than that, I can't think of anything else that needs to go into this pull request. Can you (@schof, @bdq, @lbrapid, @cmar, @GeekOnCoffeee) look over this and see if everything makes sense please?

@BDQ BDQ and 1 other commented on an outdated diff May 10, 2012
dash/app/models/spree/user_decorator.rb
@@ -0,0 +1,5 @@
+if Spree.user_class
@BDQ
Spree Commerce member
BDQ added a note May 10, 2012

Why does dash need this decorator?

@radar
Spree Commerce member
radar added a note May 22, 2012

The tests were complaining if it didn't have it, and so I added it. One of dash's tests checks for roles iirc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@BDQ BDQ commented on the diff May 10, 2012
core/app/models/spree/order.rb
self.email = user.email if self.user and not user.anonymous?
- self.user ||= User.anonymous!
@BDQ
Spree Commerce member
BDQ added a note May 10, 2012

So we're no longer creating an anonymous user for all orders? This may cause problems as I expect some stuff maybe expect an order to have a user?

@radar
Spree Commerce member
radar added a note May 22, 2012

I don't think this is the case. Users are now prompted to enter an email when they create an order (if they're not authenticated). Is there a case where an order could be created anonymously?

@radar
Spree Commerce member
radar added a note May 23, 2012

Just checked in admin/orders backend and that doesn't seem to error out. Order emails are associated with order.email, not order.user

@BDQ
Spree Commerce member
BDQ added a note May 23, 2012

Previously, when an item was added to a cart and there was no current_order, an anonymous user was created with that new order (I was never a fan of that approach, but @schof had reasons for it).

@tvdeyen
Spree Commerce member
@JDutil
Spree Commerce member
JDutil added a note May 23, 2012

I agree it would be nice to use a single dummy user record if necessary instead of a new user record for every guest order. Perhaps the new user record for guest orders has something to do with promotions though?

@schof
Spree Commerce member
schof added a note May 23, 2012

One of the original reasons for having an anonymous order was user token access (so users were able to access their own in progress and completed orders only.) IIRC we moved the token to order now so maybe its safe to contemplate this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@BDQ
Spree Commerce member

I've got a few more comments:

1) The sandbox application seems borked, you can't access the admin UI.

undefined local variable or method `spree_signup_path'

2) I commented on dash user_decorator.rb but it seems all core engines have the same basic decorator adding the habtm association at least, why is that? Feel like the association should be in core, if it's needed for all extensions.

3) I'm concerned that the sample data is now incomplete, specifically the order won't have any user data which will cause problems with the admin/orders ui.

@radar radar WIP: adding spree_auth_devise to sandbox Gemfile
This is currently NOT working. Will investigate lateR
a8edc5c
@radar radar Remove sandbox_generator, replace with Rails template
The rails template's code is much simpler and allows us to enforce specific gem requirements that the dummy application should never have.

This fixes the sandbox's requirement of spree_signup_path as pointed out by BDQ here: #1512 (comment)
948f0ba
@radar
Spree Commerce member

BDQ: 1) on your list addressed by @948f0ba. I think we could probably find a better spot for sandbox.rb than just chucking it at root. Perhaps lib?

@parndt

What about invoking it?

Spree Commerce member

What difference does it make?

@beneggett

Per my conversation with @radar in IRC, I'm interested and available for testing once this is getting close to being released in the master branch; as I'm planning on implementing it.

@radar
Spree Commerce member

Regarding spree_social, this pull request will break this extension, but not in a terrible way.

The first problem is the user_decorator file. This will need to be changed to decorate Spree.user_class rather than Spree::User. Pretty easy change.

Secondly, user_authentication.rb will need to be changed from this:

 belongs_to :user, :class_name => Spree.user_class.to_s

Thirdly, the calls to current_user throughout the controllers will need to be replaced with spree_current_user calls instead.

Fourthly, spree.login_path references will need to change to spree_login_path. We may need to add in a route for the account path too...

Finally, the modifications to Spree::UserRegistrationsController will need to be placed elsewhere, but I don't know where for now.

@tvdeyen
Spree Commerce member
radar and others added some commits May 28, 2012
@radar radar to_prepare method is on Spree::Core::Engine.config, not Spree::Core::…
…Engine
8a35b5b
@radar radar Remove spree_auth_devise and devise_encryptable from sandbox 459a8d5
@radar radar Redirect to either spree_login_path (if it exists) or root_path for s…
…tore_location
ad9b3df
@radar radar Stub authorization for admin controllers 3263215
@radar radar Move associate_user out of ControllerHelpers, into CheckoutController
The only place this is necessary is in CheckoutController's actions. This now runs as a before_filter
6184c3c
@radar radar Move clone_billing_address to be with other before_validation call in…
… Order model

This was previously ~250 lines down in the model
40b1f9e
@radar radar Move controller helpers into Spree::AuthenticationHelpers module 4812d22
@radar radar Add debugger gem f9018e8
@radar radar Remove debug from checkout_controller 632b5d2
@radar radar Only use spree_account_path in orders/show if available ae99482
@radar radar Stub authorization in correct OrdersController 2bae6e1
@radar radar Re-add as_null_object to Order model stub in CheckoutController spec …
…to fix broken tests
b8636d1
@radar radar Move regression test for #538 into its own controller spec
Read the comment in the spec
f006e01
@radar radar Added stub_authorization! for request specs
This is used to give the current request spec permission to perform any and all admin actions
405d5bd
@JDutil JDutil Only use Spree::Responder if needed for the current controller.
Stops preventing defined_response.call when any spree_responders are
defined. [fixes #1301]

Merges #1515
2db1929
@jumph4x jumph4x Changing Admin AJAX urls in the _head partial to use relative paths. #… 0e86ce5
@deJaVisions deJaVisions Updated @user.authentication_token.present? check, and print out to u…
…se @user.api_key instead in the api_fields partial. Not sure why @user_authentication_token was being used instead.

[Fixes #1521]

Merges #1522
1cc01fd
cmar unnest images api from variants and products, use viewable_id instead 6e3beec
Andrea Schiavini Per item calculator should only apply to matching products
Fixes #1524

Merges #1526
521f026
cmar fixed travis syntax error, unexpected tSYMBEG, expecting tAMPER 8e263b6
@JDutil JDutil Edge version is 1.2.0.beta
[Fixes #1530]
c193396
@shadchnev shadchnev passing the currency code from payment method preferences to the gateway
[fixes #1528]
26df00b
cmar using lambda change count for image tests 1fbb331
Matthias Wagner Removed useless hidden submit button
[Fixes #1535] [Fixes #1538]
9de1d8d
@JDutil JDutil Allow pagination of product search results.
[Fixes #1539]
a84b5fd
@maximkulkin maximkulkin Properly escape permalink when checking it for uniqueness.
[Fixes #1505]
2bbe70a
@GeekOnCoffee GeekOnCoffee Adding Load Path to API to fix #1536 d115953
@beneggett beneggett Locked devise at version 2.0.x, as 2.1 just launched and breaks auth.…
… Devise just launched 2.1, running bundle update breaks Spree Auth; locking devise to 2.0.x.

Will update to Spree to use Devise 2.1 as 2.1 clears RC process and docs are released, etc.. See http://rubygems.org/gems/devise/ for details
dfba349
@radar radar Refactor variant_images to return a scope, not an Array
Conflicts:

	core/app/models/spree/product.rb
77df79c
@alexdowad alexdowad Fix for problem with Product#images for newly created Products 4831f0a
@GeekOnCoffee GeekOnCoffee removing redundant view_path include 558f8c9
@alexdowad alexdowad Use new_record? rather than id.nil? cbf20f5
@JDutil JDutil Use phone_field helper for semantic markup.
[Fixes #1556]
7f573d1
@mscottford mscottford Removes the default rake task 51b2921
@mscottford mscottford Updates README to reflect the removal of the default and all_tests ra…
…ke tasks.

[Fixes #1557]
094316f
@JDutil JDutil [Merges 1559] Fix inconsistent required classes and style red.
Conflicts:

	core/app/views/spree/checkout/_address.html.erb
1055d85
@peterberkenbosch peterberkenbosch require 'spree/core' is needed to isolate the Spree namespace. fixes #… 8e72d68
@parndt parndt Stops spreecat joining and parting the channel by sending a notice to…
… the channel instead.

[Fixes #1560]
978f969
@cyu cyu Account for purchased units in stock validation
Merges #1525
2859de2
@citrus citrus add attr_accessible for `user_ids_string` in user promotion rule 8796502
Andrea Schiavini Per-item calculator now only applies to products matching the promotion
Fixes #1526
6941597
@radar radar Ensure that order confirmation and cancel emails do not include ineli…
…gible adjustments

Fixes #1555
e38893b
@citrus citrus default order adjustments to be ordered by created_at asc
Fixes #1549
dab7e8d
@radar radar Use has_role? not admin? to check for user admin ability in ProductsC…
…ontrollerDecorator

Fixes #1562
be3388d
@radar radar [promo] Clean up code in order decorator from #1526 26c80e7
@radar radar [promo] Check for calculator on adjustment.originator in update_adjus…
…tments_with_promotion_listing before checking its type

Related up to #1526
fe71cd0
@radar radar [promo] massive cleanup of order_spec.rb
set up order spec right so that adjustments have an originator

Fixes breakages brought in by #1526
40c118e
@radar radar Correct order amounts now that changes from #1526 are in place 1d106d0
@radar radar Remove old install tasks edcadcf
@radar radar Correct order calculation in promotion_adjustments_spec
40 + 20 - 10 + 10 = 60, not 55
68705b4
Daniel verify Image Magick installed (only on Macs)
references #1511

Merges #1533
101d4db
@jeebster jeebster [api] Add product properties as child of Products
Merges #1568
a93289d
@GeekOnCoffee GeekOnCoffee Adjusting Product Count_On_Hand in seed data to sync with variant data
[Fixes #1569]
6e2bfe9
@GeekOnCoffee GeekOnCoffee Adding ProductOptionTypes to seed data
Merges #1577
40b5d7d
Ryan Bigg and Philip Arndt Specify :group => :all so that spree.assets.precompile runs even when…
… initialize_on_precompile is false

Improved formatting: the line was way too long and now we don't need quotes or commas

Merges #1576

No need for add_assets_to_precompile_list method in Core::Engine now
2c3aa0f
@radar radar Improve Imagemagick code from #1533 to check on all operating systems c25c5d0
@parndt parndt Removed is_ from methods. Added windows? and linux?. Adjusted Imagema…
…gick check to verify Linux in the same way as Mac.

Closes #1578
bd539cd
@parndt parndt Tidying up of spree_cmd/installer.rb code
Closes #1579
9ac1182
@ademidov ademidov .search methods changed to .ransack
Closes #1532
7723b14
@tneems tneems Allow voiding of transactions on gateways supporting profiles
Closes #1546
8939921
@JDutil JDutil Explicitly nest promotion classes.
Fixes #1548
215dec3
@radar radar Remove old site generator 705da27
devilcoders and others added some commits May 30, 2012
@devilcoders devilcoders Remove additional padding on 'Similar products' 8e38444
@radar radar Light cleanup of checkout_spec a881c70
@radar radar Specify :class_name argument for all belongs_to (and some has_many) a…
…ssociations in core and promo
3d55dab
@radar radar Fix typo in class_name arg for address association in Shipment 59b710b
@radar radar Correct class name for shipping_method association in Order model 4b499b8
cmar zones api
Merges #1615
c9f2419
@joneslee85 joneslee85 Rename Creditcard to Credit Card
[Fixes #1605]
cfad733
@GeekOnCoffee GeekOnCoffee regexing out html in product description before it gets truncated
[Fixes #1620]
8f53742
@joneslee85 joneslee85 Update Payment source_type to Spree::CreditCard in migration 4851317
@radar radar Do not include deleted products by default
Allow them to be included by passing a show_deleted parameter

Fixes #1626
934e3e6
Ted Lilley Make cancel email match changes in confirm email made by Radar in 5be… 36b5469
@GeekOnCoffee GeekOnCoffee fixing product_option_types seed
Fixes #1623
52de2ee
@radar radar Only allow admins to pass show_deleted parameter
Relates to #1626
8c3f5a1
@radar radar Only support Rails 3.2.5 due to Active Record vulnerability in all ea…
…rlier versions

This was brought up here in #807:
#807 (comment)
b96d58f
@radar radar Reverse order of isolate_namespace and engine_name call in extension …
…engine template

This is a potential fix for #1580
d4d7e97
@radar radar Remove commented-out ProductGroup code from search/base a2e6030
@radar radar Soft-delete shipping methods when they are deleted through admin backend
Fixes #1240
eac66f6
@iloveitaly iloveitaly Adding classes to cart td and th for easier css styling
Closes #1281
ed4ab19
@radar radar Fix issue where removing a single line item from a promotion ended up
removing ALL the line items from it

Fixes #1274
c25de29
@JDutil JDutil Correct typo in extension installer. Skiping => Skipping.
[Fixes #1633]
d8cfe97
@LBRapid LBRapid Remove credit total from Orders. It is not being used anymore. 210b02f
@cwise cwise Use correct query parameter for sorting in zones, orders and reports
admin controllers

Fixes #1630
8d6ab7e
@radar radar Make randomly failing configuration/states spec pending until Travis …
…can be figured out
a6b2e82
@radar radar Refactor promotions.js
Defining on jQuery events, removing functions that are only called to initialize state on document ready and removing useless $ from before some variables
07b3e03
@radar radar use on and not live in cart.js eea86ab
@radar radar Change live usage in admin.js.erb to on
live is deprecated in new versions of jQuery
c64df3c
@radar radar Change live call for observe_field elements to use on, not live c3cdf1c
@radar radar Replace remaining uses of delegate/live in JavaScript in core with on…
… instead
f67d22f
@radar radar Revert "Refactor promotions.js"
This broke the promotion adjustments.

I will investigate this tomorrow morning.

This reverts commit f923ab2.

Conflicts:

	promo/app/assets/javascripts/admin/promotions.js

Conflicts:

	promo/app/assets/javascripts/admin/promotions.js
595115c
@schof schof Do not allow state to be mass-assigned. State should only be changed
via the state machine.
265c99e
@radar radar Ensure that an extension can have a model generated in it
Adds a regression test for #1580
d67a8ae
@radar radar Ensure that migrations are created within the dummy app
This is a regression test for #1580
33dc896
@radar radar Add path to spree_core to cmd's Gemfile 4ac1693
@radar radar Fix specs that were relying on shipment's state being mass-assignable 59ab4fa
@radar radar Rip out auth component, provide facilities for custom authentication 9f466be
@radar radar Use Spree.user_class in Spree::Promotion::Rules::User f07c264
@radar radar Remove sign up spec from promotion adjustments and switch over from u…
…sing sign_in_as! now that auth is gone
5758678
Andrea Schiavini Per-item calculator now only applies to products matching the promotion
Fixes #1526
67c39c0
@radar radar Correct order amounts now that changes from #1526 are in place 9208428
@radar radar Add mistakenly removed helpers from promotion_adjustments_spec back 5f3f0ae
@radar radar Add missing stub_authorization! call to missing_products_controller_s…
…pec to fix broken spec
d384523
@radar radar Add stub_authorization to admin/shipping_methods controller spec d6950a2
@radar radar Remove misplaced assertion from promotion_adjustments_spec 42c6894
@radar radar Revert "Add path to spree_core to cmd's Gemfile"
This reverts commit 4ac1693.
27c7756
@radar radar Revert "Ensure that migrations are created within the dummy app"
This reverts commit 33dc896.
90992d9
@radar radar Revert "Ensure that an extension can have a model generated in it"
This reverts commit d67a8ae.
e5f478a
@radar radar Move Sass variables into overridable file
Fixes #1641

This will allow designers to customize the variables that Spree uses, while still keeping the base rules inside of screen.css.scss
4ea6ad8
@laspluviosillas

Can't get this to work in vanilla sandbox with Radar's spree_auth_devise gem. Using a clean gemset, here are exact the steps I took.

gem install bundler
git clone https://github.com/spree/spree.git
git checkout auth-take-two
bundle
bundle exec rake sandbox && cd sandbox
bundle
rails s

At this point, everything is fine, but obviously there's no way to log in, since there's no auth solution in.

If, from here, I stop the server, add the spree_auth_devise into my Gemfile, run bundle, then run rails s again, the app starts giving me the following error:

undefined local variable or method `spree_current_user' for #<#<Class:0x007fa3b16d13a0>:0x007fa3b16ccf80>

=== full pastie ===

Been trying to debug, but haven't gotten anywhere so far. Just know that using the incredibly hacky <% spree_current_user = current_user %> half fixes the problem (but creates a whole wide array of other problems, as expected).

UPDATE::
I get the same problem when trying to upgrade an existing installation to auth-take-two

@BDQ
Spree Commerce member
BDQ commented Jun 8, 2012

I tried installing this branch into a demo rails3 / devise app and hit a lot of problems with the migrations:

See:

https://gist.github.com/2898178
https://gist.github.com/05c572240578c97e36ea
https://gist.github.com/2898218

After removing each one, I was able to migrate successfully.

I ran the generator as per the guide, and migrated again all ok.

Finally, I had to edit Spree::AuthenticationHelpers and change the current_person to current_user and all worked!

I did notice that no login / logout links were appearing in the spree layouts?

@laspluviosillas

@BDQ I have a question. Did you use the spree_auth_devise gem @radar developed, or did you use a vanilla install of devise?

When I tried, the migrations didn't seem to fail (unless they failed silently), but I had the problem I mentioned above.

@rohitnair

@BDQ The login links appear if you follow step 5 in the guide. There were a few other changes I made, mainly in step 3. Devise already provides methods that expose the login/logout/signup paths, so you don't need to define them explicitly in your routes.rb as mentioned in the guide. This is what my lib/spree/authentication_helpers.rb looks like

https://gist.github.com/2898445

I've made no changes to my routes.rb.

There is one other change required in Step 5, since the logout path needs to be an HTTP DELETE. This is how my app/views/spree/shared/_login_bar.html.erb file looks like

https://gist.github.com/2898480

@BDQ
Spree Commerce member
BDQ commented Jun 9, 2012

@laspluviosillas I was using this app as my test application: https://github.com/RailsApps/rails3-devise-rspec-cucumber so I wasn't using spree_auth_devise

@rohitnair I missed Step 5 but that makes perfect sense now, thanks for point it out.

@radar
Spree Commerce member

@BDQ: I've fixed up those migrations and the AuthenticationHelper typo. You can see the changes in the last four commits just above this message.

@laspluviosillas Thanks for trying this out. I'm going to set up a new app with spree_auth_devise right now and see if I can replicate the problem that you're seeing.

@radar
Spree Commerce member

@rohitnair Thanks for bringing up the issue about the DELETE method needed for the logout link. I've fixed this in spree/spree-guides@cbf8d13 now.

@radar
Spree Commerce member

@laspluviosillas I've updated spree-auth-devise now with spree/spree_auth_devise@beff51c and spree/spree_auth_devise@d3413ea commits. It appears that the sandbox now works for me. Could you please try it out and validate this as well, just for a second opinion?

@laspluviosillas

It works! Time to test other things as well, cheers.

@radar
Spree Commerce member

Excellent, thanks for testing :)

@laspluviosillas

Went to try things out with sorcery. Failing at the rails g spree:custom_user User step.

link to pastebin

@radar
Spree Commerce member

Does your application contain a User class? Can you put the example app on GitHub somewhere so I can have a tinker? Also, come join #spree on Freenode.

@laspluviosillas

I was about to delete my post. Yes, that's exactly right. I was doing this before creating my user Model. facepalm. Always got to do a quick check at the error before knee jerk response. Sorry about that.

@radar
Spree Commerce member

We should probably check for the constant before then and show an error message telling the person to make sure they're referencing the right constant. 99% of people don't read Giant Error Messages of Doom.

Also: 90% of statistics are made up on the spot.

@laspluviosillas

I know testing is more valuable right now than extra features, but would a default view generator be useful? It could just output the view code defined at the end of this guide. I could code it up.

@laspluviosillas

Okay, I was able to get this all setup with sorcery. Awesome stuff. The biggest stumbling block for me by far was understanding how to create custom controllers that would integrate into the "spree flow," so to speak. The solution is quite simple, which is to have your custom controllers inherit from Spree::BaseController, and put your respective routes in a Spree::Core::Engine.routes.prepend do block.

I'll add a pull request to the customization guides, but it would be good to reference this bit inside the actual custom authentication guide as well as I suspect 90% of users are going to want their custom login pages to integrate into the spree flow and automatically inherit the spree layout, since authentication is a core the system itself and not just a custom addon page. (That's a made up statistic as well.)

This is nothing more than a nitpick, but in the custom auth documentation, there is this code block at the end:

      def spree_current_user
        current_user
      end

      def spree_login_path
        main_app.login_path
      end

      def spree_signup_path
        main_app.signup_path
      end

      def spree_logout_path
        main_app.logout_path
      end

Why do the last 3 functions have main_app by default but the first one doesn't? Maybe Devise is different, but my experience with Sorcery is that if I did have my controllers inherit from Spree::BaseController, all the functions would be without the main_app prefix. On the other hand, if I left my controllers inherting from ApplicationController, all the functions would require the main_app prefix to work. It was trivial for me to figure out, but someone else might get confused.

@JDutil
Spree Commerce member

@laspluviosillas I believe the last issue your referring to with the main_app prefixes is because the first method is not a routing method. It is asking for a user object rather than routing path.

The spree_current_user method is to return the "Current User". The other 3 methods are asking to return a URL path. so the first method is returning a user object and the the other 3 methods are returning a route. The "main_app" reference means your main applications routes. Not sure why they chose that naming convention, but it makes sense for the most part.

@radar
Spree Commerce member

Thanks @jdutil for beating me to it! Here's the response I typed up before I saw his reply:


I am not sure I understand this. Why do you need to integrate with the Spree flow? Authentication should sit outside the context of Spree and then if it's available Spree should then hook back into it. It shouldn't require you to hook into Spree::BaseController at all, or draw on Spree::Core::Engine's routes. What's making you do that?

Regarding the helpers, current_user is a typical method that is available everywhere, made available by Devise/Sorcery/whatever inside of ApplicationController and friends. The other methods are routing methods, and due to how Rails engines are defined, you need to tell Rails in what context the routes can be found. By default, Rails will look in the current engine's routes for it. By putting main_app up front, we tell it expressly that the routes are located in the application.

I explain that (and a lot of other things about engines) in my engines screencast

@JDutil
Spree Commerce member

@radar I think the work on this is great, but I am still a bit hesitant about removing the auth component altogether. I think removing altogether was great for working out the issues with decoupling the components, but should that be the final solution? I almost think that spree_auth_devise should live on as part of "spree". Simply because a bulk of users will just want things to work out of the box, but it is great to offer the option to choose another auth source.

I'm just thinking that including spree_auth as part of spree may have prevented fully understanding all of the issues and solutions that were required to truly decouple the gems. It still may be beneficial to keep the auth gem as part of spree though for new users. Either way I'm glad the work was done, and think a lot of benefit will come from this. I'm just not sure breaking into its own repo will be the best option, but at the least it should prevent coupling by accident and raise errors w/decoupling sooner I would expect by separating the libraries.

@JDutil
Spree Commerce member

I should add that a big reason I am hesitant to break into it's own repo is that I've seen a lot of spree extensions fall behind the main platform. So while I think breaking auth out on it's own is great for the decoupling of the project I'm worried that it could cause the auth portion to fall behind the rest of the project as some extensions do.

@laspluviosillas

@radar I want my login page to fit inside of the standard spree_application.html.erb layout. The spree_application.html.erb layout use a few variables/functions that are only available if the controller using that layout inherits from Spree::BaseController. I assume some other users would want to have their login page inside the spree layout as well.

Am I doing things massively the wrong way? That's 99% probable.

The routes bit was my own stupidity, so never mind on that account.

@radar
Spree Commerce member

@radar I think the work on this is great, but I am still a bit hesitant about removing the auth component altogether. I think removing altogether was great for working out the issues with decoupling the components, but should that be the final solution? I almost think that spree_auth_devise should live on as part of "spree". Simply because a bulk of users will just want things to work out of the box, but it is great to offer the option to choose another auth source.

I'm just thinking that including spree_auth as part of spree may have prevented fully understanding all of the issues and solutions that were required to truly decouple the gems. It still may be beneficial to keep the auth gem as part of spree though for new users. Either way I'm glad the work was done, and think a lot of benefit will come from this. I'm just not sure breaking into its own repo will be the best option, but at the least it should prevent coupling by accident and raise errors w/decoupling sooner I would expect by separating the libraries.

New users are prompted if they want to install the default authentication option as part of the installation process of Spree. If they select the default option of "Yes, please install this thing", then Spree will work (for all intents and purposes) exactly as it does now.

If they select "no", then, well... that's a different story. There's some differences involved, and that option is only for people who know what they're doing after they've read the authentication guide.

If there are errors introduced by this decoupling, I would have expected them to have appeared by now. Breaking the authentication into its own repo is the best way to go about this, as the auth component is now going to be maintained completely separately from the core components. This means that we would be able to do a new release of the auth extension without having to do another release of the remaining components, or vice versa.

It's my super-strong opinion that auth should've never been a part of an engine-ized Spree (or any engine, for that matter), as it's a concern of the application how it decides how users will authenticate against its system. This is the best solution I have come up with in my discussions with a lot of people on this issue. There's just simply too many differing factors in authentication systems these days to lock people to using a specific one.

I should add that a big reason I am hesitant to break into it's own repo is that I've seen a lot of spree extensions fall behind the main platform. So while I think breaking auth out on it's own is great for the decoupling of the project I'm worried that it could cause the auth portion to fall behind the rest of the project as some extensions do.

The extensions that have fallen behind need issues posted on them so that we know that a) people are actually using them and we should maintain them still and kinda related b) so we know that they're broken by newer releases and they need attention now. With the exception of spree_paypal_express, I can't think of any other official extension which has lagged terribly behind.

We won't let that happen to spree_auth_devise because it's a neat, easily-maintainable part of Spree that's critical to the default setup of Spree. Without it, Spree would be broken and that would reflect poorly on us.

@radar
Spree Commerce member

@radar I want my login page to fit inside of the standard spree_application.html.erb layout. The spree_application.html.erb layout use a few variables/functions that are only available if the controller using that layout inherits from Spree::BaseController. I assume some other users would want to have their login page inside the spree layout as well.

Am I doing things massively the wrong way? That's 99% probable.

I hadn't actually considered that people would put their login form inside of Spree's page, but that makes sense. What are the issues that you're running into regarding that? Perhaps we can work out a cleaner way to do that.

@laspluviosillas

@radar
What's required to get any page to use spree_application.html.erb layout is that the controller (in my app that's SessionsController) inherit from Spree::BaseController instead of the standard ApplicationController. Here's the catch:

If your controller inherits from Spree::BaseController, then any routes you want your controller to use that are defined in your main application namespace have to be prepended with main_app. just like in the AuthenticationHelpers file. It makes using gems that automatically generate routes such as simple_form harder, so I half retract what I said about routing.

What are the issues that you're running into regarding that? Perhaps we can work out a cleaner way to do that.

It's not a huge deal in my opinion to inherit from Spree::BaseController, but the most annoying issue it is that I believe you're putting yourself inside the spree namespace when you do that (but not sure). It'd obviously be better if there were a way to keep your controller in the default namespace while having access to the spree layouts, but I'm not sure if this is possible.

Whatever the "official solution" is, I care about having some section in the guides that deals with this scenario. I'll more than happily [attempt to] write it myself, but I'll hold off on the writing until you confirm what the best solution to this scenario is.

@laspluviosillas

@radar

Apologies for flooding your inbox! But, I believe I have discovered another (more critical) issue. The last line of authentication_helpers.rb

ApplicationController.send :include, Spree::AuthenticationHelpers

Is only called when server boots up. As a result, if you do a save to any controller in development mode, when the controllers are reloaded, the Spree::AuthenticationHelpers are no longer available.

I confirmed that this is a one-load issue by making the include explicit in app controller. When my ApplicationController is explicitly set to include the AuthenticationHelpers module, the issue goes away.

@BDQ
Spree Commerce member

@radar - I've tried the latest branch with this [1] test app and I'm still having similar migration issues:

Maybe, I'm doing something wrong - could you test out installing Spree into this app and see if it works as expected for you?

[1] https://github.com/RailsApps/rails3-devise-rspec-cucumber

@radar
Spree Commerce member

I've fixed the ResizeApiKeyFields migration tonight. I'm going to run-through the guide tomorrow morning when I'm more coherent... but I think that at least fixes your problem.

@BDQ
Spree Commerce member

Looks good, I say: merge.

GREAT JOB BTW!

@radar
Spree Commerce member

This has been rebased onto master as of right now. Thanks to all who've helped out and poked and prodded the work. Great to see we've finally landed this thing!

🎈 😃

@radar radar closed this Jun 20, 2012
@greinacker

@radar just out of curiosity - when you rebased this, did you rebase your local auth-take-two branch on top of master, and then just push master (but not push auth-take-two)? I'm just wondering why the commits still exist in their original form in auth-take-two after a rebase - trying to get my head around what exactly happens when you rebase code that has already been pushed.

@radar
Spree Commerce member

I rebased auth-take-two onto master, and then did my alias gl which is effectively git pull --rebase which runs another rebase on the top of that, pulling in the changes from master.

I don't know if this is the "right" way of doing it -- usually I'd just merge, but there's a policy on this project that's "rebase or death" -- but it works for me.

@greinacker

Got it, and then after that I'm guessing you pushed master, but did not push auth-take-two...right?

@radar
Spree Commerce member

Correct. That branch is dead now. I will delete it.

@greinacker

Cool, that clears up my question. Thanks!

@amacneil

In case anyone else lands here trying to work out how to integrate Spree and RefineryCMS authentication, I have created a sample app and documented the process here:

https://github.com/adrianmacneil/refinery_spree

@kennyadsl
Spree Commerce member

@adrianmacneil Do you think that create an extension for this integration should be possible/useful?

@radar
Spree Commerce member

@netconstructor I don't understand the question?

@radar
Spree Commerce member
@amacneil

@kennyadsl Sure thing! I moved the initializers, migrations and workarounds into a gem. It's my first ever gem, so any feedback is welcome :)

https://github.com/adrianmacneil/spree-refinery-authentication

@thiennp thiennp pushed a commit that referenced this pull request Nov 3, 2013
@radar radar Remove sandbox_generator, replace with Rails template
The rails template's code is much simpler and allows us to enforce specific gem requirements that the dummy application should never have.

This fixes the sandbox's requirement of spree_signup_path as pointed out by BDQ here: #1512 (comment)
a03fa68
@thiennp thiennp pushed a commit that referenced this pull request Nov 3, 2013
@radar radar Move common Spree.user_class role decorations into core
As per BDQ's comment here: #1512 (comment)
bd52468
@thiennp thiennp pushed a commit that referenced this pull request Nov 3, 2013
@radar radar Don't run migration code that modifies the users table at all if a Us…
…er constant exists

Based off ideas from this comment: #1512 (comment)
82db10d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment