Rails Redis Session Store在Heroku异常：用户自动登出求助

Hey there! Let's tackle that unexpected session timeout issue you're facing with your Rails 5.2 + Spree + Sidekiq app on Heroku. Even though you're using Redis for session storage (which should handle shared sessions across dynos perfectly), there are a few common culprits that might be causing those 5-6 minute logouts. Here's what to check:

1. Check Spree's Built-in Session Timeout #

Spree has its own session timeout configuration that might override Rails' default settings. Head to your config/initializers/spree.rb file and look for:

Spree::Config[:session_timeout]

If this is set to something like 5.minutes or 6.minutes, that's exactly the issue! Update it to your desired duration, e.g.:

Spree::Config[:session_timeout] = 2.hours

2. Explicitly Set Session Expiry in Rails #

Your current session store config doesn't specify an expire_after value, which might be falling back to a shorter default (or inheriting a short expiry from your cache store). Update your session store setup to include a clear expiry:

config.session_store :cache_store, key: '_spree_test_session', expire_after: 1.day

Also, double-check your Redis cache store config to make sure it's not enforcing a global short expiry that's affecting sessions:

config.cache_store = :redis_cache_store, { url: ENV['REDIS_URL'], expire_in: 1.day }

Note: The expire_after in session_store takes precedence over the cache store's global expire_in for session-specific keys.

3. Verify Heroku Redis Memory & Eviction Policy #

Heroku's free/hobby Redis instances have limited memory, and if they hit the limit, they'll use an LRU (Least Recently Used) eviction policy to delete keys. If your session keys are being evicted early because of this, you'll see unexpected logouts:

• Run heroku redis:info from your terminal to check memory usage and eviction policy.
• If memory is near capacity, consider upgrading your Redis plan or cleaning up unused cache keys.
• For hobby plans, you can try adjusting the eviction policy (though options are limited) with heroku redis:config set maxmemory-policy=noeviction (but be cautious—this can cause errors if memory fills up).

4. Add a Namespace to Your Redis Cache #

Without a namespace, your session keys might be colliding with other cache entries (from Sidekiq, Spree's own caching, or other parts of your app) and getting deleted accidentally. Add a namespace to your cache store config:

config.cache_store = :redis_cache_store, { url: ENV['REDIS_URL'], namespace: 'spree_app_session', expire_in: 1.day }

This ensures session keys are isolated from other cache operations.

5. Check Browser Cookie Expiry #

Sometimes the issue is on the client side. Open your browser's developer tools, go to the "Application" tab, and look for the _spree_test_session cookie. Check its Expires or Max-Age value—if it's set to 5-6 minutes, that confirms the expiry is being sent correctly from the server, and you'll need to fix the server-side configs above. If it's longer but you're still being logged out, there might be a Redis connectivity issue.

6. Rule Out Dyno Restart or Connectivity Blips #

While less likely for 5-minute timeouts, Heroku dynos do restart daily, but that shouldn't cause frequent logouts. You can check your app logs with heroku logs --tail to see if there are any Redis connection errors or session lookup failures around the time users get logged out.

Hope these steps help you track down the issue! Let me know if you find something unexpected.

内容的提问来源于stack exchange，提问作者Vishal G