- The roots of this gem are ancient, and there are more modern options.
- This gem is based on OpenID 2.0, which is a deprecated standard.
- The modern alternative is called OpenID Connect (OIDC).
- This gem does not support OIDC.
- Many, if not all, of the current security vulnerabilities will not be fixed.
- The purpose of this gem is to help legacy systems modernize, one step at a time, by allowing them to get onto modern Ruby / Rails.
- If you find this useful, please consider sponsoring me!
Masq2 is a mountable Rails engine that provides OpenID server/identity provider functionality. It is the successor to the masq gem, which in turn was the successor of the stand-alone Rails application of the same purpose, masquerade.
Because of this history, and the desire to be drop-in compatible with masq
,
the namespace remains Masq
, not Masq2
.
The project is released under the MIT-License and its source code is available at GitHub. Feel free to fork and submit patches :)
Tokens to Remember | |
---|---|
Works with MRI Ruby 3 | |
Works with MRI Ruby 2 | |
Source | |
Documentation | |
Compliance | |
Expert 1:1 Support | or |
Enterprise Support | π‘Subscribe for support guarantees covering all FLOSS dependencies! π‘Tidelift is part of Sonar! π‘Tidelift pays maintainers to maintain the software you depend on! π @ Pointy Haired Boss: An enterprise support subscription is "never gonna let you down", and supports open source maintainers! |
Comrade BDFL ποΈ | |
... π |
-
In case you want to run Masq2 as a standalone application (not integrated into an existing app), you will have to generate a bare-bone Rails app first:
rails new my_openid_provider
-
Add
masq2
to your Gemfile and install it:gem 'masq2'
bundle install
-
Copy the configuration and edit it:
bundle exec rake masq:install:config
$EDITOR config/masq.yml
-
Copy the migrations and migrate:
bundle exec rake masq:install:migrations
bundle exec rake db:migrate
-
Configure the routes by mounting the masq engine:
- For integration into an existing app, mount it in a subdirectory, like:
mount Masq::Engine => "/masq"
ormount Masq::Engine => "/openid"
- Standalone installation, mount it at the root:
mount Masq::Engine => "/"
- For integration into an existing app, mount it in a subdirectory, like:
You can test the functionality in your local environment starting two instances: One as your Identity Provider/OpenID Server and another one as Relying Party.
* `rails server`
* `rails server -p 3001`
Open your browser with these urls (assumes you mounted the engine at /masq):
* [http://localhost:3000/masq](http://localhost:3000/masq) (Identity Provider)
* [http://localhost:3001/masq/consumer](http://localhost:3001/masq/consumer) (Relying Party testsuite)
First you have to create an account at the Identity Provider, after that you will be able
to use the issued OpenID URL (http://localhost:3000/masq/YOUR_LOGIN
) to send requests from the
Relying Party to the server.
Use the options provided by the OpenID verification form to test several aspects of the client-server communication (like requesting simple registration data).
masq2
adds ORACLE database support, as well as support for
Rails 5.2, 6.0, 6.1, 7.0, 7.1, 7.2, 8.0,
which masq
never had.
The main functionality is in the server controller, which is the endpoint for incoming OpenID requests. The server controller is supposed to only interact with relying parties a.k.a. consumer websites. It includes the OpenidServerSystem module, which provides some handy methods to access and answer OpenID requests.
[πAlso Rails 5.2+ / Serialization / Psych Caveats]
v1 release has a breaking change from the ancient masq v0.3.4 release. Continue reading if you think it may impact you.
Rails 5.2.8.1 is a security patch release to fix CVE-2022-32224. See: https://discuss.rubyonrails.org/t/cve-2022-32224-possible-rce-escalation-bug-with-serialized-columns-in-active-record/81017
The patch (Rails v5.2.8.1) causes an error with masq
v0.3.4
(... actually it doesn't work at all on Rails v5, but some forks have been fixed):
Psych::DisallowedClass: Tried to load unspecified class: ActiveSupport::HashWithIndifferentAccess
when serializing a Hash the way we had done in previous versions app/models/masq/open_id_request.rb
:
serialize :parameters, Hash
so we instead switch to serializing as JSON:
# Rails 5.2/6.0
serialize :parameters, JSON
# Rails 6.1+
serialize :parameters, type: Hash, coder: JSON
If an implementation needs to continue using the serialized Hash, you will need to override the definition by reopening the model, and set it back to the old way!
# Rails 5.2/6.0
serialize :parameters, Hash
# Rails 6.1+ (untested, might not work!)
serialize :parameters, type: Hash, coder: Hash
In addition, one of the following is also needed.
-
Simple, but insecure fix, which reverts to previous unpatched behavior is:
Rails.application.config.active_record.use_yaml_unsafe_load = true ```
-
More complex, and a bit less insecure fix, is to explicitly list the allowed classes to serialize:
Rails.application.config.active_record.yaml_column_permitted_classes = [Symbol, Date, Time, HashWithIndifferentAccess] ```
You can run the tests with Rake:
DB_ADAPTER=sqlite3 bundle exec rake app:masq:test:ci
DB_ADAPTER=mysql2 bundle exec rake app:masq:test:ci
DB_ADAPTER=postgresql bundle exec rake app:masq:test:ci
The Rake task configures the database.yml for the chosen adapter.
In case you prefer running the tests continuously, use Guard:
bundle exec guard
See SECURITY.md.
If you need some ideas of where to help, you could work on adding more code coverage, or if it is already π― (see below) check TODOs (see below), or check issues, or PRs, or use the gem and think about how it could be better.
We so if you make changes, remember to update it.
See CONTRIBUTING.md for more detailed instructions.
Everyone interacting in this project's codebases, issue trackers,
chat rooms and mailing lists is expected to follow the .
Made with contributors-img.
Also see GitLab Contributors: https://gitlab.com/oauth-xx/masq2/-/graphs/main
This Library adheres to .
Violations of this scheme should be reported as bugs.
Specifically, if a minor or patch version is released that breaks backward compatibility,
a new version should be immediately released that restores compatibility.
Breaking changes to the public API will only be introduced with new major versions.
Yes. But I'm obligated to include notes...
SemVer should, but doesn't explicitly, say that dropping support for specific Platforms is a breaking change to an API. It is obvious to many, but not all, and since the spec is silent, the bike shedding is endless.
dropping support for a platform is both obviously and objectively a breaking change
- Jordan Harband (@ljharb) in SemVer issue 716
To get a better understanding of how SemVer is intended to work over a project's lifetime, read this article from the creator of SemVer:
As a result of this policy, and the interpretive lens used by the maintainer, you can (and should) specify a dependency on these libraries using the Pessimistic Version Constraint with two digits of precision.
For example:
spec.add_dependency("masq2", "~> 1.0")
See CHANGELOG.md for list of releases.
The gem is available as open source under the terms of
the MIT License .
See LICENSE.txt for the official Copyright Notice.
Copyright (c) 2024 - 2025 Peter H. Boling,
RailsBling.com
You made it to the bottom of the page, so perhaps you'll indulge me for another 20 seconds. I maintain many dozens of gems, including this one, because I want Ruby to be a great place for people to solve problems, big and small. Please consider supporting my efforts via the giant yellow link below, or one of the others at the head of this README.