jwt_sessions 2.4.1 → 2.4.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
-SHA256:
-  metadata.gz: d60c5dcae06e9f49ee1e99125baab8285156bd54eb5b36a3589001cee55acd6e
-  data.tar.gz: faa1cf67e08b8a320b525a918260dd4cf61f0aaf5f4ea1160f0e82ffff2e97b6
+SHA1:
+  metadata.gz: 603df513aaba9a73e5360895ea7fffddf52dd02e
+  data.tar.gz: f70b523406ae364b05d16b45423d3b98971f4c75
 SHA512:
-  metadata.gz: eb844adfe82415bc6126f5a32bceeb95234fbe8172ca427dbeaf7535bc4ae745cee3e33207b9e017c72098b8bf08b0d05cc302b952690568e5ca11fe12ad7629
-  data.tar.gz: 38b0299aa445d3a1558ed66e5a8d805850635065bf17d4de3d4f7f7b6c81a5962cac801bd79ae019209a8df96a4da64592897c6e45355e763b6220f5dfbed1af
+  metadata.gz: f937d9d3362f0ec7c63dc4af813038a3a0b49647a29e6f0338583ae106094cc9677bc83790ae330df3ef46d1159d441cab595cb62f274294a1fdc7af23ecb2cb
+  data.tar.gz: fd37c7ec5f318893567dfce15ba8562c35a25b0ec8c53c12707947ba0f81e9d973144c0f153364ff1e3a92d17eab58c8a91ec1f4f67f0f84457334c83da38f8e

data/README.md

@@ -8,50 +8,50 @@ XSS/CSRF safe JWT auth designed for SPA
 
 ## Table of Contents
 
-- [Synopsis](#synopsis)
-- [Installation](#installation)
-- [Getting Started](#getting-started)
-  * [Creating a session](#creating-a-session)
-  * [Rails integration](#rails-integration)
-  * [Non-Rails usage](#non-rails-usage)
-- [Configuration](#configuration)
-    + [Token store](#token-store)
-    + [JWT signature](#jwt-signature)
-    + [Request headers and cookies names](#request-headers-and-cookies-names)
-    + [Expiration time](#expiration-time)
-    + [CSRF and cookies](#csrf-and-cookies)
-    + [Refresh with access token](#refresh-with-access-token)
-    + [Refresh token hijack protection](#refresh-token-hijack-protection)
-- [Flush Sessions](#flush-sessions)
-    + [Sessions Namespace](#sessions-namespace)
-    + [Logout](#logout)
-- [Examples](#examples)
-- [Contributing](#contributing)
-- [License](#license)
+  - [Synopsis](#synopsis)
+  - [Installation](#installation)
+  - [Getting Started](#getting-started)
+    - [Creating a session](#creating-a-session)
+    - [Rails integration](#rails-integration)
+    - [Non-Rails usage](#non-rails-usage)
+  - [Configuration](#configuration)
+        - [Token store](#token-store)
+        - [JWT signature](#jwt-signature)
+        - [Request headers and cookies names](#request-headers-and-cookies-names)
+        - [Expiration time](#expiration-time)
+      - [CSRF and cookies](#csrf-and-cookies)
+        - [Refresh with access token](#refresh-with-access-token)
+      - [Refresh token hijack protection](#refresh-token-hijack-protection)
+  - [Flush Sessions](#flush-sessions)
+        - [Sessions namespace](#sessions-namespace)
+        - [Logout](#logout)
+  - [Examples](#examples)
+  - [Contributing](#contributing)
+  - [License](#license)
 
 ## Synopsis
 
-Main goal of this gem is to provide configurable, manageable, and safe stateful sessions based on JSON Web Tokens.
+The primary goal of this gem is to provide configurable, manageable, and safe stateful sessions based on JSON Web Tokens.
 
-The gem stores JWT based sessions on the backend (currently, redis and memory stores are supported), making it possible to manage sessions, reset passwords, logout users in a reliable and secure way.
+The gem stores JWT based sessions on the backend (currently, Redis and memory stores are supported), making it possible to manage sessions, reset passwords and logout users in a reliable and secure way.
 
-It's designed to be framework agnostic yet is easily integrable, and Rails integration is available out of the box.
+It is designed to be framework agnostic, yet easily integrable, and Rails integration is available out of the box.
 
-Core concept behind `jwt_sessions` is that each session is represented by a pair of tokens: access and refresh, and a session store is used to handle CSRF checks and refresh token hijacking. Both tokens have configurable expiration times, but in general refresh token is supposed to have a longer lifespan than an access token. Access token is used to retrieve secured resources and refresh token is used to renew the access token once it's expired. Default token store is based on redis.
+The core concept behind `jwt_sessions` is that each session is represented by a pair of tokens: `access` and `refresh`. The session store is used to handle CSRF checks and prevent refresh token hijacking. Both tokens have configurable expiration times but in general the refresh token is supposed to have a longer lifespan than the access token. The access token is used to retrieve secure resources and the refresh token is used to renew the access token once it has expired. The default token store uses Redis.
 
-All tokens are encoded and decoded by [ruby-jwt](https://github.com/jwt/ruby-jwt) gem, and its reserved claim names are supported as well as it's allowed to configure claim checks and cryptographic signing algorithms supported by it.
+All tokens are encoded and decoded by [ruby-jwt](https://github.com/jwt/ruby-jwt) gem. Its reserved claim names are supported and it can configure claim checks and cryptographic signing algorithms supported by it.
 `jwt_sessions` itself uses `ext` claim and `HS256` signing by default.
 
 
 ## Installation
 
-Put this line in your Gemfile
+Put this line in your Gemfile:
 
 ```ruby
 gem "jwt_sessions"
 ```
 
-Then run
+Then run:
 
 ```
 bundle install
@@ -59,18 +59,18 @@ bundle install
 
 ## Getting Started
 
-You should configure an encryption algorithm and specify the encryption key. By default the gem uses `HS256`.
+You should configure an encryption algorithm and specify the encryption key. By default the gem uses the `HS256` signing algorithm.
 
 ```ruby
 JWTSessions.encryption_key = "secret"
 ```
 
-`Authorization` mixin provides helper methods which are used to retrieve access and refresh tokens from incoming requests and verify CSRF token if needed. It assumes that a token can be found either in a cookie or in a header (cookie and header names are configurable). It tries to retrieve it from headers first, then from cookies (CSRF check included) if the headers check failed.
+`Authorization` mixin provides helper methods which are used to retrieve the access and refresh tokens from incoming requests and verify the CSRF token if needed. It assumes that a token can be found either in a cookie or in a header (cookie and header names are configurable). It tries to retrieve the token from headers first and then from cookies (CSRF check included) if the header check fails.
 
 ### Creating a session
 
 Each token contains a payload with custom session info. The payload is a regular Ruby hash. \
-Usually, it contains user ID or other data which helps to identify current user but it's not necessary, the payload can be an empty hash as well.
+Usually, it contains a user ID or other data which help identify the current user but the payload can be an empty hash as well.
 
 ```ruby
 > payload = { user_id: user.id }
@@ -84,7 +84,7 @@ Generate the session with a custom payload. By default the same payload is sewn
 => #<JWTSessions::Session:0x00007fbe2cce9ea0...>
 ```
 
-Sometimes it makes sense to keep different data within the payloads of access and refresh tokens. \
+Sometimes it makes sense to keep different data within the payloads of the access and refresh tokens. \
 The access token may contain rich data including user settings, etc., while the appropriate refresh token will include only the bare minimum which will be required to reconstruct a payload for the new access token during refresh.
 
 ```ruby
@@ -117,10 +117,10 @@ To perform the refresh do:
 Available `JWTSessions::Session.new` options:
 
 - **payload**: a hash object with session data which will be included into an access token payload. Default is an empty hash.
-- **refresh_payload**: a hash object with session data which will be included into a refresh token payload. Default is a value of the access payload.
-- **access_claims**: a hash object with [JWT claims](https://github.com/jwt/ruby-jwt#support-for-reserved-claim-names) which will be validated within the access token payload. F.e. `{ aud: ["admin"], verify_aud: true }` meaning that the token can be used only by "admin" audience. Also, the endpoint can automatically validate claims instead. See `token_claims` method.
+- **refresh_payload**: a hash object with session data which will be included into a refresh token payload. Default is the value of the access payload.
+- **access_claims**: a hash object with [JWT claims](https://github.com/jwt/ruby-jwt#support-for-reserved-claim-names) which will be validated within the access token payload. For example, `{ aud: ["admin"], verify_aud: true }` means that the token can be used only by "admin" audience. Also, the endpoint can automatically validate claims instead. See `token_claims` method.
 - **refresh_claims**: a hash object with [JWT claims](https://github.com/jwt/ruby-jwt#support-for-reserved-claim-names) which will be validated within the refresh token payload.
-- **namespace**: a string object which helps to group sessions by a custom criteria. For example, sessions can be grouped by user ID, then it'll be possible to logout the user from all devises. More info [Sessions Namespace](#sessions-namespace).
+- **namespace**: a string object which helps to group sessions by a custom criteria. For example, sessions can be grouped by user ID, making it possible to logout the user from all devices. More info [Sessions Namespace](#sessions-namespace).
 - **refresh_by_access_allowed**: a boolean value. Default is false. It links access and refresh tokens (adds refresh token ID to access payload), making it possible to perform a session refresh by the last expired access token. See [Refresh with access token](#refresh-with-access-token).
 - **access_exp**: an integer value. Contains an access token expiration time in seconds. The value overrides global settings. See [Expiration time](#expiration-time).
 - **refresh_exp**: an integer value. Contains a refresh token expiration time in seconds. The value overrides global settings. See [Expiration time](#expiration-time).
@@ -132,11 +132,11 @@ Helper methods within `Authorization` mixin:
 - **found_token**: a raw token found within the request.
 - **payload**: a decoded token's payload.
 - **claimless_payload**: a decoded token's payload without claims validation (can be used for checking data of an expired token).
-- **token_claims**: the method should be defined by a developer, and is expected to return a hash-like object with claims to be validated within a token's payload.
+- **token_claims**: the method should be defined by a developer and is expected to return a hash-like object with claims to be validated within a token's payload.
 
 ### Rails integration
 
-Include `JWTSessions::RailsAuthorization` in your controllers, add `JWTSessions::Errors::Unauthorized` exceptions handling if needed.
+Include `JWTSessions::RailsAuthorization` in your controllers and add `JWTSessions::Errors::Unauthorized` exception handling if needed.
 
 ```ruby
 class ApplicationController < ActionController::API
@@ -152,14 +152,14 @@ end
 ```
 
 Specify an encryption key for JSON Web Tokens in `config/initializers/jwt_session.rb` \
-It's adviced to store the key itself within the app secrets.
+It is advisable to store the key itself within the app secrets.
 
 ```ruby
 JWTSessions.algorithm = "HS256"
 JWTSessions.encryption_key = Rails.application.secrets.secret_jwt_encryption_key
 ```
 
-Most of the encryption algorithms require private and public keys to sign a token, yet HMAC only require a single key, so you can use a shortcat `encryption_key` to sign the token. For other algorithms you must specify a private and public keys separately.
+Most of the encryption algorithms require private and public keys to sign a token. However, HMAC requires only a single key and you can use the `encryption_key` shortcut to sign the token. For other algorithms you must specify private and public keys separately.
 
 ```ruby
 JWTSessions.algorithm   = "RS256"
@@ -167,10 +167,11 @@ JWTSessions.private_key = OpenSSL::PKey::RSA.generate(2048)
 JWTSessions.public_key  = JWTSessions.private_key.public_key
 ```
 
-You can build login controller to receive access, refresh and csrf tokens in exchange for user's login/password. \
-Refresh controller - to be able to get a new access token using refresh token after access is expired. \
-Here is example of a simple login controller, which returns set of tokens as a plain JSON response. \
-It's also possible to set tokens as cookies in the response instead.
+You can build a login controller to receive access, refresh and CSRF tokens in exchange for the user's login/password. \
+Refresh controller allows you to get a new access token using the refresh token after access is expired. \
+
+Here is an example of a simple login controller, which returns a set of tokens as a plain JSON response. \
+It is also possible to set tokens as cookies in the response instead.
 
 ```ruby
 class LoginController < ApplicationController
@@ -187,7 +188,7 @@ class LoginController < ApplicationController
 end
 ```
 
-Now you can build a refresh endpoint. To protect the endpoint use before_action `authorize_refresh_request!`. \
+Now you can build a refresh endpoint. To protect the endpoint use the before_action `authorize_refresh_request!`. \
 The endpoint itself should return a renewed access token.
 
 ```ruby
@@ -205,15 +206,16 @@ class RefreshController < ApplicationController
   end
 end
 ```
-In the example `found_token` - is a token fetched from request headers or cookies. In the context of `RefreshController` it's a refresh token. \
-The refresh request with headers must include `X-Refresh-Token` (header name is configurable) with refresh token.
+
+In the above example, `found_token` is a token fetched from request headers or cookies. In the context of `RefreshController` it is a refresh token. \
+The refresh request with headers must include `X-Refresh-Token` (header name is configurable) with the refresh token.
 
 ```
 X-Refresh-Token: eyJhbGciOiJIUzI1NiJ9...
 POST /refresh
 ```
 
-Now when there're login and refresh endpoints, you can protect the rest of your secure controllers with `before_action :authorize_access_request!`.
+When there are login and refresh endpoints, you can protect the rest of your secured controllers with `before_action :authorize_access_request!`.
 
 ```ruby
 class UsersController < ApplicationController
@@ -228,6 +230,7 @@ class UsersController < ApplicationController
   end
 end
 ```
+
 Headers must include `Authorization: Bearer` with access token.
 
 ```
@@ -244,7 +247,7 @@ end
 ```
 
 Methods `authorize_refresh_request!` and `authorize_access_request!` will always try to fetch the tokens from the headers first and then from the cookies.
-For the cases when an endpoint must support only one specific token transport the next auth methods can be used instead:
+For the cases when an endpoint must support only one specific token transport the following authorization methods can be used instead:
 
 ```ruby
 authorize_by_access_cookie!
@@ -255,7 +258,7 @@ authorize_by_refresh_header!
 
 ### Non-Rails usage
 
-You must include `JWTSessions::Authorization` module to your auth class and implement within it next methods:
+You must include `JWTSessions::Authorization` module to your auth class and within it implement the following methods:
 
 1. request_headers
 
@@ -282,7 +285,7 @@ end
 ```
 
 Example Sinatra app. \
-NOTE: Since rack updates HTTP headers by using `HTTP_` prefix, upcasing and using underscores for sake of simplicity JWTSessions tokens header names are converted to rack-style in this example.
+NOTE: Rack updates HTTP headers by using the `HTTP_` prefix, upcasing and underscores for the sake of simplicity. JWTSessions token header names are converted to the rack-style in this example.
 
 ```ruby
 require "sinatra/base"
@@ -344,9 +347,9 @@ List of configurable settings with their default values.
 
 ##### Token store
 
-In order to configure token store you should set up a store adapter in a following way: `JWTSessions.token_store = :redis, { redis_url: 'redis://127.0.0.1:6379/0' }` (options can be omitted). Currently supported stores are `:redis` and `:memory`. Please note, that if you want to use Redis as a store then you should have `redis` gem listed in your Gemfile. If you won't configure the adapter explicitly, this gem will try to load `redis` and use it, otherwise it would fallback to a `memory` adapter.
+In order to configure a token store you should set up a store adapter in a following way: `JWTSessions.token_store = :redis, { redis_url: 'redis://127.0.0.1:6379/0' }` (options can be omitted). Currently supported stores are `:redis` and `:memory`. Please note, that if you want to use Redis as a store then you should have `redis` gem listed in your Gemfile. If you do not configure the adapter explicitly, this gem will try to load `redis` and use it. Otherwise it will fall back to a `memory` adapter.
 
-Memory store accepts only `prefix` (used for redis db keys). Here is a default configuration for Redis:
+Memory store only accepts a `prefix` (used for Redis db keys). Here is a default configuration for Redis:
 
 ```ruby
 JWTSessions.token_store = :redis, {
@@ -371,7 +374,7 @@ JWTSessions.token_store = :redis, { redis_url: "redis://localhost:6397" }
 JWTSessions.algorithm = "HS256"
 ```
 
-You need to specify a secret to use for HMAC, this setting doesn"t have a default value.
+You need to specify a secret to use for HMAC as this setting does not have a default value.
 
 ```ruby
 JWTSessions.encryption_key = "secret"
@@ -384,9 +387,9 @@ JWTSessions.private_key = "abcd"
 JWTSessions.public_key  = "efjh"
 ```
 
-NOTE: ED25519 and HS512256 require rbnacl installation in order to make it work.
+NOTE: ED25519 and HS512256 require `rbnacl` installation in order to make it work.
 
-jwt_sessions only uses `exp` claim by default when it decodes tokens, you can specify which additional claims to use by
+jwt_sessions only uses `exp` claim by default when it decodes tokens and you can specify which additional claims to use by
 setting `jwt_options`. You can also specify leeway to account for clock skew.
 
 ```ruby
@@ -413,11 +416,11 @@ class UsersController < ApplicationController
 end
 ```
 
-Claims are also supported by `JWTSessions::Session`, you can pass `access_claims` and `refresh_claims` options in the initializer.
+Claims are also supported by `JWTSessions::Session` and you can pass `access_claims` and `refresh_claims` options in the initializer.
 
 ##### Request headers and cookies names
 
-Default request headers/cookies names can be re-configured
+Default request headers/cookies names can be reconfigured.
 
 ```ruby
 JWTSessions.access_header  = "Authorization"
@@ -429,19 +432,19 @@ JWTSessions.csrf_header    = "X-CSRF-Token"
 
 ##### Expiration time
 
-Access token must have a short life span, while refresh tokens can be stored for a longer time period
+Access token must have a short life span, while refresh tokens can be stored for a longer time period.
 
 ```ruby
 JWTSessions.access_exp_time = 3600 # 1 hour in seconds
 JWTSessions.refresh_exp_time = 604800 # 1 week in seconds
 ```
 
-It's defined globally, but can be overridden on a session level. See `JWTSessions::Session.new` options for more info.
+It is defined globally, but can be overridden on a session level. See `JWTSessions::Session.new` options for more info.
 
 #### CSRF and cookies
 
-In case when you use cookies as your tokens transport it gets vulnerable to CSRF. That's why both login and refresh methods of the `Session` class produce CSRF tokens for you. `Authorization` mixin expects that this token is sent with all requests except GET and HEAD in a header specified among this gem's settings (X-CSRF-Token by default). Verification will be done automatically and `Authorization` exception will be raised in case of mismatch between the token from the header and the one stored in session. \
-Although you don't need to mitigate BREACH attacks it's still possible to generate a new masked token with the access token.
+When you use cookies as your tokens transport it becomes vulnerable to CSRF. That is why both the login and refresh methods of the `Session` class produce CSRF tokens for you. `Authorization` mixin expects that this token is sent with all requests except GET and HEAD in a header specified among this gem's settings (`X-CSRF-Token` by default). Verification will be done automatically and the `Authorization` exception will be raised in case of a mismatch between the token from the header and the one stored in the session. \
+Although you do not need to mitigate BREACH attacks it is still possible to generate a new masked token with the access token.
 
 ```ruby
 session = JWTSessions::Session.new
@@ -450,10 +453,11 @@ session.masked_csrf(access_token)
 
 ##### Refresh with access token
 
-Sometimes it's not secure enough to store the refresh tokens in web / JS clients. \
-That's why you have a possibility to operate only by an access token, and to not pass the refresh to the client at all. \
-Session accepts `refresh_by_access_allowed: true` setting, which links the access token to the according refresh token. \
-Example Rails login controller, which passes an access token token via cookies and renders CSRF.
+Sometimes it is not secure enough to store the refresh tokens in web / JS clients. \
+This is why you have the option to only use an access token and to not pass the refresh token to the client at all. \
+Session accepts `refresh_by_access_allowed: true` setting, which links the access token to the corresponding refresh token. \
+
+Example Rails login controller, which passes an access token token via cookies and renders CSRF:
 
 ```ruby
 class LoginController < ApplicationController
@@ -477,17 +481,18 @@ class LoginController < ApplicationController
 end
 ```
 
-The gem provides an ability to refresh the session by access token.
+The gem provides the ability to refresh the session by access token.
 
 ```ruby
 session = JWTSessions::Session.new(payload: payload, refresh_by_access_allowed: true)
 tokens  = session.refresh_by_access_payload
 ```
 
-In case of token forgery and successful refresh performed by an atacker - the original user will have to logout. \
-To protect the endpoint use before_action `authorize_refresh_by_access_request!`. \
-Example Rails refresh by access controller with cookies as token transport. \
-As refresh should be performed once the access token is already expired we need to use `claimless_payload` method in order to skip JWT expiration validation (and other claims) so we can proceed.
+In case of token forgery and successful refresh performed by an attacker the original user will have to logout. \
+To protect the endpoint use the before_action `authorize_refresh_by_access_request!`. \
+Refresh should be performed once the access token is already expired and we need to use the `claimless_payload` method in order to skip JWT expiration validation (and other claims) in order to proceed. \
+
+Example Rails refresh by access controller with cookies as token transport:
 
 ```ruby
 class RefreshController < ApplicationController
@@ -507,7 +512,7 @@ end
 
 ```
 
-For the cases when an endpoint must support only one specific token transport the next auth methods can be used instead:
+For the cases when an endpoint must support only one specific token transport the following auth methods can be used instead:
 
 ```ruby
 authorize_refresh_by_access_cookie!
@@ -516,8 +521,8 @@ authorize_refresh_by_access_header!
 
 #### Refresh token hijack protection
 
-There is a security recommendation regarding the usage of refresh tokens: only perform refresh when an access token gets expired. \
-Since sessions are always defined by a pair of tokens and there can't be multiple access tokens for a single refresh token simultaneous usage of the refresh token by multiple users can be easily noticed as refresh will be perfomed before the expiration of the access token by one of the users. Because of that `refresh` method of the `Session` class supports optional block as one of its arguments which will be executed only in case of refresh being performed before the expiration of the access token.
+There is a security recommendation regarding the usage of refresh tokens: only perform refresh when an access token expires. \
+Sessions are always defined by a pair of tokens and there cannot be multiple access tokens for a single refresh token. Simultaneous usage of the refresh token by multiple users can be easily noticed as refresh will be performed before the expiration of the access token by one of the users. As a result, `refresh` method of the `Session` class supports an optional block as one of its arguments which will be executed only in case of refresh being performed before the expiration of the access token.
 
 ```ruby
 session = JwtSessions::Session.new(payload: payload)
@@ -526,7 +531,7 @@ session.refresh(refresh_token) { |refresh_token_uid, access_token_expiration| ..
 
 ## Flush Sessions
 
-Flush a session by its refresh token. The method returns number of flushed sessions.
+Flush a session by its refresh token. The method returns number of flushed sessions:
 
 ```ruby
 session = JWTSessions::Session.new
@@ -534,7 +539,7 @@ tokens = session.login
 session.flush_by_token(tokens[:refresh]) # => 1
 ```
 
-Flush a session by its access token.
+Flush a session by its access token:
 
 ```ruby
 session = JWTSessions::Session.new(refresh_by_access_allowed: true)
@@ -545,7 +550,7 @@ session = JWTSessions::Session.new(refresh_by_access_allowed: true, payload: pay
 session.flush_by_access_payload
 ```
 
-Or by refresh token UID
+Or by refresh token UID:
 
 ```ruby
 session.flush_by_uid(uid) # => 1
@@ -553,27 +558,28 @@ session.flush_by_uid(uid) # => 1
 
 ##### Sessions namespace
 
-It's possible to group sessions by custom namespaces
+It's possible to group sessions by custom namespaces:
 
 ```ruby
 session = JWTSessions::Session.new(namespace: "account-1")
 ```
 
-and selectively flush sessions by namespace
+Selectively flush sessions by namespace:
 
 ```ruby
 session = JWTSessions::Session.new(namespace: "ie-sessions")
 session.flush_namespaced # will flush all sessions which belong to the same namespace
 ```
 
-it's posible to flush access tokens only
+Flush access tokens only:
 
 ```ruby
 session = JWTSessions::Session.new(namespace: "ie-sessions")
 session.flush_namespaced_access_tokens # will flush all access tokens which belong to the same namespace, but will keep refresh tokens
 ```
 
-To force flush of all app sessions
+Force flush of all app sessions:
+
 ```ruby
 JWTSessions::Session.flush_all
 ```
@@ -583,14 +589,14 @@ JWTSessions::Session.flush_all
 To logout you need to remove both access and refresh tokens from the store. \
 Flush sessions methods can be used to perform logout. \
 Refresh token or refresh token UID is required to flush a session. \
-To logout with an access token `refresh_by_access_allowed` setting should be set to true on an access token creation. If logout by access token is allowed it's recommended to ignore the expiration claim and to allow to logout with expired access token.
+To logout with an access token, `refresh_by_access_allowed` should be set to true on access token creation. If logout by access token is allowed it is recommended to ignore the expiration claim and to allow to logout with the expired access token.
 
 ## Examples
 
 [Rails API](test/support/dummy_api) \
 [Sinatra API](test/support/dummy_sinatra_api)
 
-You can use a mixed approach for the cases when you'd like to store an access token in localStorage and refresh token in HTTP-only secure cookies. \
+You can use a mixed approach for the cases when you would like to store an access token in localStorage and refresh token in HTTP-only secure cookies. \
 Rails controllers setup example:
 
 ```ruby

data/lib/jwt_sessions/refresh_token.rb

@@ -41,8 +41,10 @@ module JWTSessions
         end
       end
 
-      def find(uid, store, namespace = nil)
-        token_attrs = store.fetch_refresh(uid, namespace)
+      # first_match should be set to true when
+      # we need to search through the all namespaces
+      def find(uid, store, namespace = nil, first_match: false)
+        token_attrs = store.fetch_refresh(uid, namespace, first_match)
         raise Errors::Unauthorized, "Refresh token not found" if token_attrs.empty?
         build_with_token_attrs(store, uid, token_attrs, namespace)
       end

data/lib/jwt_sessions/session.rb

@@ -114,7 +114,7 @@ module JWTSessions
       ruid = retrieve_val_from(external_payload, :access, "ruid", "refresh uid")
       uid  = retrieve_val_from(external_payload, :access, "uid", "access uid")
 
-      refresh_token = RefreshToken.find(ruid, JWTSessions.token_store)
+      refresh_token = RefreshToken.find(ruid, JWTSessions.token_store, first_match: true)
       return false unless uid == refresh_token.access_uid
 
       CSRFToken.new(refresh_token.csrf).valid_authenticity_token?(external_csrf_token)

data/lib/jwt_sessions/store_adapters/memory_store_adapter.rb

@@ -22,7 +22,7 @@ module JWTSessions
         storage[""]["access"].store(uid, access_token)
       end
 
-      def fetch_refresh(uid, namespace)
+      def fetch_refresh(uid, namespace, _first_match = false)
         value_if_not_expired(uid, "refresh", namespace.to_s)
       end
 

data/lib/jwt_sessions/store_adapters/redis_store_adapter.rb

@@ -31,8 +31,9 @@ module JWTSessions
         storage.expireat(key, expiration)
       end
 
-      def fetch_refresh(uid, namespace)
-        values = storage.hmget(refresh_key(uid, namespace), *REFRESH_KEYS).compact
+      def fetch_refresh(uid, namespace, first_match = false)
+        key    = first_match ? first_refresh_key(uid) : full_refresh_key(uid, namespace)
+        values = storage.hmget(key, *REFRESH_KEYS).compact
 
         return {} if values.length != REFRESH_KEYS.length
         REFRESH_KEYS.each_with_index.each_with_object({}) { |(key, index), acc| acc[key] = values[index] }
@@ -69,7 +70,8 @@ module JWTSessions
       end
 
       def destroy_refresh(uid, namespace)
-        storage.del(refresh_key(uid, namespace))
+        key = full_refresh_key(uid, namespace)
+        storage.del(key)
       end
 
       def destroy_access(uid)
@@ -107,16 +109,14 @@ module JWTSessions
         "#{prefix}_#{namespace}_refresh_#{uid}"
       end
 
-      def refresh_key(uid, namespace)
-        if namespace.to_s.empty?
-          wildcard_refresh_key(uid)
-        else
-          full_refresh_key(uid, namespace)
-        end
+      def first_refresh_key(uid)
+        key = full_refresh_key(uid, "*")
+        (storage.keys(key) || []).first
       end
 
-      def wildcard_refresh_key(uid)
-        (storage.keys(refresh_key(uid, "*")) || []).first
+      def refresh_key(uid, namespace)
+        namespace = "*" if namespace.to_s.empty?
+        full_refresh_key(uid, namespace)
       end
 
       def access_key(uid)

data/lib/jwt_sessions/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module JWTSessions
-  VERSION = "2.4.1"
+  VERSION = "2.4.2"
 end

data/test/units/jwt_sessions/test_refresh_token.rb

@@ -7,6 +7,8 @@ class TestRefreshToken < Minitest::Test
    attr_reader :csrf, :token, :access_uid
 
   def setup
+    JWTSessions::Session.flush_all
+
     JWTSessions.encryption_key = "secure encryption"
     @access_uid = SecureRandom.uuid
     @csrf = JWTSessions::CSRFToken.new
@@ -39,4 +41,18 @@ class TestRefreshToken < Minitest::Test
       JWTSessions::RefreshToken.find(token.uid, JWTSessions.token_store, nil)
     end
   end
+
+  def test_all
+    access_uid_2 = SecureRandom.uuid
+    csrf_2       = JWTSessions::CSRFToken.new
+    token_2      = JWTSessions::RefreshToken.create(
+      csrf_2.encoded,
+      access_uid_2,
+      JWTSessions.access_expiration - 5,
+      JWTSessions.token_store,
+      {},
+      nil
+    )
+    assert_equal [token.token, token_2.token].sort, JWTSessions::RefreshToken.all(nil, JWTSessions.token_store).map(&:token).sort
+  end
 end

data/test/units/jwt_sessions/test_session.rb

@@ -296,7 +296,7 @@ class TestSession < Minitest::Test
 
     session.flush_namespaced_access_tokens
     ruid = session.instance_variable_get(:"@_refresh").uid
-    refresh_token = JWTSessions::RefreshToken.find(ruid, JWTSessions.token_store, nil)
+    refresh_token = JWTSessions::RefreshToken.find(ruid, JWTSessions.token_store, namespace)
     assert_equal "", refresh_token.access_uid
     assert_equal "", refresh_token.access_expiration
 
@@ -306,7 +306,7 @@ class TestSession < Minitest::Test
     end
     auid = session.instance_variable_get(:"@_access").uid
     access_token = JWTSessions::AccessToken.find(auid, JWTSessions.token_store)
-    refresh_token = JWTSessions::RefreshToken.find(ruid, JWTSessions.token_store, nil)
+    refresh_token = JWTSessions::RefreshToken.find(ruid, JWTSessions.token_store, namespace)
 
     assert_equal false, access_token.uid.size.zero?
     assert_equal false, access_token.expiration.size.zero?

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: jwt_sessions
 version: !ruby/object:Gem::Version
-  version: 2.4.1
+  version: 2.4.2
 platform: ruby
 authors:
 - Yulia Oletskaya
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2019-05-25 00:00:00.000000000 Z
+date: 2019-07-30 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: jwt
@@ -137,7 +137,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.7.6
+rubygems_version: 2.6.13
 signing_key: 
 specification_version: 4
 summary: JWT Sessions