Setting up LDAP cookie-based authentication

[colmexdev]

Hi there!

I tried setting up LDAP authentication as stated in the docs, but I couldn't make it work. First of all, is it possible yet? Or maybe I'm doing something wrong. My setup is as follows:

plugin :rodauth do
  enable :login, :logout
  login_route "login/admin"
  login_redirect "/dashboard"
  after_login do
    logger.info("Attempting to log in...")
  end
  login_view do
    scope.view("login/admin", layout: "login/login")
  end
  logout_route "close-admin"
  require_bcrypt? false
  session_key :admin
  account_session_value { account }
  account_from_login { |l| l.to_s }
  password_match? do |password|
    ldap = Net::LDAP.new host: ENV.fetch("LDAP_HOST"), port: ENV.fetch("LDAP_PORT").to_i, auth: { method: :simple, username: account, password: }
    ldap.bind
  end
end

And in Roda's tree:

class App < Roda
  # Here lies former Rodauth plugin settings
  route do |r|
    r.rodauth
    r.on "dashboard" do
      rodauth.require_login
      # More nested routes thet need to be authenticated first.
    end
  end
end

Basically, I try checking for user existance and login capabilities from the LDAP server (later on, I'll try with different bases, that's why I didn't use SimpleLdapAuthenticator gem). And, based on the logs, it seems that it is indeed validating; though once succeeded, it redirects again to the login form.

Thanks in advance!

[jeremyevans]

Does it have the same behavior if your password_match? block just returns true? That would help diagnose whether the issue is in the LDAP part or something else.

I'm not sure what session handler you are using, but you could try session_key 'admin' and see if that fixes it.

[colmexdev]

Im using Roda's sessions plugin to handle it. It worked changing the session_key from symbol to string. Thank you for pointing that.

One more question: is there a hook that runs right before require_login is specified? I'd like to check some custom values added to the sessions' hash for logging and analytics reasons, and while I solved it using a custom defined method called right before require_login, I got curious if hooks can be of any helo in this situation.

[jeremyevans]

There isn't a hook that runs before require_login. I think all of Rodauth's hooks are called in places the user doesn't have direct control over. For require_login, you are calling the method directly, so you have direct control.

If you want to add information to the sessions hash, I would recommend something like:

update_session do
  super()
  # add additional session values
end

[colmexdev]

Cool! Thanks for the clarification.

If I wanted to have a non-DB instance (say, a User class not backed by Db table) to give certain authorization level, is it possible to create an account from session or login that can be used throughout the session? I was looking at account_from_login and account_from_session, both of them define an @account instance variable, but the way it is used in the LDAP example, it uses a block and I don't know if it would be correct to define something like account_from_login { @account = User.new(account) } or if there's another way to do it.

[jeremyevans]

That looks like it should work, but you want both account_from_login and account_from_session to return the same type of object, and you'll need to adjust account_session_value appropriately.