Using ActiveRecord's encrypt feature over rodauth's account table?

[fmborghino]

First off, thanks for rodauth-rails - really nice to use!

We're hoping to keep all our user PII encrypted, and already use Rails 7 ActiveRecord's encrypt feature for this. What we would like to do is setup our account model to use this. Am I missing something on how to have rodauth-rails make this work, or is this a feature that isn't implemented?

Here's a snippet that I think sums up what we're hoping to do:

app/models/account.rb

class Account < ApplicationRecord
  include Rodauth::Rails.model

  encrypts :email, deterministic: true, downcase: true
  ...

Hope this makes sense! Thanks for any pointers.

[janko]

First off, thanks for rodauth-rails - really nice to use!

Glad to hear that 🙂

Am I missing something on how to have rodauth-rails make this work, or is this a feature that isn't implemented?

Rodauth doesn't use Active Record models for database interaction, so that encryption setting is skipped. rodauth-rails uses the model only for rails_account method, which is just there for convenience.

I would have to check how Active Record implements its encryption, and see if Rodauth could be overridden to do the same.

[fmborghino]

Wow thanks for the quick response!

Yeah so given that rodauth works on top of Sequel, we're also experimenting with https://sequel.jeremyevans.net/rdoc-plugins/classes/Sequel/Plugins/ColumnEncryption.html to see if we can stitch together what we need, along with the ideas in here jeremyevans/rodauth#225 ... it feels like what we need is there but we're still figuring out how to assemble the parts.

Does this feel like the right direction to you?

[winstonwolff]

Hi @janko —

I'm working with @fmborghino above. We've made some progress in the direction of encrypting emails through Sequel ColumnEncryption. Here's what we're trying so far:

• change account_ds to return an Account Sequel model instead of a hash,
• change save_account to expect an Account model instead of a hash when it's saving, i.e. instead of db[accounts_table].insert(account) it does account.save

But now RodauthRails is crashing when we call rails_account—it says

undefined method `stringify_keys' for #<Account id: nil, status: "unverified", email: "[email protected]", password_hash: "$2a$12$seXUZd0xk2uf3gt6ZLPmk.tcwG3Xy44.dEHQNH9Mf8K...">

We suspect Rodauth::Rails.model is expecting a hash from Rodauth, but we've changed that to a Model with ColumnEncryption. Do you think that's the problem? Do you think we're going to have pain every step of the way with this approach?

—Winston

[janko]

Yeah, I think having the account_ds return Sequel models instead of hashes will probably break quite a few places, because that change is breaking the contract of what kind of object that dataset returns.

If you're already using Active Record as the main database library with its encryption, I don't think there is benefit in going through Sequel model encryption, because as Jeremy said, Rodauth doesn't use Sequel models.

I'm currently experimenting overriding Rodauth to use Active Record's encryption directly. I identified three general things that need to be overridden: writing encrypted email, querying encrypted email column, retrieving decrypted email. I will share something as soon as I get a working example 😉

[janko]

I answered in jeremyevans/rodauth#225 (comment), to keep the conversation in one place, as it's not strictly Rails-related (people can use Active Record with Rodauth in a Sinatra app as well).

[fmborghino]

Oh wow! You did a lot on this, thanks so much. We'll dive in with those suggestions today! (And yes, good idea to consolidate the convo over there).