aws/aws-sdk-rails

DynamoDB Sessions don't work like documented

Closed this issue · 5 comments

thomaswitt commented

The DynamoDB Sessions store seems to me rather poorly implemented and/or documented.

First, the Aws::SessionStore::DynamoDB::Table.create_table does seems to ignore basically all the options set in the Rails app, it always creates a table called sessions. Browsing swiftly through the code, I don't see any possibility how the Rails configuration would land up here: https://github.com/aws/aws-sessionstore-dynamodb-ruby/blob/b9d2ce50f86076bc4bfb7d90d8637080711dd487/lib/aws/session_store/dynamo_db/table.rb#L11

Second, the generate command creates a migration, which is rather useless if you use DynamoDB, as you don't have any migrations when not using ActiveRecord.

The configuration in the initialized also seems to be rather ignored.

Rails.application.config.session_store :dynamodb_store,
  key: '_myapp_session',
  table_name: "myapp_sessions_#{Rails.env}",
  max_age: 7 * 3600 * 24,
  max_stale: 3600 * 5,
  secret_key: Rails.application.credentials.dig(:secret_key_base)

Also I keep on getting the error undefined method commit_csrf_token' for an instance of Rack::Request` when using OmniAuth.

mullermp commented

Thanks for your feedback on this. Currently we don't have bandwidth to fix any of this. Do you have any recommendations on how to fix it or would you like to start a pull request?

thomaswitt commented

@mullermp Not really interested. That'd be a bigger code change than just a few lines. I didn't really do much digging on this issue so far as the code seems quite old (e.g. still asks for Read Capacity Units and doesn't support PAY_PER_REQUEST). I might build a custom solution for my project.

Personal comment: It is truly disappointing that a giant company like AWS apparently puts very little effort into Ruby/Rails support. Unfixed things like this, very un-ruby-esque APIs, etc …Ruby doesn't get much love from you guys and seems to be nowhere near a first class citizen there.

mullermp commented

I understand where you are coming from and I appreciate your sentiment. There are only so many of us here working on the Ruby products. I can assure you that me and the Ruby SDK team are passionate about Ruby and want to improve your experiences. We are working diligently on SDK features that cover almost 400 services and their APIs - it is not trivial. I do agree more investment needs to be done in 1P gems such as this and DDB session storage, etc, but we have to balance them with other company initiatives. We can carve out some time to look at DDB session storage (it was created before I joined the team!) and go from there.

  • 👍1
thomaswitt commented

@mullermp I really highly appreciate your explanations and your efforts. Please let me know if I can be of any help. I think the session storage is a good idea, as everybody who wants to use DynamoDB is not interested in maintaining another database for sessions.

mullermp commented

I took a look into a few of these issues.

First, the Aws::SessionStore::DynamoDB::Table.create_table does seems to ignore basically all the options set in the Rails app

If you are referring to the session_store config snippet, I think this is by design (by Rails)? Migrations are run separate from rails initialization. Looking at create_table, it does take options, you can add your options to the create_table call in the migration for one time use. You could also use the config_file option which points to a yml file, I believe the generator will give you a skeleton template.

Second, the generate command creates a migration, which is rather useless if you use DynamoDB, as you don't have any migrations when not using ActiveRecord.

This is true - I think maybe a rake task for create/delete would be preferred, and we can take this as a feature request. ActiveRecord usage is separate from your session storage usage. I think at the time of this gem being created, aws-record did not exist, and noSQL wasn't as popular as it is now.

The configuration in the initialized also seems to be rather ignored.

Looking into this, I confirmed that the initializer is setting config and it's eventually piped through to SessionStore::DynamoDB::Configuration. Looking at SessionStore::DynamoDB::RackMiddleware it seems the only config that matters at runtime is locking, the secret key, and the error handler.

I think given how some of the config options are used (in and out of Rails execution), you should define your config in the dynamo_db_session_store.yml config that is provided on default generation, and use it per Rails.env (or globally). You can pass this config option to the create table, and it will be loaded when you run your application as well as when you clean up sessions with the rake task. The initializer would only be a default call to Rails.application.config.session_store :dynamodb_store

Also I keep on getting the error undefined method commit_csrf_token' for an instance of Rack::Request` when using OmniAuth.
I don't see a reference to this method anywhere in these packages. It might be something unrelated? If you have a stack trace or more information I could look.

  • 😄1