warden | General Rack Authentication Framework | Model View Controller library

I'm not really sure what happened and why but I tried doing this on my rails container and I was no longer receiving the said error.

1. docker-compose run --rm bash
2. cd to project directory
3. bundle install

This problem was caused by our use of the Ahoy analytics library.

By default, this library tracks all page visits in your Rails app. It tries to get the current user using current_user || current_resource_owner. Because current_user was still nil when POSTing to /oauth/token, getting current_resource_owner ended up calling our Doorkeeper resource_owner_authenticator, which returned the 401 error. The source code for this is here.

This also explains why things worked as expected when unsetting the User-Agent header: with no user agent (or the user agent of e.g. curl), Ahoy treats the request as coming from a bot, and doesn't attempt to track it (source code here).

Our solution to this is to tell Ahoy to stop tracking all page views automatically by setting Ahoy.api_only = true in its configuration.

Those instructions are really useful if you’re building your own auth system, but Devise can handle this for you.

In your user model, add the :timeoutable attribute to your existing devise statement.

In config/initializers/devise.rb, you can then specify the timeout duration, e.g.:

In your project directory, try installing rails gem install rails -v 4.1.6 and removing the version from the failing gems like (liquid_markdown, gon, etc..) then try running bundle update then bundle clean --force

I think this might be an issue because all the version of these gems are locked inside your Gemfile

So... It seems this line in ActiveSupport v6.0.3.6 is calling this method in redis with 3 arguments instead of 2; exactly like the error says!

And just as I suspected, that's already been fixed in the master branch. Here was the commit that introduced the fix.

So in other words, I reckon you've found a bug in rails 6.0 working with ruby 3.0.

Additionally, it seems that this bug has already been backported into the 6.0-stable branch and, according to the comments, "will be included in Rails 6.0.4".

tl;dr: Either downgrade ruby back to 2.7, or upgrade rails to 6.1, or add to your Gemfile:

There is an open issue about that on github.

I am facing this issue because my host IP start from 34.xx.xx.xx as per code it return first subdomain it consider 34 is a first subdomain and because of that it search for 34 database and issue occcured

Gemfile.lock is a file generated from Gemfile. As such, instead of trying to merge the two branches, it's simpler and more accurate to generate a new one from its canonical source. This might result in slightly different versions, but these should cause no trouble; any version restrictions should be defined in your Gemfile.

Normally one does not commit generated files, they can change in trivial ways, but Gemfile.lock is a special case where you do want this to be the same for all builds.

Resolve any conflicts in the Gemfile. Regenerate Gemfile.lock. Add it.

for some reason he copied the code and added it himself

This is a good opportunity to explain to them why this is a bad practice when working with a team. It might be easy for them, but it's causing trouble for you. They might need instructing in how to update their work in progress. Or you might need to extract some changes into their own branch and get that merged.

The new view display a form for the current resource, which should be initialized in the action new.

Your best bet at this point, is to replace render 'new' by calling new itself, which should take care of your problem.