limited_sessions 4.1.0 → 5.0.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +5 -5
- data/CHANGELOG +16 -0
- data/MIT-LICENSE +1 -1
- data/README.md +205 -0
- data/lib/limited_sessions/expiry.rb +2 -9
- data/lib/limited_sessions/self_cleaning_session.rb +10 -10
- data/lib/limited_sessions/version.rb +1 -1
- data/lib/limited_sessions.rb +0 -4
- metadata +21 -20
- data/README +0 -229
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
|
-
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
2
|
+
SHA256:
|
|
3
|
+
metadata.gz: e49ec43bc1c4f86c591c152081196467df00bf82949d2ec838506e6d2c71e033
|
|
4
|
+
data.tar.gz: 6d88ce0966c834298391d13493482b047394a75764342aa735c7703005eef181
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: f78ee40a5c1158c5aa886d23d670da59529d5f27d9fb5f64533a686bc5e362e6288a5db15a5ecdaafee5922f7f45ce030ca6d33729d5535ead5ca5fc69748798
|
|
7
|
+
data.tar.gz: 9da570b7fd00bebea9acb009e33657823d69b4e6ae855cf90907afe08bb9b06250429721fd078d7565e53b5ef1f645709507c4ad24e2bc0231b33b6d1f8d3e61
|
data/CHANGELOG
CHANGED
|
@@ -1,3 +1,19 @@
|
|
|
1
|
+
* 2022-aug-10 - v5.0.1
|
|
2
|
+
|
|
3
|
+
- Fix for deprecation warning in Rails 7
|
|
4
|
+
|
|
5
|
+
* 2021-apr-20 - v5.0.0
|
|
6
|
+
|
|
7
|
+
- Drop support for Rack <= 2.0.8 and Rails < 5.2
|
|
8
|
+
- Update for new rubies
|
|
9
|
+
- Cleanup readme and comments
|
|
10
|
+
|
|
11
|
+
* 2017-may-22 - v4.2.0
|
|
12
|
+
|
|
13
|
+
- Fixed ActiveRecord session cleanup on Rails 5.1
|
|
14
|
+
- Prevent ActiveRecord session cleanup from possibly running more often than
|
|
15
|
+
configured due to Rails loading sessions more than once per request.
|
|
16
|
+
|
|
1
17
|
* 2016-feb-12 - v4.1.0
|
|
2
18
|
|
|
3
19
|
- Support Rails 5.0 & Rack 2.0
|
data/MIT-LICENSE
CHANGED
data/README.md
ADDED
|
@@ -0,0 +1,205 @@
|
|
|
1
|
+
# LimitedSessions
|
|
2
|
+
|
|
3
|
+
LimitedSessions provides two distinct features, each in a separate part:
|
|
4
|
+
|
|
5
|
+
* Rack-compatible middleware that expires sessions based on inactivity or maximum session length. The middleware supports any session storage type, including cookies, Redis, ActiveRecord, etc.
|
|
6
|
+
|
|
7
|
+
* Rails extension to the (now separate) ActiveRecord Session Store to auto-cleanup stale session records.
|
|
8
|
+
|
|
9
|
+
|
|
10
|
+
## Features
|
|
11
|
+
|
|
12
|
+
* For all session stores:
|
|
13
|
+
* Configurable session expiry time (eg: 2 hours from last page access)
|
|
14
|
+
* Optional hard maximum limit from beginning of session (eg: 24 hours)
|
|
15
|
+
|
|
16
|
+
* When using the ActiveRecord Session Store:
|
|
17
|
+
* DB-based handling of session expiry (activity and hard limits) instead of by session paramters
|
|
18
|
+
* Auto-cleaning of expired session records
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
## Requirements
|
|
22
|
+
|
|
23
|
+
* Rack and any Rack-compatible app (including Rails)
|
|
24
|
+
* Utilizing Rack's (or Rails') sessions
|
|
25
|
+
* For ActiveRecord session enhancements:
|
|
26
|
+
* Must be using the standard ActiveRecord::SessionStore
|
|
27
|
+
(`ActionDispatch::Session::ActiveRecordStore.session_store = :active_record_store`)
|
|
28
|
+
* Ensure your sessions table has an `updated_at` column
|
|
29
|
+
* If using hard session limits, a `created_at` column is needed too
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
## Compatibility
|
|
33
|
+
|
|
34
|
+
The middleware should be compatible with any framework using a recent version of Rack. It has been tested with Rack 2.x and Rails 5.2-7.0.
|
|
35
|
+
|
|
36
|
+
The optional ActiveRecord Session Store extension requires Rails.
|
|
37
|
+
|
|
38
|
+
If using Rack < 2.0.9 or Rails < 5.2, use LimitedSessions 4.x.
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
## Upgrading
|
|
42
|
+
|
|
43
|
+
No changes are required to upgrade from LimitedSessions 4.x to 5.0.
|
|
44
|
+
|
|
45
|
+
Upgrading `activerecord-session_store` from 1.x to 2.x may require changes. See its own upgrade instructions.
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
## Installation
|
|
49
|
+
|
|
50
|
+
Add this gem to your Gemfile or otherwise make it available to your app. Then, configure as required.
|
|
51
|
+
|
|
52
|
+
```ruby
|
|
53
|
+
gem 'limited_sessions', '~> 5'
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
If storing sessions in the DB using ActiveRecord with AR Session Store:
|
|
57
|
+
|
|
58
|
+
```ruby
|
|
59
|
+
gem 'activerecord-session_store'
|
|
60
|
+
gem 'limited_sessions', '~> 5'
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
`activerecord-session_store` must be loaded first in order for `limited_sessions` to properly detect it.
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+
## Configuration
|
|
67
|
+
|
|
68
|
+
### Rack Middleware with Rails
|
|
69
|
+
|
|
70
|
+
1. Add/update `config/initializers/session_store.rb` and append the following:
|
|
71
|
+
|
|
72
|
+
```ruby
|
|
73
|
+
config.middleware.insert_after ActionDispatch::Flash, LimitedSessions::Expiry, \
|
|
74
|
+
recent_activity: 2.hours, max_session: 24.hours
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
2. Configuration options.
|
|
78
|
+
|
|
79
|
+
The example above shows both configuration options. You may include one, both, or none.
|
|
80
|
+
|
|
81
|
+
#### Session activity timeout
|
|
82
|
+
Example: `recent_activity: 2.hours`
|
|
83
|
+
By default, the session activity timeout is disabled (`nil`).
|
|
84
|
+
|
|
85
|
+
#### Maximum session length
|
|
86
|
+
Example: `max_session: 24.hours`
|
|
87
|
+
By default, the maximum session length is disabled (`nil`).
|
|
88
|
+
|
|
89
|
+
|
|
90
|
+
### Rack Middleware apart from Rails
|
|
91
|
+
|
|
92
|
+
1. In `config.ru`, add the following *after* the middleware that handles your sessions.
|
|
93
|
+
|
|
94
|
+
```ruby
|
|
95
|
+
use LimitedSessions::Expiry, recent_activity: 2.hours, max_session: 24.hours
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
2. For configuration options, see #2 above, under Rack Middleware with Rails.
|
|
99
|
+
|
|
100
|
+
|
|
101
|
+
### ActionRecord Session Store extension
|
|
102
|
+
|
|
103
|
+
1. If you don't already have an `updated_at` column on your sessions table, create a migration and add it. If you plan to use the hard session limit feature, you'll also need to add `created_at`.
|
|
104
|
+
|
|
105
|
+
2. Tell Rails to use your the new session store. Change `config/initializers/session_store.rb` to reflect the following:
|
|
106
|
+
|
|
107
|
+
```ruby
|
|
108
|
+
Rails.application.config.session_store :active_record_store
|
|
109
|
+
ActionDispatch::Session::ActiveRecordStore.session_class = LimitedSessions::SelfCleaningSession
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
3. Configuration options.
|
|
113
|
+
|
|
114
|
+
Each of the following options should also be added to your initializer file from step 2.
|
|
115
|
+
|
|
116
|
+
#### Self-cleaning
|
|
117
|
+
By default, SelfCleaningSession will clean the sessions table every 1000 page views. Technically, it's a 1 in 1000 chance on each page. For most sites this is good. Higher traffic sites may want to increase it to 10000 or more. Set to 0 to disable self-cleaning.
|
|
118
|
+
|
|
119
|
+
```ruby
|
|
120
|
+
LimitedSessions::SelfCleaningSession.self_clean_sessions = 1000
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
#### Session activity timeout
|
|
124
|
+
The default session activity timeout is 2 hours. This uses the `updated_at` column which will be updated on every page load.
|
|
125
|
+
|
|
126
|
+
This can also be disabled by setting to `nil`. However, the `updated_at` column is still required for self-cleaning and will effectively function as if set to `1.week`. If you really want it longer, set it to `1.year` or something.
|
|
127
|
+
|
|
128
|
+
```ruby
|
|
129
|
+
LimitedSessions::SelfCleaningSession.recent_activity = 2.hours
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
#### Maximum session length
|
|
133
|
+
By default, maximum session length handling is disabled. When enabled, it uses the `created_at` column to do its work.
|
|
134
|
+
|
|
135
|
+
A value of `nil` disables this feature and `created_at` does not need to exist in this case.
|
|
136
|
+
|
|
137
|
+
```ruby
|
|
138
|
+
LimitedSessions::SelfCleaningSession.max_session = 12.hours
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
|
|
142
|
+
## Questions
|
|
143
|
+
|
|
144
|
+
* Do I need both the middleware and the ActiveRecord Session Store?
|
|
145
|
+
|
|
146
|
+
No. While it should work, it is not necessary to use both the middleware
|
|
147
|
+
and the ActiveRecord Session Store. If you are storing sessions via AR,
|
|
148
|
+
then use the ActiveRecord Session Store. If you are storing sessions any
|
|
149
|
+
other way, then use the middleware.
|
|
150
|
+
|
|
151
|
+
* I'm storing sessions in {Memcache, Redis, etc.} and they auto-expire sessions. Do I need this?
|
|
152
|
+
|
|
153
|
+
Maybe, maybe not. Normally, that auto-expire period is equivalent to LimitedSessions' :recent_activity. If that's all you want, then you don't need this. However, if you'd also like to put a maximum cap on session length, regardless of activity, then LimitedSessions' `:max_session` feature will still be useful.
|
|
154
|
+
|
|
155
|
+
* Can I use the middleware with ActiveRecord instead of the ActionRecord Session Store enhancement?
|
|
156
|
+
|
|
157
|
+
Yes. Session expiry (recent activity and max session length) should work fine in this circumstance. The only thing you won't get is self-cleaning of the AR sessions table.
|
|
158
|
+
|
|
159
|
+
* How are session expiry times tracked?
|
|
160
|
+
|
|
161
|
+
The middleware adds one or two keys to the session data: `:last_visit` and/or `:first_visit`.
|
|
162
|
+
|
|
163
|
+
The AR enhancement uses `updated_at` and possibly `created_at`.
|
|
164
|
+
|
|
165
|
+
* How is this different from using the session cookie's own expires= value?
|
|
166
|
+
|
|
167
|
+
The cookie's own value puts the trust in the client to self-expire. If you really want to control session lengths, then you need to manage the values on the application side. LimitedSessions is fully compatible with the cookie's expires= value, however, and the two can be used together.
|
|
168
|
+
|
|
169
|
+
* What's the difference between `:recent_activity` and `:max_session`?
|
|
170
|
+
|
|
171
|
+
Recent activity requires regular access on your site. If it's set to 15 minutes, then a page must be loaded at least once every 15 minutes.
|
|
172
|
+
|
|
173
|
+
Max session is a cap on the session from the very beginning. If it's set to 12 hours, then even if a user is accessing the page constantly, and not triggering the recent activity timeout, after 12 hours their session would be reset anyway.
|
|
174
|
+
|
|
175
|
+
* What are the security implications of using LimitedSessions?
|
|
176
|
+
|
|
177
|
+
LimitedSessions enhances security by reducing risk of session cookie replay attacks. The specifics will depend on what cookie store you're using.
|
|
178
|
+
|
|
179
|
+
For Rails' default cookie store, `:max_session` handling is perhaps most valuable as it guarantees an end to the session. Rails' default behavior allows a session to last for an infinite time. If a cookie is somehow exposed, the holder of the cookie has an open-ended session. Note that signing and/or encryption do not mitigate this.
|
|
180
|
+
|
|
181
|
+
For any session store that uses a server-side database (AR, memcache, Redis, etc.), at least the user can formally logout and terminate the session. Auto-expiring sessions (memcache, Redis, AR w/SelfCleaningSession, etc.) will also expire if allowed to, but can also be maintained perpetually by ongoing access.
|
|
182
|
+
|
|
183
|
+
Since the cookie store doesn't expire ever, `:recent_activity` addresses this by making sessions expire similarly to if memcache, Redis, or something similar was being used.
|
|
184
|
+
|
|
185
|
+
It is recommended to use both aspects of LimitedSessions for best security.
|
|
186
|
+
|
|
187
|
+
* What are the performance implications of using LimitedSessions?
|
|
188
|
+
|
|
189
|
+
The middleware should have minimal impact.
|
|
190
|
+
|
|
191
|
+
The AR enhancement should result in an overall net gain in performance as the size of the AR sessions table will be kept to a smaller size. The 1 in 1000 hit (or whatever you've configured it to) may be slightly slower while the database cleanup is in progress.
|
|
192
|
+
|
|
193
|
+
|
|
194
|
+
## Contributing
|
|
195
|
+
|
|
196
|
+
1. Fork it ( https://github.com/zarqman/limited_sessions/fork )
|
|
197
|
+
2. Create your feature branch (`git checkout -b my-new-feature`)
|
|
198
|
+
3. Commit your changes (`git commit -am 'Add some feature'`)
|
|
199
|
+
4. Push to the branch (`git push origin my-new-feature`)
|
|
200
|
+
5. Create new Pull Request
|
|
201
|
+
|
|
202
|
+
|
|
203
|
+
## License
|
|
204
|
+
|
|
205
|
+
MIT
|
|
@@ -1,16 +1,9 @@
|
|
|
1
|
-
# LimitedSessions
|
|
2
|
-
# (c) 2007-2013 t.e.morgan
|
|
3
|
-
# Made available under the MIT license
|
|
4
|
-
|
|
5
|
-
# This version is compatible with Rack 1.4-1.5 (possibly earlier; untested).
|
|
6
|
-
# Correspondingly, it is compatible with Rails 3.x-4.x.
|
|
7
|
-
|
|
8
1
|
module LimitedSessions
|
|
9
2
|
# Rack middleware that should be installed *after* the session handling middleware
|
|
10
3
|
class Expiry
|
|
11
4
|
DEFAULT_OPTIONS = {
|
|
12
|
-
:
|
|
13
|
-
:
|
|
5
|
+
recent_activity: nil, # eg: 2.hours
|
|
6
|
+
max_session: nil # eg: 24.hours
|
|
14
7
|
}
|
|
15
8
|
|
|
16
9
|
def initialize(app, options={})
|
|
@@ -1,14 +1,12 @@
|
|
|
1
|
-
# LimitedSessions
|
|
2
|
-
# (c) 2007-2012 t.e.morgan
|
|
3
|
-
# Made available under the MIT license
|
|
4
|
-
|
|
5
|
-
# This is the Rails 4.x version.
|
|
6
|
-
|
|
7
1
|
module LimitedSessions
|
|
8
2
|
class SelfCleaningSession < ActiveRecord::SessionStore::Session
|
|
9
3
|
|
|
10
4
|
# disable short circuit by Dirty module; ensures :updated_at is kept updated
|
|
11
|
-
|
|
5
|
+
if Rails::VERSION::MAJOR >= 7
|
|
6
|
+
self.partial_updates = false
|
|
7
|
+
else
|
|
8
|
+
self.partial_writes = false
|
|
9
|
+
end
|
|
12
10
|
|
|
13
11
|
self.table_name = 'sessions'
|
|
14
12
|
|
|
@@ -29,19 +27,21 @@ module LimitedSessions
|
|
|
29
27
|
# If this is a problem, use a migration and rename the column.
|
|
30
28
|
def find_by_session_id(session_id)
|
|
31
29
|
consider_self_clean
|
|
32
|
-
active_session.current_session.where(:session_id
|
|
30
|
+
active_session.current_session.where(session_id: session_id).first
|
|
33
31
|
end
|
|
34
32
|
|
|
35
33
|
private
|
|
36
34
|
def consider_self_clean
|
|
37
35
|
return if self_clean_sessions == 0
|
|
36
|
+
return if defined?(@@last_check) && @@last_check == Time.now.to_i
|
|
38
37
|
if rand(self_clean_sessions) == 0
|
|
38
|
+
@@last_check = Time.now.to_i
|
|
39
39
|
# logger.info "SelfCleaningSession :: scrubbing expired sessions"
|
|
40
40
|
look_back_recent = recent_activity || 1.week
|
|
41
41
|
if max_session
|
|
42
|
-
|
|
42
|
+
self.where('updated_at < ? OR created_at < ?', Time.current - look_back_recent, Time.current - max_session).delete_all
|
|
43
43
|
elsif columns_hash['updated_at']
|
|
44
|
-
|
|
44
|
+
self.where('updated_at < ?', Time.current - look_back_recent).delete_all
|
|
45
45
|
else
|
|
46
46
|
# logger.warning "WARNING: Unable to self-clean Sessions table; updated_at column is missing"
|
|
47
47
|
self.self_clean_sessions = 0
|
data/lib/limited_sessions.rb
CHANGED
metadata
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: limited_sessions
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version:
|
|
4
|
+
version: 5.0.1
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- t.e.morgan
|
|
8
|
-
autorequire:
|
|
8
|
+
autorequire:
|
|
9
9
|
bindir: bin
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date:
|
|
11
|
+
date: 2022-08-10 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: rack
|
|
@@ -16,7 +16,7 @@ dependencies:
|
|
|
16
16
|
requirements:
|
|
17
17
|
- - ">="
|
|
18
18
|
- !ruby/object:Gem::Version
|
|
19
|
-
version:
|
|
19
|
+
version: 2.0.9
|
|
20
20
|
- - "<"
|
|
21
21
|
- !ruby/object:Gem::Version
|
|
22
22
|
version: '3'
|
|
@@ -26,7 +26,7 @@ dependencies:
|
|
|
26
26
|
requirements:
|
|
27
27
|
- - ">="
|
|
28
28
|
- !ruby/object:Gem::Version
|
|
29
|
-
version:
|
|
29
|
+
version: 2.0.9
|
|
30
30
|
- - "<"
|
|
31
31
|
- !ruby/object:Gem::Version
|
|
32
32
|
version: '3'
|
|
@@ -50,24 +50,24 @@ dependencies:
|
|
|
50
50
|
requirements:
|
|
51
51
|
- - ">="
|
|
52
52
|
- !ruby/object:Gem::Version
|
|
53
|
-
version: '
|
|
53
|
+
version: '5.2'
|
|
54
54
|
- - "<"
|
|
55
55
|
- !ruby/object:Gem::Version
|
|
56
|
-
version: '
|
|
56
|
+
version: '7.1'
|
|
57
57
|
type: :development
|
|
58
58
|
prerelease: false
|
|
59
59
|
version_requirements: !ruby/object:Gem::Requirement
|
|
60
60
|
requirements:
|
|
61
61
|
- - ">="
|
|
62
62
|
- !ruby/object:Gem::Version
|
|
63
|
-
version: '
|
|
63
|
+
version: '5.2'
|
|
64
64
|
- - "<"
|
|
65
65
|
- !ruby/object:Gem::Version
|
|
66
|
-
version: '
|
|
66
|
+
version: '7.1'
|
|
67
67
|
description: 'LimitedSessions provides two core features to handle cookie-based session
|
|
68
68
|
expiry: 1) Rack Middleware for most session stores and 2) an ActiveRecord extension
|
|
69
69
|
for AR-based session stores. Sessions can be expired on inactivity and/or overall
|
|
70
|
-
session length.'
|
|
70
|
+
session length. Works with and without Rails.'
|
|
71
71
|
email:
|
|
72
72
|
- tm@iprog.com
|
|
73
73
|
executables: []
|
|
@@ -76,7 +76,7 @@ extra_rdoc_files: []
|
|
|
76
76
|
files:
|
|
77
77
|
- CHANGELOG
|
|
78
78
|
- MIT-LICENSE
|
|
79
|
-
- README
|
|
79
|
+
- README.md
|
|
80
80
|
- Rakefile
|
|
81
81
|
- lib/limited_sessions.rb
|
|
82
82
|
- lib/limited_sessions/expiry.rb
|
|
@@ -114,10 +114,12 @@ files:
|
|
|
114
114
|
- test/dummy/script/rails
|
|
115
115
|
- test/limited_sessions_test.rb
|
|
116
116
|
- test/test_helper.rb
|
|
117
|
-
homepage:
|
|
118
|
-
licenses:
|
|
119
|
-
|
|
120
|
-
|
|
117
|
+
homepage: https://iprog.com/projects#limited_sessions
|
|
118
|
+
licenses:
|
|
119
|
+
- MIT
|
|
120
|
+
metadata:
|
|
121
|
+
source_code_uri: https://github.com/zarqman/limited_sessions
|
|
122
|
+
post_install_message:
|
|
121
123
|
rdoc_options: []
|
|
122
124
|
require_paths:
|
|
123
125
|
- lib
|
|
@@ -132,12 +134,13 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
|
132
134
|
- !ruby/object:Gem::Version
|
|
133
135
|
version: '0'
|
|
134
136
|
requirements: []
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
signing_key:
|
|
137
|
+
rubygems_version: 3.2.32
|
|
138
|
+
signing_key:
|
|
138
139
|
specification_version: 4
|
|
139
140
|
summary: Server-side session expiry via either Rack Middleware or ActiveRecord extension
|
|
140
141
|
test_files:
|
|
142
|
+
- test/dummy/README.rdoc
|
|
143
|
+
- test/dummy/Rakefile
|
|
141
144
|
- test/dummy/app/assets/javascripts/application.js
|
|
142
145
|
- test/dummy/app/assets/stylesheets/application.css
|
|
143
146
|
- test/dummy/app/controllers/application_controller.rb
|
|
@@ -164,8 +167,6 @@ test_files:
|
|
|
164
167
|
- test/dummy/public/422.html
|
|
165
168
|
- test/dummy/public/500.html
|
|
166
169
|
- test/dummy/public/favicon.ico
|
|
167
|
-
- test/dummy/Rakefile
|
|
168
|
-
- test/dummy/README.rdoc
|
|
169
170
|
- test/dummy/script/rails
|
|
170
171
|
- test/limited_sessions_test.rb
|
|
171
172
|
- test/test_helper.rb
|
data/README
DELETED
|
@@ -1,229 +0,0 @@
|
|
|
1
|
-
LimitedSessions
|
|
2
|
-
===============
|
|
3
|
-
Copyright 2007-2013 t.e.morgan.
|
|
4
|
-
License: MIT
|
|
5
|
-
|
|
6
|
-
Updates/info: http://iprog.com/projects#limited_sessions
|
|
7
|
-
Source: https://github.com/zarqman/limited_sessions
|
|
8
|
-
Contact: tm@iprog.com
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
LimitedSessions provides two distinct features, each in a separate part:
|
|
12
|
-
* Rack-compatible middleware that expires sessions based on inactivity or
|
|
13
|
-
maximum session length. This works with Rails 4 just fine.
|
|
14
|
-
* Rails 4 extension to the (now separate) ActiveRecord Session Store to
|
|
15
|
-
auto-cleanup stale session records.
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
Notes on Rails and Rack versions:
|
|
19
|
-
The middleware should be compatible with any framework using a recent
|
|
20
|
-
version of Rack. It was tested with Rack 1.5 and Rails 4.0.
|
|
21
|
-
|
|
22
|
-
The ActiveRecord Session Store extension requires Rails 4 and the now
|
|
23
|
-
separate activerecord-session_store gem:
|
|
24
|
-
gem 'activerecord-session_store'
|
|
25
|
-
activerecord-session_store must be *before* limited_sessions in your Gemfile
|
|
26
|
-
in order for limited_sessions to auto-detect it.
|
|
27
|
-
|
|
28
|
-
For Rails 3, use limited_sessions v3.x.x:
|
|
29
|
-
gem 'limited_sessions', '~> 3.0'
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
Upgrading from previous versions:
|
|
33
|
-
Other than possibly requiring the activerecord-session_store gem as noted
|
|
34
|
-
above, no changes are required upgrading from limited_sessions 3.x to 4.0.
|
|
35
|
-
|
|
36
|
-
If upgrading from limited_sessions v2.x, please review the upgrade notes from
|
|
37
|
-
limited_sessions 3.x or build a new configuration using the instructions
|
|
38
|
-
below.
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
Features:
|
|
42
|
-
* For all session stores:
|
|
43
|
-
* Configurable session expiry time (eg: 2 hours from last page access)
|
|
44
|
-
* Optional hard maximum limit from beginning of session (eg: 24 hours)
|
|
45
|
-
* When using the ActiveRecord Session Store:
|
|
46
|
-
* DB-based handling of session expiry (activity and hard limits) instead of
|
|
47
|
-
by session paramters
|
|
48
|
-
* Auto-cleaning of expired session records
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
Requirements:
|
|
52
|
-
* Rack and any Rack-compatible app (including Rails 4)
|
|
53
|
-
* Utilizing Rack's (or Rails') sessions support
|
|
54
|
-
* For ActiveRecord session enhancements:
|
|
55
|
-
* Must be using the standard ActiveRecord::SessionStore
|
|
56
|
-
(ActionDispatch::Session::ActiveRecordStore.session_store = :active_record_store)
|
|
57
|
-
* Ensure your sessions table has an `updated_at` column
|
|
58
|
-
* If using hard session limits, a `created_at` column is needed too
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
Installation:
|
|
62
|
-
Add this gem to your Gemfile (Rails) or otherwise make it available to your
|
|
63
|
-
app. Then, configure as required.
|
|
64
|
-
|
|
65
|
-
gem 'limited_sessions', '~> 4.0'
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
Configuration:
|
|
69
|
-
Rack Middleware with Rails
|
|
70
|
-
1. Update your config/initializers/session_store.rb and append the
|
|
71
|
-
following:
|
|
72
|
-
|
|
73
|
-
config.middleware.insert_after ActionDispatch::Flash, LimitedSessions::Expiry, \
|
|
74
|
-
recent_activity: 2.hours, max_session: 24.hours
|
|
75
|
-
|
|
76
|
-
2. Configuration options.
|
|
77
|
-
The example above shows both configuration options. You may include
|
|
78
|
-
both, one, or none.
|
|
79
|
-
|
|
80
|
-
* Session activity timeout *
|
|
81
|
-
Example: recent_activity: 2.hours
|
|
82
|
-
By default, the session activity timeout is disabled (nil).
|
|
83
|
-
|
|
84
|
-
* Maximum session length *
|
|
85
|
-
Example: max_session: 24.hours
|
|
86
|
-
By default, the maximum session length is disabled (nil).
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
Rack Middleware apart from Rails
|
|
90
|
-
1. In your config.ru, add the following *after* the middleware that handles
|
|
91
|
-
your sessions.
|
|
92
|
-
|
|
93
|
-
use LimitedSessions::Expiry, recent_activity: 2.hours, max_session: 24.hours
|
|
94
|
-
|
|
95
|
-
2. See #2 above, under Rack Middleware with Rails, for Configuration options.
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
ActionRecord Session Store
|
|
99
|
-
1. If you don't already have an 'updated_at' column on your sessions table,
|
|
100
|
-
create a migration and add it. If you plan to use the hard session limit
|
|
101
|
-
feature, you'll also need to add 'created_at'.
|
|
102
|
-
|
|
103
|
-
2. Tell Rails to use your the new session store. Change
|
|
104
|
-
config/initializers/session_store.rb to reflect the following:
|
|
105
|
-
|
|
106
|
-
<YourApp>::Application.config.session_store :active_record_store
|
|
107
|
-
ActionDispatch::Session::ActiveRecordStore.session_class = LimitedSessions::SelfCleaningSession
|
|
108
|
-
|
|
109
|
-
3. Configuration options.
|
|
110
|
-
Each of the following options should also be added to your initializer
|
|
111
|
-
file from step 2.
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
* Self-cleaning *
|
|
115
|
-
By default, SelfCleaningSession will clean the sessions table about every
|
|
116
|
-
1000 page views. Technically, it's a 1 in 1000 chance on each page. For
|
|
117
|
-
most sites this is good. Higher traffic sites may want to increase it to
|
|
118
|
-
10000 or more. 0 will disable self-cleaning.
|
|
119
|
-
|
|
120
|
-
LimitedSessions::SelfCleaningSession.self_clean_sessions = 1000
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
* Session activity timeout *
|
|
124
|
-
The default session activity timeout is 2 hours. This uses the
|
|
125
|
-
'updated_at' column which will be updated on every page load.
|
|
126
|
-
|
|
127
|
-
This can also be disabled by setting to nil. However, the 'updated_at'
|
|
128
|
-
column is still required for self-cleaning and will effectively function
|
|
129
|
-
as if this was set to 1.week. If you really want it longer, set it to
|
|
130
|
-
1.year or something.
|
|
131
|
-
|
|
132
|
-
LimitedSessions::SelfCleaningSession.recent_activity = 2.hours
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
* Maximum session length *
|
|
136
|
-
By default, the maximum session length handling is disabled. When
|
|
137
|
-
enabled, it uses the 'created_at' column to do its work.
|
|
138
|
-
|
|
139
|
-
A value of nil disables this feature and 'created_at' does not need to
|
|
140
|
-
exist in this case.
|
|
141
|
-
|
|
142
|
-
LimitedSessions::SelfCleaningSession.max_session = 12.hours
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
Other questions:
|
|
146
|
-
Do I need both the middleware and the ActiveRecord Session Store?
|
|
147
|
-
No. While it should work, it is not necessary to use both the middleware
|
|
148
|
-
and the ActiveRecord Session Store. If you are storing sessions via AR,
|
|
149
|
-
then use the ActiveRecord Session Store. If you are storing sessions any
|
|
150
|
-
other way, then use the middleware.
|
|
151
|
-
|
|
152
|
-
I'm storing sessions in {Memcache, Redis, etc.} and they auto-expire
|
|
153
|
-
sessions. Do I need this?
|
|
154
|
-
Maybe, maybe not. Normally, that auto-expire period is equivalent to
|
|
155
|
-
LimitedSessions' :recent_activity. If that's all you want, then you don't
|
|
156
|
-
need this. However, if you'd also like to put a maximum cap on session
|
|
157
|
-
length, regardless of activity, then LimitedSessions' :max_session feature
|
|
158
|
-
will still be useful.
|
|
159
|
-
|
|
160
|
-
Can I use the middleware with ActiveRecord instead of the ActionRecord
|
|
161
|
-
Session Store enhancement?
|
|
162
|
-
Yes; session expiry (recent activity and max session length) should work
|
|
163
|
-
fine in this circumstance. The only thing you won't get is self-cleaning of
|
|
164
|
-
the AR sessions table.
|
|
165
|
-
|
|
166
|
-
How are session expiry times tracked?
|
|
167
|
-
The middleware adds one or two keys to the session data: :last_visit and/or
|
|
168
|
-
:first_visit.
|
|
169
|
-
The AR enhancement uses 'updated_at' and possibly 'created_at'.
|
|
170
|
-
|
|
171
|
-
How is this different from using the session cookie's own expires= value?
|
|
172
|
-
The cookie's own value puts the trust in the client to self-expire. If you
|
|
173
|
-
really want to control session lengths, then you need to manage the values
|
|
174
|
-
on the application side. LimitedSessions is fully compatible with the
|
|
175
|
-
cookie's expires= value, however, and the two can be used together.
|
|
176
|
-
|
|
177
|
-
What's the difference between :recent_activity and :max_session?
|
|
178
|
-
Recent activity requires regular access on your site. If it's set to 15
|
|
179
|
-
minutes, then a page must be loaded at least once every 15 minutes.
|
|
180
|
-
|
|
181
|
-
Max session is a cap on the session from the very beginning. If it's set to
|
|
182
|
-
12 hours, then even if a user is accessing the page constantly, and not
|
|
183
|
-
triggering the recent activity timeout, after 12 hours their session would
|
|
184
|
-
be reset anyway.
|
|
185
|
-
|
|
186
|
-
What are the security implications of using LimitedSessions?
|
|
187
|
-
LimitedSessions enhances security by reducing risk of session cookie replay
|
|
188
|
-
attacks. The specifics will depend on what cookie store you're using.
|
|
189
|
-
|
|
190
|
-
For Rails' default cookie store, :max_session handling is perhaps most
|
|
191
|
-
valuable as it guarantees an end to the session. Rails' default behavior
|
|
192
|
-
allows a session to last for an infinite time. If a cookie is somehow
|
|
193
|
-
exposed, the holder of the cookie has an open-ended session. Note that
|
|
194
|
-
signing and/or encryption do not mitigate this.
|
|
195
|
-
|
|
196
|
-
For any session store that uses a server-side database (AR, memcache, Redis,
|
|
197
|
-
etc.), at least the user can formally logout and terminate the session.
|
|
198
|
-
Auto-expiring sessions (memcache, Redis, AR w/SelfCleaningSession, etc.)
|
|
199
|
-
will also expire if allowed to, but can also be maintained perpetually by
|
|
200
|
-
ongoing access.
|
|
201
|
-
|
|
202
|
-
Since the cookie store doesn't expire ever, :recent_activity addresses this
|
|
203
|
-
by making sessions expire similarly to if memcache, Redis, or something
|
|
204
|
-
similar was being used.
|
|
205
|
-
|
|
206
|
-
It is recommended to use both halves of LimitedSessions for best security.
|
|
207
|
-
|
|
208
|
-
What are the performance implications of using LimitedSessions?
|
|
209
|
-
The middleware should have minimal impact.
|
|
210
|
-
|
|
211
|
-
The AR enhancement should result in an overall net gain in performance as
|
|
212
|
-
the size of the AR sessions table will be kept to a smaller size. The 1 in
|
|
213
|
-
1000 hit (or whatever you've configured it to) may be slightly slower while
|
|
214
|
-
the database cleanup is in progress.
|
|
215
|
-
|
|
216
|
-
Is the AR enhancement compatible with the legacy 'sessid' column?
|
|
217
|
-
No. Please rename that column to 'session_id'.
|
|
218
|
-
|
|
219
|
-
|
|
220
|
-
Other Notes:
|
|
221
|
-
This version has been tested on Rack 1.5 and Rails 4.0. It should be
|
|
222
|
-
compatible with a broad spectrum of data and session stores. If you find a
|
|
223
|
-
bug, I'd love to hear about it -- preferably via a new issue on GitHub (bonus
|
|
224
|
-
points for a pull request). Likewise, give me a shout if you have a suggestion
|
|
225
|
-
or just want to tell me that it works. Thanks for checking limited_sessions
|
|
226
|
-
out!
|
|
227
|
-
|
|
228
|
-
--t (tm@iprog.com; http://iprog.com/)
|
|
229
|
-
|