global_session 3.2.10 → 3.3.0

data/lib/global_session/version.rb

@@ -0,0 +1,3 @@
+module GlobalSession
+  VERSION = '3.3.0'
+end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: global_session
 version: !ruby/object:Gem::Version
-  version: 3.2.10
+  version: 3.3.0
 platform: ruby
 authors:
 - Tony Spataro
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2016-09-30 00:00:00.000000000 Z
+date: 2016-12-21 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: json
@@ -42,22 +42,22 @@ dependencies:
   name: right_support
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "<"
-      - !ruby/object:Gem::Version
-        version: '4.0'
     - - ">="
       - !ruby/object:Gem::Version
-        version: 2.8.2
+        version: 2.14.1
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '3.0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "<"
-      - !ruby/object:Gem::Version
-        version: '4.0'
     - - ">="
       - !ruby/object:Gem::Version
-        version: 2.8.2
+        version: 2.14.1
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '3.0'
 - !ruby/object:Gem::Dependency
   name: simple_uuid
   requirement: !ruby/object:Gem::Requirement
@@ -72,82 +72,13 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: 0.2.0
-- !ruby/object:Gem::Dependency
-  name: ruby-debug
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.10'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.10'
-- !ruby/object:Gem::Dependency
-  name: pry
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.10'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.10'
-- !ruby/object:Gem::Dependency
-  name: pry-byebug
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '2.0'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '2.0'
-- !ruby/object:Gem::Dependency
-  name: jeweler
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '1.8'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '1.8'
-description: This Rack middleware allows several web apps in an authentication domain
-  to share session state, facilitating single sign-on in a distributed web app. It
-  only provides session sharing and does not concern itself with authentication or
-  replication of the user database.
-email: support@rightscale.com
+description: A toolkit of useful, reusable foundation code created by RightScale.
+email: rubygems@rightscale.com
 executables: []
 extensions: []
-extra_rdoc_files:
-- LICENSE
-- README.rdoc
+extra_rdoc_files: []
 files:
-- ".ruby-version"
-- ".travis.yml"
-- CHANGELOG.md
-- LICENSE
-- README.rdoc
-- Rakefile
-- VERSION
 - global_session.gemspec
-- init.rb
 - lib/global_session.rb
 - lib/global_session/configuration.rb
 - lib/global_session/directory.rb
@@ -162,13 +93,9 @@ files:
 - lib/global_session/session/v1.rb
 - lib/global_session/session/v2.rb
 - lib/global_session/session/v3.rb
-- rails/init.rb
-- rails_generators/global_session/USAGE
-- rails_generators/global_session/global_session_generator.rb
-- rails_generators/global_session/templates/global_session.yml.erb
-- rails_generators/global_session_authority/USAGE
-- rails_generators/global_session_authority/global_session_authority_generator.rb
-homepage: https://github.com/rightscale/global_session
+- lib/global_session/session/v4.rb
+- lib/global_session/version.rb
+homepage: https://github.com/rightscale/right_support
 licenses:
 - MIT
 metadata: {}
@@ -180,7 +107,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
   - - "~>"
     - !ruby/object:Gem::Version
-      version: '2.0'
+      version: '2.1'
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
@@ -191,5 +118,5 @@ rubyforge_project:
 rubygems_version: 2.2.3
 signing_key: 
 specification_version: 4
-summary: Secure single-domain session sharing plugin for Rack and Rails.
+summary: Reusable foundation code.
 test_files: []

data/.ruby-version

@@ -1 +0,0 @@
-2.1.6

data/.travis.yml

@@ -1,11 +0,0 @@
-language: ruby
-cache: bundler
-rvm:
-  - 1.8.7
-  - 2.1.8
-before_install:
-  - sudo apt-get -qq update
-  - sudo apt-get install -y libgmp3-dev
-script:
-  - bundle exec rake ci:spec
-bundler_args: --without development

data/CHANGELOG.md

@@ -1,94 +0,0 @@
-3.2.1 (2015-07-10)
----------------
-
-Fixed a bug with automatic cookie renewal; cookies were not being renewed unless
-the `authority` directive was present in the configuration.
-
-3.2.0 (2015-07-08)
-------------------
-
-If cookie domain is omitted from configuration, the Rack middleware will 
-guess a suitable domain by looking at the HTTP Host header (or `X-Forwarded-Host` 
-if it is present, i.e. the request has passed through a load balancer). The
-heuristic for HTTP-host-to-cookie-domain is:
-
-* Numeric IPv4: `127.0.0.1` -> _no_ domain
-* 1-component: `localhost` -> _no_ domain
-* 2-component: `example.com` -> `example.com` 
-* N-component: `foo.test.example.com` -> `test.example.com`
-
-This doesn't handle country-code TLDs (`.co.uk`) so you'll still need to specify
-the cookie domain for Web sites under a ccTLD.
-
-The Rack middleware will guess whether to add the `secure` flag to cookies
-based on `rack.url_scheme` (or `X-Forwarded-Proto` if it is present).
-
-3.1 (2015-01-27)
-----------------
-
-Split Directory class into Directory & Keystore, retaining some backward-compatibility shims
-inside Directory. In v4, these shims will be removed and all key management concerns will be
-handled by Keystore; the Directory class will be limited to session creation, renewal, and
-validity checking.
-
-The `trust` and `authority` configuration elements have been deprecated, as ha
-the ability to pass a keystore directory to `Directory.new`. Instead, the
-configuration should contain a `keystore` that tells the gem where to find its
-public and private keys; every public key is implicitly trusted, and if some
-private key is found, the app is an authority (otherwise it's not an authority
-and sessions are read-only). Example new configuration:
-
-    keystore:
-      public:
-        - config/authorities
-        - config/other_dir_with_keys_i_should_trust
-      private: /etc/my_private.key
-      
-As with any other Global Session configuration, this stanza can appear under
-`common` or under an enivronment-specific section (`staging`, `production`, etc).
-
-Finally, you can pass a private key location in the environment variable named
-`GLOBAL_SESSION_PRIVATE_KEY` instead of including that information in the
-configuration.
-
-3.0 (2013-10-03)
-----------------
-
-The format of the global session cookie has been reinvented again! It once again uses JSON
-(because msgpack was not widely supported in other languages/OSes) but retains the compact
-array encoding introduced in v2.
-
-The cryptographic signature scheme has been changed for better compatibility; we now use
-PKCS1 v1.5 sign and verify operations instead of "raw" RSA. v2 and v1 sessions are fully
-supported for read/write, but any session created with the v3 gem will use the v3 crypto
-scheme.
-
-2.0 (2012-11-06)
-----------------
-
-The format of the global session cookie has been reinvented; it now uses msgpack and delegates
-all crypto to RightSupport::Crypto::SignedHash. Together with a few other optimizations, the
-size of the cookie has shrunk by about 30%.
-
-The gem remains capable of reading and writing V1 format cookies, but all new cookies are created
-with the V2 format.
-
-The "integrated" feature is no longer supported for the Rails integration layer; global session
-attributes must always be accessed separately from local session attributes, through the
-#global_session reader method that is mixed into ActionController::Base.
-
-1.0 (2011-01-01)
-----------------
-
-General Availability release. Mostly interface-compatible with 0.9.
-
-0.9 (2010-12-07)
-----------------
-
-Rack middleware implementation is feature-complete and has major spec coverage. Rails integration
-is untested and may contain bugs.
-
-0.9.0 (2010-12-22)
-----------------
-
-Initial commit ported from 'rack' branch of old has_global_session project

data/LICENSE

@@ -1,20 +0,0 @@
-Copyright (c) 2009-2015 RightScale, Inc.
-
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-'Software'), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-
-The above copyright notice and this permission notice shall be
-included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
-IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
-CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
-TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
-SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.rdoc

@@ -1,298 +0,0 @@
-Copyright (c) 2009-2015 RightScale, Inc. <support@rightscale.com>; see LICENSE for more details.
-
-= Preamble
-
-<b>WARNING:</b> This RubyGem was authored in 2010 when Rails 2.1 was state of
-the art. Its Rails integration has not been kept up to date over time; it is
-untested with Rails 3, 4 and 5, and its generators are broken with Rails above
-2.3.5.
-
-We continue to support the Rack middleware and other components of this gem,
-and recommend using it as a plain old Rack middleware in your Rails apps.
-Instructions for doing so are provided in this README.
-
-= Introduction
-
-GlobalSession enables multiple heterogeneous Web applications to share
-session state in a cryptographically secure way, facilitating single sign-on
-and enabling easier development of distributed applications that make use of
-architectural strategies such as sharding or separation of concerns.
-
-In other words: it glues your Web apps together by letting them share session state.
-This is done by putting the session itself into a cookie and adding some crypto to
-protect against tampering.
-
-Maintained by
- - [RightScale Engineering](https://github.com/rightscale)
-
-Merge to master whitelist
- - @tony-spataro-rs
-
-== What Is It Not?
-
-This gem does not provide a complete solution for identity management. In
-particular, it does not provide any of the following:
-
-* <b>federation</b> -- aka cross-domain single sign-on -- use SAML for that.
-
-* <b>authentication</b> -- the application must authenticate the user.
-
-* <b>authorization</b> -- the application is responsible for using the contents
-  of the global session to make authorization decisions.
-
-* <b>secrecy</b> -- global session attributes can be signed but never encrypted.
-  Protect against third-party snooping using SSL. Group secrecy is expensive;
-  if you don't want your users to see their session state, put it in a database,
-  or in an encrypted local session cookie.
-
-* <b>replication</b> -- the session authorities must have some way to
-  share information about the database of users in order to authenticate
-  them and place identifying information into the global session.
-
-* <b>single sign-out</b> -- the authorities must have some way to broadcast a
-  notification when sessions are invalidated; they can override the default
-  Directory implementation to do realtime revocation checking.
-
-= Examples
-
-== Make a YML configuration file
-
-The config file format is designed to be self-documenting. The most important
-data are: what data can be in your global session (`attributes`), what
-directory contains your `.pub` files with authorities' public keys (`keystore.public`),
-and the locatio nof `.key` private key file, if any, used by this app (`keystore.private`).
-
-You can omit `keystore.private` if the app should be able to read, but not
-write, global sessions.
-
-If you have asymmetrical trust (e.g. dev trusts production but not vice-versa),
-you can include an optional `trust` list. By default, every public key file is
-trusted.
-
-    common:
-      attributes:
-        signed:
-        - user
-        insecure:
-        - favorite_color
-      cookie:
-        name: global_session
-      keystore:
-        public: config/authorities
-      renew: 30
-      timeout: 60
-    development:
-      keystore:
-        private: config/authorities/dev
-    production:
-    trust:
-      - prod
-    keystore:
-      private: config/authorities/prod
-
-== Make a new keypair for a GlobalSession authority
-
-Decide on a name for your authority. The name is a short string that identifies
-a pair of key files on disk (one public, one private) which will be used to
-sign and verify sessions. If you have mutual trust between every app in your
-architecture, then you only need one authority and your domain name, e.g.
-`example-com`, is a fine choice of name. If you want partition trust within your
-architecture, then authorities could be named after environments
-(`staging`, `production`), regions (`us`, `eu`) or even specific apps
-(`frontend`, `api`) depending on where you draw the trust boundaries.
-
-Figure out where key files live in your application. This is whatever value
-you set in the `keystore: public: ...` directive in the configuration.
-
-If you have complete, mutual trust between all components of your architecture,
-then something based on your organization's domain name (e.g. `example-com`)
-is a fine choice.
-
-Open irb or your console of choice and require the `global_session` gem.
-
-    # default is RSA cryptosystem with 1024-bit keys.
-    keypair = GlobalSession::Keystore.create_keypair(:RSA, 1024)
-    public_pem  = keypair.public_key.to_pem
-    private_pem = keypair.to_pem
-
-    # write keys to disk
-    File.open('config/authorities/example-com.pub', 'w') { |f| f.write public_pem }
-    File.open('config/authorities/example-com.key', 'w') { |f| f.write private_pem }
-
-== Integration with Rails
-
-Install the GlobalSession middleware in your application startup. Open
-`environment.rb` or `application.rb` (depending on your Rails version) and
-add a new file to `config/initializers` to configure and install the
-middleware:
-
-    configuration = GlobalSession::Configuration.new('config/global_session.yml', Rails.env)
-    directory = GlobalSession::Directory.new(configuration)
-
-== Integration with Rack
-
-Install the GlobalSession middleware into your Rack stack; pass a config and a directory
-object to its initializer. For instance, in config.ru:
-
-    configuration = GlobalSession::Configuration.new('path/to/config.yml', RACK_ENV)
-    directory = GlobalSession::Directory.new(configuration)
-    use ::GlobalSession::Rack::Middleware, configuration, directory
-
-    Application.config.middleware.insert_before(Application.config.session_store, ::Rack::Cookies)
-    Application.config.middleware.insert_before(Application.config.session_store, ::Rack::GlobalSession, configuration, directory)
-
-Note that the GlobalSession middleware depends on `Rack::Cookies`; be sure
-to install them both, and in the proper order.
-
-= Global Session Contents
-
-Global session state is stored as a cookie in the user's browser and/or sent
-with every request as an HTTP Authorization header. If your app uses the
-Authorization header, then it's responsible for communicating new or changed
-header values to clients out-of-band (i.e. as part of an OAuth refresh-token
-operation). If your app uses the cookie, GlobalSession will take care of
-updating the cookie whenever session values change.
-
-Data-wise, the session is a JSON dictionary containing the following stuff:
-* session metadata (UUID, created at, expires at, signing authority)
-* signed session attributes (e.g. the authenticated user ID)
-* insecure session attributes (e.g. the last-visited URL)
-* a cryptographic signature of the metadata and signed attributes
-
-The global session is unserialized and its signature is verified whenever
-Rack receives a request. The cookie's value is updated whenever attributes
-change. As an optimization, the signature is only recomputed when the metadata
-or signed attributes have changed; insecure attributes can change "for free."
-
-Because the security properties of attributes can vary, GlobalSession
-requires all _possible_ attributes to be declared up-front in the config
-file. The 'attributes' section of the config file defines the _schema_
-for the global session: which attributes can be used, which can be trusted
-to make authorization decisions (because they are signed), and which are
-insecure and act only as "hints" about the session.
-
-Since the session is serialized as JSON, only a limited range of object
-types can be stored in it: nil, strings, numbers, lists, hashes, booleans
-and other Ruby primitives.
-
-= Detailed Information
-
-== Global Session Domain
-
-We refer to collection of _all_ Web application instances capable of using the
-global session as the "domain." The global session domain may consist of any
-number of distinct nodes, possibly hidden behind load balancers or proxies.
-The nodes within the domain may all be running the same Rails application,
-or they may be running different codebases that represent different parts of
-a distributed application. (They may also be using app frameworks other than
-Rails.)
-
-The only constraint imposed by GlobalSession is that all nodes within the
-domain must have end-user-facing URLs within the same second-level DNS domain.
-This is due to limitations imposed by the HTTP cookie mechanism: for privacy
-reasons, cookies will only be sent to nodes within the same domain as the
-node that first created them.
-
-For example, in my GlobalSession configuration file I might specify that my
-cookie's domain is "example.com". My app nodes at app1.example.com and
-app2.example.com would be part of the global session domain, but my business
-partner's application at app3.partner.com could not participate.
-
-If your app uses an Authorization header instead of cookies, the domain-name
-constraint does not apply!
-
-== Authorities and Relying Parties
-
-A node that can create or update the global session is said to be an "authority"
-(because it's trusted by other parties to make assertions about global session
-state). An application that can read the global session is said to be a "relying
-party." In practice, every application is a relying party, but not all of them
-need to be authorities.
-
-There is an RSA key pair associated with each authority. The authority's
-public key is distribued to all relying parties, but the private key must
-remain a secret to that authority (which may consist of many individual
-nodes).
-
-This system allows for significant flexibility when configuring a distributed
-app's global session. There must be at least one authority, but for many apps
-one authority (plus an arbitrary number of relying parties, which do not need
-a key pair) will be sufficient.
-
-In general, two systems should be part of the same authority if there is no
-trust boundary between them -- that is to say, trust between the two systems
-is unlimited in both directions.
-
-Here are some reasons you might consider dividing your systems into different
-authorities:
-* beta/staging system vs. production system
-* system hosted by a third party vs. system hosted internally
-* e-commerce app vs. storefront app vs. admin app
-
-== The Keystore
-
-The Directory is a Ruby object that provides lookups of public and private
-keys. Given an authority name (as found in a session cookie), the Directory
-can find the corresponding RSA public key.
-
-If the local system is an authority itself, #private_key_name will
-return the authority name and #private_key will return an RSA private key
-suitable for signing session attributes.
-
-The Keystore implementation included with GlobalSession uses the filesystem
-as the backing store for its key pairs. Its #initialize method accepts a
-filesystem path that will be searched for files containing PEM-encoded public
-and private keys (the same format used by OpenSSH). This simple Directory
-implementation relies on the following conventions:
-* Public keys have a *.pub extension.
-* Private keys have a *.key extension.
-* If a node is an authority, then one (and *only* one) *.key file should exist.
-* The local node's authority name is inferred from the name of the private key
-  file.
-
-When used with a Rails app, GlobalSession expects to find its keystore in
-config/authorities. You can use the global_session generator to create new key
-pairs. Remember never to check a *.key file into a public repository!! (*.pub
-files can be checked into source control and distributed freely.)
-
-If you wish all of the systems to stop trusting an authority, simply delete
-its public key from config/authorities and re-deploy your app.
-
-The keystore needs to be told where to find its keys. This is accomplished by
-setting some configuration attributes like so:
-
-    keystore:
-      public:
-        - config/authorities
-        - config/more_authorities
-      private: config/authorities/my_private.key
-
-The filename of keys is relevant; after stripping the *.pub or *.key extension,
-the remainder of the file's basename is taken to be the authority name. For
-instance, "production.pub" is the public key of the authority named "production"
-and "development.key" is the private key of the authority named "development."
-
-== The Directory
-
-The Directory is a Ruby object that performs session management operations,
-including:
-* Checking whether sessions have become invalid (e.g. after sign-out)
-* Creating new sessions
-* Unserializing existing sessions
-* Renewing sessions if they will expire
-* Updating session signatures
-
-In GlobalSession v3, Directory also presents methods for key management, but
-these are all delegated to the Keystore class. In v4, the concerns of Directory
-and Keystore will be fully separated.
-
-=== Implementing Your Own Directory Provider
-
-To replace or enhance the built-in Directory, simply create a new class that
-extends Directory and put the class somewhere in your app (the lib directory
-is a good choice). In the GlobalSession configuration file, specify the
-class name of the directory under the 'common' section, like so:
-
-    common:
-      directory:
-        class: MyCoolDirectory