NameError: `@' is not allowed as an instance variable name

[fguillen]

Expected Behavior

No error

Actual Behavior

The application works good until it doesn't any more :/

When I try to access to the website I see this error:

File "/Users/user/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/authlogic-6.4.2/lib/authlogic/session/base.rb" line 1127 in instance_variable_set
File "/Users/user/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/authlogic-6.4.2/lib/authlogic/session/base.rb" line 1127 in initialize
File "/Users/user/Development/MyApp/app/controllers/front/front_sessions_controller.rb" line 5 in new
File "/Users/user/Development/MyApp/app/controllers/front/front_sessions_controller.rb" line 5 in new

I see in the code here:

• authlogic/lib/authlogic/session/base.rb

  Line 1127 in 8e31cc0

  instance_variable_set("@#{password_field}", nil)

that password_field may be empty an there for we are executing this:

instance_variable_set("@", nil)

This is my code affected line:

def new
  @front_session = FrontSession.new
end

This is my FrontSession implementation:

class FrontSession < Authlogic::Session::Base
  authenticate_with FrontUser

  def to_key
    new_record? ? nil : [send(self.class.primary_key)]
  end

  def persisted?
    false
  end
end

This is in my FrontUser:

class FrontUser < ApplicationRecord
  acts_as_authentic do |config|
    config.crypto_provider = ::Authlogic::CryptoProviders::SCrypt
    config.session_class = FrontSession
  end

[fguillen]

I see the error is happening when there is a DB connection problem. Looks like Authlogic is expecting the connection to be properly configured and if not the case it fails with this cryptical error. It would be better if Authlogic confirms the connection is stable or at least failing with another more explanatory error message.

[la-ruby]

...I see the error is happening when there is a DB connection problem...

I saw this error and realized my server had no Postgres add-on provisioned at heroku.

jo-ytm-acpig $ heroku run rails c
 ›   Warning: heroku update available from 7.68.2 to 8.0.1.
Running rails c on ⬢ app... up, run.4985 (Basic)
Loading production environment (Rails 7.0.4)
irb(main):001:0> User.count
/app/vendor/bundle/ruby/3.0.0/bundler/gems/rails-5bebef36ade9/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:87:in `rescue in new_client': connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory (ActiveRecord::ConnectionNotEstablished)
	Is the server running locally and accepting connections on that socket?
/app/vendor/bundle/ruby/3.0.0/gems/pg-1.4.4/lib/pg/connection.rb:754:in `connect_start': connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory (PG::ConnectionBad)
	Is the server running locally and accepting connections on that socket?
irb(main):002:0> exit

[sandrods]

Having the same problem here... not sure where to begin debuging.
Any news on that front?

[quevon24]

It definitely fails if there is no connection to the database or you are missing tables. You can verify it like @la-ruby did

[wakproductions]

I ran into this error using 6.4.3 and can confirm that it was a database issue. Took a while to pinpoint the exact problem, but I had Puma server started up and running as an Ubuntu service. The DB credentials were in the environment variables initialized from the user profile, but because Puma was running as a service it could not see the environment variables. I fixed it by moving the DB credentials environment variables to a .env file and loaded by the dotenv-rails gem.

This was tricky to figure out because running Rails Console loaded the environment variables from the user profile and I couldn't tell that they were missing in the Puma server until I added special lines in the app to have them output to the Rails log. It was then I noticed the DB credentials were missing in Puma.

The error message led me down the wrong path because by looking at the source code I couldn't find figure out where Authlogic makes a DB call related to its retrieval of :password_field as shown in the stack trace. So strange.