I tried this: http://blog.blazingcloud.net/2011/01/08/devise-authentication-in-rails-3/
Where to add the dependencies as shown?
//sorry, I changed my question, after you answered! Sorry for this.
Bundler is mainly to manage your gem dependencies. so when you add devise to your Gemfile and run bundle install, it installs its run time dependencies as well. devise gem depends upon bcrypt-ruby,warden. This link provides you details about the dependencies of devise gem.
You don't need to set up any of them. That will happen automatically for you once you add devise.
Related
I'm trying to wrap my head around why a problem I was struggling with is now magically resolved.
I am building a Rails app that uses Spotify OAuth (via the rspotify gem) and became stuck on the exact issue described here. After spinning my wheels, I finally came across this comment, recommending that I explicitly add the omniauth gem to my Gemfile.
Now, this omniauth gem was already a dependency in Gemfile.lock for omniauth-oauth2 specifically. As the linked comment recommends, I included omniauth in my Gemfile and now my problem is seemingly resolved, but I don't really know why.
Why does including a gem in your Gemfile resolve a railtie issue in this case?
If a gem is already installed as a dependency (according to Gemfile.lock) isn't that evidence that a given gem was installed? If, say, gem_foo is listed as a dependency in Gemfile.lock and I add gem_foo in Gemfile and then run Bundler, how does Rails interpret this change?
This is related to how gems are loaded by bundler. Bundler.require requires gems listed in Gemfile but does not require its dependecy. Its upto the library to require/load its dependency.
The mentioned issue happens when omniauth is not added explicitly to Gemfile, hence bundler does not require it.
But since omniauth-rails_csrf_protection assumes the ominauth is already required, it errors out when user only adds omniauth-rails_csrf_protection but does not add omniauth to Gemfile.
I have created a possible fix for the issue https://github.com/cookpad/omniauth-rails_csrf_protection/pull/13
UPDATE: The is fix has been merged in the gem repo.
ruby '2.6.3'
gem 'rails', '~> 6.0.2', '>= 6.0.2.1'
I'm using the latest omniauth-facebook and devise together
Gemfile:
gem 'devise'
gem 'omniauth-facebook'
Getting this error when starting the server:
/versions/2.6.3/lib/ruby/gems/2.6.0/gems/devise-4.7.3/lib/devise/omniauth.rb:12:in `': You are using an old OmniAuth version, please ensure you have 1.0.0.pr2 version or later installed. (RuntimeError)
The problem is that if I try to use older omniauth-facebook versions the server works but then the Facebook authentication stops working properly (e.g. fails including emails despite
scope: 'email', info_fields: 'email,name'
in devise.rb. )
I have tried many different version combinations of omniauth-facebook and devise. Either Facebook-authentication stops working properly or the server fails (see above).
Using
gem 'devise', github: 'heartcombo/devise', branch: 'ca-omniauth-2'
In Gemfile will fix the problem, awaiting a merge.
Updated my answer based on Carlos answer below, I was in a rush when I posted this using ref.
Thank You, Carlos for maintaining Devise.
This is Carlos, Devise maintainer. Please keep an eye on that Pull Request linked above, I just shared how you can test it in your app there:
I'd recommend using the branch ref instead of the git ref directly:
gem 'devise', github: 'heartcombo/devise', branch: 'ca-omniauth-2'
With that you should be able to run bundle update devise omniauth which should hopefully give you OmniAuth 2 and this Devise branch. That should allow the app to boot up.
Lastly, if you've copied over the Devise shared links on your app, or if you have your own links to initiate the OmniAuth authentication flow, you need to make sure they're changed to use a form. (you can do that by using link_to with method: :post option for example, or using button_to, if that works for your app.) Please note that this is a requirement change in how OmniAuth work due to a security issue, read more.
If you run into any issues please comment back in GitHub, and we'll work to get them resolved soon so we can release a new Devise version that fully supports OmniAuth 2. Thanks.
Devise 4.8.0 (shipped yesterday) resolves this.
Please downgrade OmniAuth:
gem "omniauth", "~> 1.9.1"
That's worked for me.
I'm pretty sure the issue is related to this devise PR, https://github.com/heartcombo/devise/pull/5327
Devise currently has a version check that doesn't include OmaniAuth > 1.x.x
I would like to use gems 'better_errors' and 'binding_of_caller' for my debugging in rails app, but i DON'T want to include those in Gemfile. Is it possible to do? My first thought was to simply
gem install better_errors
gem install binding_of_caller
but it doesnt work, i mean installation finishes without problems, but thats it, gem doesnt seem to work at all when i run my app on localhost. Do I need some kind of config set, anybody?
but i DON'T want to include those in Gemfile. Is it possible to do?
Yes, it is possible. You can just download the respective directories in desire folder (ex. lib) and add that gem class in your initializer so it will be loaded at the time of starting. Configuration varies as per gem.
My first thought was to simply .... but it doesnt work,
Ofcourse, it wont. How can your rails app magically detects without knowing it that you have better way to show error. It is simply saying like you have cancer formula and doctors automatically applied that formula to there patient without you telling them. There should be some commucaition between two parties rails-app and gem so they can coordinate and work better.
Do I need some kind of config set, anybody?
Yes, explained above.
i dont want to force those gems on my coworkers. KRUKUSA any more details? // said in comment
Yes, including this gems in your rails app can do this job. This extension will be available automatically to your worked. (no force applied :P)
it looks like all you want to not show those gems to other co-worker, if so, you can use this trick with git.
To achieve this thing, first simply add the gems in your gemfile, run bundle and then make it untrackable with git. You can put Gemfile and Gemfile.lock in your .gitignore file. or you can add the first add the gems and mark it ignore with below command. Read more here
git update-index --assume-unchanged Gemfile Gemfile.lock
Another possibility would be to create your own environment and use it accordingly.
Have your own configuration for myenv:
$ cp config/environments/{development,myenv}.rb
In config/database.yml, add the environment myenv and use the same config as development:
development: &development
<rest of the code you have on config/databases.yml>
...
myenv:
<< *development
In Gemfile add your custom gems to use on your mydev group:
group :myenv do
gem 'better_errors'
gem 'binder_of_caller'
end
Run rails and rake with RAILS_ENV like this: RAILS_ENV=myenv rails c
The advantage of this approach is that you still get the updates from Gemfile from the repo, and if you need to add a gem in the Gemfile for everybody to see, you still can.
Also, nobody will see the gems you installed inside the myenv group in your Gemfile.
This two commands seem to generate practically the same thing
rails plugin new __name__
bundle gem __name__
There is a hidden detail I haven't notice?
which one do you use, and basically, why?
Thanks
They can all generate a barebone gem but they are different.
rails plugin new could generate a dummy app inside test, and a basic test_helper, which would be very handy if you want to add some functional/integration tests in gem. You can also revise that a bit to use Rspec. bundle gem would not do that.
If you develop the gem for Rails and need such tests, rails plugin would be better. Otherwise bundle or a gem generating gem jeweller.
Plugins are more or less deprecated in favor of gems in recent versions of Rails.
As far as I can tell, running rails plugin my_gem simply creates a 'my_gem' directory in the root of your rails app.
It's not too much different from running bundle gem my_gem except that it stubs out a couple of test files, and runs bundle install.
This may be useful if you're creating a gem that's made to be run on rails - where you need a "rails environment" (see the test/dummy/app directory).
Still, if you do it this way, it appears the gem is added right into the root of your rails project. You could always move it, but if you were to run bundle gem you could do so wherever you want.
I am trying to understand the initialization process for Rails 3 plugins. I have a plugin packaged as a gem that I am including in my Gemfile for my project.
In turn, that gem specifies in its gemspec that it depends Sunspot::Rails. The gem itself gets pulled in and I can access its classes, but it doesn't appear that the railtie initialization code gets run.
However, if I add a line in my project's Gemfile for sunspot_rails directly, then the initialization code is run.
Does anyone know of a way to have my gem/plugin run the initialize code in its dependencies without having to include all of them directly in my project?
Thanks in advance.
After reading the above article and responses, I realized that I was requiring sunspot/rails instead of sunspot_rails. It's necessary to require sunspot_rails because that in turn requires the railtie (which is not automatically required as part of having the gem listed in the gemspec).
Here is a link to a very good article on the difference between gemspec and Gemfile that helped explain it all.