DEV Community: Peter H. Boling

💎REL: oauth2 v2.0.18

Peter H. Boling — Wed, 01 Apr 2026 05:59:42 +0000

oauth2 v2.0.18 was released... almost five months ago. And I never got around to posting about it. Being unemployed is a LOT of work...

As a participant in Session 3 of GitHub Secure Open Source Fund I was able to learn about implementing:

an incident response plan
threat model analysis

These are critical tools to have in place so you have a guide when things go awry. ;) Those are the main changes in v2.0.18.

Another release is coming soon...

Ruby #GitHub #Security

Cover Photo (Cropped) by Dasha Yukhymyuk on Unsplash

🐠 ANN: appraisal2 v3.0.6 - support frozen appraisal lockfiles

Peter H. Boling — Wed, 18 Feb 2026 06:20:33 +0000

An issue was reported by Richard Kramer, and made me aware of a use case that I had never personally used, or even considered - which is committing the lockfiles for appraisals. I have always added gemfiles/*.gemfile.lock to my .gitignore.

In fact, when I had use cases where I wanted to run a CI workflow against a frozen lockfile I would avoid using appraisal2. But no more. We now have first class support for frozen lockfiles, and the implied active bundler version switching that can happen at runtime.

No breaking changes. No code changes needed for implementations. Just update, and go. Report back if anything breaks!

I need your support. Please sponsor me here on OpenCollective, or on:

Thanks,
@pboling

Hostile Takeover of RubyGems: My Thoughts

Peter H. Boling — Fri, 06 Feb 2026 01:00:32 +0000

I'll keep this post evergreen, as the situation evolves. Also, when you are done reading - hire me.

👣🔍️ First some background reading 🕵️

RubyGems (the GitHub org, not the website) suffered a hostile takeover in September 2025.
Ultimately 4 maintainers were hard removed and a (dubious) reason has been given for only 1 of those, while 2 others resigned in protest.
It is a complicated story which is difficult to parse quickly.
Simply put - there was active policy for adding or removing maintainers/owners of rubygems and bundler, and those policies were not followed.
I'm adding a note linking to this post to all of my gems because I don't condone theft of repositories or gems from their rightful owners.
If a similar theft happened with my repos/gems, I'd hope some would stand up for me.
Disenfranchised former-maintainers have started gem.coop.
Once available I will publish there, or to my own server, exclusively; unless RubyCentral & Ruby Core make amends with the community.
The "Technology for Humans: Joel Draper" podcast episode by reinteractive is the most cogent summary I'm aware of.
See here, here and here for more info on what comes next.

My thoughts

I no longer trust Ruby Central.
I no longer trust certain members, but primarily HSBT, of the RubyGems core team.
I no longer trust certain members, but primarily HSBT and Matz, of the Ruby core team.

Q: In what sense do I not trust them?
A: 📃 Governance 📃

To be more specific, I no longer trust that they:

Hold people accountable for their actions according to written agreements and documentation around governance policy.
Understand the community upset over point 1.
Will ever do anything about it.

If they are added to your repository, you may wake up to find you have lost access to your own project.

I'm not OK with this having already happened to others, and have taken steps to ensure it will not happen to me.

Within my open source projects, I will reduce, to the degree possible, my reliance, on any project hosted under the Ruby org on GitHub. Since most of my projects are Ruby projects, I'll never get to complete exclusion, but I will be focusing much more on JRuby and Truffleruby.

It has been pointed out to me in other discussions about this that we never had reason to trust them, but we did anyway, implicitly. We normally assume other people live by the same code of ethics that we ourselves live by. I will miss being able to rest on that assumption, but it is probably for the best that it get binned.

What I'm doing about it

appraisal2 is a hard fork of the old, and nearly-dead, namesake Thoughtbot project, to which I've added many features, including support for:
- Bundler's eval_gemfile
- frozen appraisal lockfiles w/ bundler version switching
- all versions of Ruby back to v1.8
- ore (see below)
- More on the reasons behind the hard fork
ore installs gems without Ruby, without bundler, and without rubygems. It is a GoLang implementation of (some parts of) Bundler (and adds some features bundler lacks). A project by @seuros - and I'm now on the core team. It is much faster than bundler.
setup-ruby-flash is an alternative to the venerable setup-ruby GHA we've all been using for years. setup-ruby-flash relies on rv and ore for Ruby and Gem installs, and it falls back to setup-ruby on unsupported platforms/engines. I wrote more about it here.
A (WIP) proposal for bundler/gem scopes
A (WIP) proposal for a federated gem server

⚡️ setup-ruby-flash

Peter H. Boling — Mon, 19 Jan 2026 03:03:27 +0000

Find out how fast my workflows can go!
-You, possibly

GH Marketplace	Dogfood	Current Tag	License	Source	Stars

A fast GitHub Action for fast Ruby environment setup using rv for Ruby installation and ore for gem management.

⚡ Install Ruby in under 2 seconds — no compilation required!

⚡ Install Gems 50% faster — using ORE ✅️!

Features

🚀 Lightning-fast Ruby installation via prebuilt binaries from rv
📦 Rapid gem installation with ore (Bundler-compatible, ~50% faster)
💾 Intelligent caching for both Ruby and gems
🔒 Security auditing via ore audit
🐧 Linux & macOS support (x86_64 and ARM64)
☕️ Gitea Actions support
🦊 Forgejo Actions support
🧊 Codeberg Actions support
🐙 GitHub Actions support

Requirements

Operating Systems: Ubuntu 22.04+, macOS 14+
Architectures: x86_64, ARM64
Ruby Versions: 3.2, 3.3, 3.4, 4.0

#	Important	Alternative
1	Windows is not supported	ruby/setup-ruby
2	Ruby <= 3.1 is not supported	ruby/setup-ruby

Key Differences with setup-ruby

Feature	setup-ruby	setup-ruby-flash
Ruby Install	~5 seconds	< 2 seconds
Gem Install	Bundler	ore (~50% faster)
`ruby-version: ruby`	✅ latest stable	✅ latest stable
`rubygems: latest`	✅	✅
`bundler: latest`	✅	✅
Windows	✅	❌
Ruby < 3.2	✅	❌
JRuby	✅	❌ (planned)
TruffleRuby	✅	❌ (planned)
Security Audit	❌	✅ (`ore audit`)

Basic Usage

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: '3.4'

With Gem Installation

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: '3.4'
    ore-install: true

Using Version Files

When ruby-version is set to default (the default), setup-ruby-flash reads from:

.ruby-version
.tool-versions (asdf format)
mise.toml

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ore-install: true

Enough Talk, Where?

Inputs

Input	Description	Default
`ruby-version`	Ruby version to install (e.g., `3.4`, `3.4.1`). Use `ruby` for latest stable version, or `default` to read from version files.	`default`
`rubygems`	RubyGems version: `default`, `latest`, or a version number (e.g., `3.5.0`)	`default`
`bundler`	Bundler version: `Gemfile.lock`, `default`, `latest`, `none`, or a version number	`Gemfile.lock`
`ore-install`	Run `ore install` and cache gems	`false`
`working-directory`	Directory for version files and Gemfile	`.`
`cache-version`	Cache version string for invalidation	`v1`
`rv-version`	Version of rv to install (ignored if `rv-git-ref` is set)	`latest`
`rv-git-ref`	Git branch, tag, or commit SHA to build rv from source	`''`
`ore-version`	Version of ore to install (ignored if `ore-git-ref` is set)	`latest`
`ore-git-ref`	Git branch, tag, or commit SHA to build ore from source	`''`
`skip-extensions`	Skip building native extensions	`false`
`without-groups`	Gem groups to exclude (comma-separated)	`''`
`ruby-install-retries`	Number of retry attempts for Ruby installation (with exponential backoff)	`3`
`no-document`	Skip generating documentation (ri/rdoc) for installed gems. Creates `~/.gemrc` with `gem: --no-document` if file doesn't exist	`true`
`token`	GitHub token for API calls	`${{ github.token }}`

Outputs

Output	Description
`ruby-version`	The installed Ruby version
`ruby-prefix`	The path to the Ruby installation
`rv-version`	The installed rv version
`rubygems-version`	The installed RubyGems version
`bundler-version`	The installed Bundler version
`ore-version`	The installed ore version
`cache-hit`	Whether gems were restored from cache

Examples

Matrix Build

name: CI
on: [push, pull_request]

jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest]
        ruby: ["3.2", "3.3", "3.4", "4.0"]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v5
      - uses: appraisal-rb/setup-ruby-flash@v1
        with:
          ruby-version: ${{ matrix.ruby }}
          ore-install: true
      - run: bundle exec rake test

Production Gems Only

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: '3.4'
    ore-install: true
    without-groups: 'development,test'

Latest Ruby with Latest RubyGems and Bundler

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: ruby
    rubygems: latest
    bundler: latest
    ore-install: true

Specific RubyGems Version

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: '3.4'
    rubygems: '3.5.0'
    ore-install: true

Skip Native Extensions

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: '3.4'
    ore-install: true
    skip-extensions: true

Custom Working Directory

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: '3.4'
    ore-install: true
    working-directory: './my-app'

Specific Tool Versions

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: '3.4.1'
    rv-version: '0.4.0'
    ore-version: '0.1.0'
    ore-install: true

Custom Retry Configuration

If you experience intermittent failures due to GitHub API rate limiting, you can adjust the number of retry attempts:

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: '3.4'
    ruby-install-retries: '5'

Enable Documentation Generation

Include documentation (ri/rdoc) for installed gems (default skips documentation for faster installation):

- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: "3.4"
    ore-install: true
    no-document: false

Building rv or ore from Source

You can build rv or ore from a git branch, tag, or commit SHA instead of using a released version.
This is useful for testing unreleased features or bug fixes. Required toolchains (Rust for rv, Go for ore)
are automatically installed. Fork syntax (pboling:feat/myexperiment) is supported to test out feature branches in forks of ore or rv.

# Test an ore feature branch
- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: "3.4"
    ore-install: true
    ore-git-ref: "feat/bundle-gemfile-support"

# Test a pre-release rv tag
- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: "3.4"
    rv-git-ref: "v0.5.0-beta1"

# Test both from main branches
- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: "3.4"
    rv-git-ref: "main"
    ore-install: true
    ore-git-ref: "main"

Migration from setup-ruby

setup-ruby-flash is designed to be a near drop-in replacement for ruby/setup-ruby on supported platforms:

# Before (setup-ruby)
- uses: ruby/setup-ruby@v1
  with:
    ruby-version: '3.4'
    bundler-cache: true
- run: bundle exec rake test

# After (setup-ruby-flash)
- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: '3.4'
    ore-install: true
- run: bundle exec rake test

With Latest RubyGems and Bundler

# Before (setup-ruby)
- uses: ruby/setup-ruby@v1
  with:
    ruby-version: ruby
    rubygems: latest
    bundler: latest

# After (setup-ruby-flash)
- uses: appraisal-rb/setup-ruby-flash@v1
  with:
    ruby-version: ruby
    rubygems: latest
    bundler: latest

Acknowledgements

setup-ruby the venerable mainstay for many years, and inspiration for this project.
rv by Spinel Cooperative
ore by Contriboss

Support & Funding Info

I am a full-time FLOSS maintainer. If you find my work valuable I ask that you become a sponsor. Every dollar helps!

🥰 Support FLOSS work 🥰	Get access	"Sponsors" channel	on Galtzo FLOSS	Discord 👇️

About rv and ore

rv

rv is an extremely fast Ruby version manager written in Rust. It downloads prebuilt Ruby binaries, eliminating the need for compilation. Created by @indirect, long-time project lead for Bundler and RubyGems.

ore

ore is a fast gem installer written in Go. It's Bundler-compatible but performs downloads significantly faster using Go's concurrency features. Use bundle exec to run gem commands after ore installs your gems. Created by @seuros, a long time Rubyist, and prolific writer.

Cover photo (cropped) by Kyle Hinkson on Unsplash

💲FLOSS Funding

Peter H. Boling — Thu, 06 Nov 2025 23:39:10 +0000

Two things are true.

Many open source contributors have been laid off recently, and have not been able to find new roles. Many of these have become the fabled "person in Nebraska", made famous by XKCD #2347.
Every RubyGem, NPM, pip, cargo, etc, package you have ever used is worth at least $1 to you and the careers and products they helped build. Many people would contribute more financially to open source if more systems were in place to facilitate that.

All modern digital infrastructure (depending on) a project some random person in Nebraska has been thanklessly maintaining since 2003 - xkcd.com/2347

You may be saying:

Systems do exist to enable donations or subscriptions to developers. In fact, I can name several!

Yes, fine, three things are true. Those systems are excellent, and underutilized. Why?

Finding the funding path for a project is hard. Unless you are the meticulous type to memorize a Gemfile.lock, yarn.lock, or package-lock.json, many, if not most, of the projects at the bottom of the tree get overlooked. Since they know they will be overlooked, they often don't even bother setting up paths for donations.

What kinds of dependencies?

The nested, indirect, dependencies loaded by your direct dependencies.
The development and test dependencies which you rely on for AI to validate its work when you are vibe coding
The ones that take just as much effort to build, but fail to get recognized as valuable.

Aren't there tools that automatically dig into the dependency tree to help fund those indirect dependencies?

Yes, those are great, and I encourage people to use them. So apparently four things are true, but:

None dig down more than 3 levels into a dependency tree, and trees can be much deeper than that. In Ruby, for example:

bundle fund doesn't consider indirect dependencies
- In some contexts they only consider runtime dependencies
bundle fund doesn't consider development dependencies in Gemfile during RubyGem development

I love bundle fund, but if the command isn't run, people don't see the requests for help with funding, and it is never run automatically. I expect there are similar issues with npm fund.

Currently, funding for the majority of free (libre) open source code (FLOSS) is hard.

What if it was easy?

What if a project could tell you how to support it precisely when you are using it, and deriving value from it?

New #Ruby gem to fund open source developers whose projects get missed by other #FLOSS #funding tools which don’t cover dev deps, nor indirect deps > 3 levels down.

https://ruby.social/@galtzo/114994584740434327

👉 no tracking
👉 no network calls
👉 never forces or requires payment
👉 supports buy-once, or per-version
👉 easily silenced nags
👉 sets of related libraries share activation keys
👉 nags are opt-in for maintainers, opt-out for users
👉 nags are throttled to customizable frequency
👉 inert in non-TTY shells (i.e. production-like environments)
👉 inert when exit status is non-zero
👉 inert for many edge cases, such as an internal failure
👉 inert when a global silencing ENV variable is set (you're welcome, haters!)

Open source projects in which languages will have this ability?
Ruby
Javascript
Elixir
Python
Perl
... Join the discord if you have more ideas, and want to contribute. A lanugage just needs to have an "atexit()" style hook, i.e. a process termination hook. A bunch of languages meet the criteria, even Bash.

Cover photo by me, CC-SA 4.0.

💎 ANN: omniauth-identity v3.1.5 (Hanami/ROM Support)

Peter H. Boling — Tue, 14 Oct 2025 00:49:55 +0000

3.1.5 - 2025-10-13

TAG: v3.1.5
COVERAGE: 93.58% -- 437/467 lines in 14 files
BRANCH COVERAGE: 81.00% -- 81/100 branches in 14 files
92.39% documented

Added

Adapter support for Hanami and ROM
Complete YARD documentation
kettle-dev for easier maintenance & dev tooling

The one where omniauth-identity gains a rom adapter. Since rom is the default DB adapter for Hanami, this also makes it hanami-ready.

class Identity
  include OmniAuth::Identity::Models::Rom

  # Configure the ROM container and relation using the DSL (no `self.`):
  rom_container -> { MyDatabase.rom } # accepts a proc or a container object
  rom_relation_name :identities # optional, defaults to :identities
  owner_relation_name :owners  # optional, for loading associated owner
  # Uses OmniAuth::Identity::Model.auth_key to set the auth key (defaults to :email)
  auth_key :email
  # Optional: override the password digest field name (defaults to :password_digest)
  password_field :password_digest
end

Find a complete example after the funding info.

Support & Funding Info

I am a full-time FLOSS maintainer. If you find my work valuable I ask that you become a sponsor. Every dollar helps!

🥰 Support FLOSS work 🥰	Get access to "Sponsors" channel	on Galtzo FLOSS	Discord 👇️

As an example I'll use the code straight from the specs.

Test Harness

ROM_DB = if RUBY_ENGINE == "jruby"
  require "jdbc/sqlite3"
  require "sequel"
  Sequel.connect("jdbc:sqlite::memory:rom")
else
  require "sqlite3"
  require "sequel"
  Sequel.connect("sqlite::memory:rom")
end

require "rom"
require "rom-sql"

# Define the ROM relations
class RomTestIdentities < ROM::Relation[:sql]
  schema(:rom_test_identities) do
    attribute :id, ROM::SQL::Types::Serial
    attribute :email, ROM::SQL::Types::String
    attribute :login, ROM::SQL::Types::String
    attribute :password_digest, ROM::SQL::Types::String
    attribute :pwd_hash, ROM::SQL::Types::String
    attribute :owner_id, ROM::SQL::Types::Integer
  end
end

class RomTestOwners < ROM::Relation[:sql]
  schema(:rom_test_owners) do
    attribute :id, ROM::SQL::Types::Serial
    attribute :name, ROM::SQL::Types::String
  end
end

# Set up ROM container
ROM_CONFIG = ROM::Configuration.new(:sql, ROM_DB)
ROM_CONFIG.register_relation(RomTestIdentities)
ROM_CONFIG.register_relation(RomTestOwners)
ROM_CONTAINER = ROM.container(ROM_CONFIG)

class RomTestIdentity
  include OmniAuth::Identity::Models::Rom

  # Configure via the new DSL (no `self.`): accepts a value or a proc
  rom_container -> { ROM_CONTAINER }
  rom_relation_name :rom_test_identities
  # Use the standard Model.auth_key API to configure the auth key
  auth_key :email
  password_field :password_digest

  # Provide a simple reader for the :login attribute for specs that use a
  # non-standard auth key (e.g. `auth_key :login`). The ROM adapter stores the
  # underlying tuple in @identity_data, so delegate to it here.
  def login
    @identity_data && @identity_data[:login]
  end
end

Test

RSpec.describe(OmniAuth::Identity::Models::Rom, :sqlite3) do
  before(:all) do
    # Create the tables
    ROM_DB.create_table(:rom_test_identities) do
      primary_key :id
      String :email, null: false
      String :password_digest, null: false
      # Add the login column to support tests that use a non-standard auth_key
      String :login
      Integer :owner_id
    end

    ROM_DB.create_table(:rom_test_owners) do
      primary_key :id
      String :name, null: false
    end
  end

  before do
    # Clear the tables before each test
    ROM_DB[:rom_test_identities].delete
    ROM_DB[:rom_test_owners].delete
  end

  describe "model", type: :model do
    subject(:model_klass) { RomTestIdentity }

    describe "::authenticate" do
      it "authenticates with correct password" do
        # Insert test data
        password_digest = BCrypt::Password.create("password")
        identity_data = {email: "test@example.com", password_digest: password_digest}
        ROM_CONTAINER.relations[:rom_test_identities].insert(identity_data)

        authenticated = model_klass.authenticate({email: "test@example.com"}, "password")
        expect(authenticated).to(be_a(RomTestIdentity))
        expect(authenticated.email).to(eq("test@example.com"))
      end

      it "authenticates with custom auth_key (login) when auth_key is set to :login" do
        original = model_klass.auth_key
        model_klass.auth_key(:login)

        begin
          # Insert test data using login field
          password_digest = BCrypt::Password.create("password")
          identity_data = {login: "bob", email: "bob@example.com", password_digest: password_digest}
          ROM_CONTAINER.relations[:rom_test_identities].insert(identity_data)

          authenticated = model_klass.authenticate({login: "bob"}, "password")
          expect(authenticated).to(be_a(RomTestIdentity))
          expect(authenticated.login).to(eq("bob"))
        ensure
          model_klass.auth_key(original)
        end
      end

      it "returns false with incorrect password" do
        # Insert test data
        password_digest = BCrypt::Password.create("password")
        identity_data = {email: "test@example.com", password_digest: password_digest}
        ROM_CONTAINER.relations[:rom_test_identities].insert(identity_data)

        authenticated = model_klass.authenticate({email: "test@example.com"}, "wrong")
        expect(authenticated).to(be(false))
      end

      it "returns false for non-existent user" do
        authenticated = model_klass.authenticate({email: "nonexistent@example.com"}, "password")
        expect(authenticated).to(be(false))
      end
    end
  end
end

Photo by Ryunosuke Kikuno on Unsplash

💎 ANN: oauth2 v2.0.17

Peter H. Boling — Thu, 18 Sep 2025 06:30:38 +0000

Announcing oauth2 v2.0.17 — Static Hash for verb‑dependent token mode (Instagram‑friendly)

The oauth2 v2.0.17 is a small but useful release: it adds support for configuring verb‑dependent token transmission with a static Hash in addition to the previously available Proc. This makes integrations like Instagram’s Graph API a little simpler and slightly more performant.

TL;DR

v2.0.15 introduced verb‑dependent token mode, so you could decide per HTTP verb whether the access token should be sent in the query string or the Authorization header.
v2.0.17 lets you provide that mapping as a static Hash instead of a Proc.
Example mapping: {get: :query, post: :header, delete: :header}.

Why this matters

Some APIs (notably Instagram’s Graph API) require you to send the access token in the query for GET requests (e.g., ?access_token=...), but in the Authorization header for POST/DELETE (e.g., Authorization: Bearer ...).

In v2.0.15 we added support for a verb‑dependent mode via a Proc, like:

{mode: ->(verb) { verb == :get ? :query : :header }}

In v2.0.17 you can now configure the same behavior using a static Hash, which avoids calling a Proc for each request, keeps intent obvious at a glance, and can be trivially serialized or reused:

verb_dependent_token = {get: :query, post: :header, delete: :header}

Example: Instagram Graph API with a static Hash

Below is a concrete example that exchanges a short‑lived token for a long‑lived token, refreshes it, and then makes API calls — all while automatically placing the token in the right place per HTTP verb using the static Hash mode.

require "oauth2"

client = OAuth2::Client.new(nil, nil, site: "https://graph.instagram.com")

# Start with a short‑lived token you already obtained via Facebook Login
verb_dependent_token = {get: :query, post: :header, delete: :header}

short_lived = OAuth2::AccessToken.new(
  client,
  ENV["IG_SHORT_LIVED_TOKEN"],
  mode: verb_dependent_token,
)

# 1) Exchange for a long‑lived token (GET with token in query)
#    Endpoint: GET https://graph.instagram.com/access_token
#    Params: grant_type=ig_exchange_token, client_secret=APP_SECRET
exchange = short_lived.get(
  "/access_token",
  params: {
    grant_type: "ig_exchange_token",
    client_secret: ENV["IG_APP_SECRET"],
    # access_token will be added automatically in the query
  },
)
long_lived_token_value = exchange.parsed["access_token"]

long_lived = OAuth2::AccessToken.new(
  client,
  long_lived_token_value,
  mode: verb_dependent_token,
)

# 2) Refresh the long‑lived token (GET with token in query)
#    Endpoint: GET https://graph.instagram.com/refresh_access_token
refresh_resp = long_lived.get(
  "/refresh_access_token",
  params: {grant_type: "ig_refresh_token"},
)
long_lived = OAuth2::AccessToken.new(
  client,
  refresh_resp.parsed["access_token"],
  mode: verb_dependent_token,
)

# 3) Typical API GET request (token automatically in query)
me = long_lived.get("/me", params: {fields: "id,username"}).parsed

# 4) Example POST (token automatically in Authorization header)
# long_lived.post("/me/media", body: {image_url: "https://...", caption: "hello"})

Notes

Instagram is a special case that explicitly requires query‑string tokens for GET endpoints. For most providers you should prefer header‑based tokens when possible.
If you need custom logic beyond a simple mapping, you can still use a Proc: mode: ->(verb) { ... }.

Migrating from Proc to Hash

If you already use the v2.0.15 Proc style:

{mode: ->(verb) { verb == :get ? :query : :header }}

You can switch to the Hash form in v2.0.17:

{mode: {get: :query, post: :header, delete: :header}}

Both are supported; choose whichever best fits your app. The Hash form is generally a bit faster and more explicit, while the Proc form is endlessly versatile!

Release links

Changelog entry: https://github.com/ruby-oauth/oauth2/blob/main/CHANGELOG.md#2017---2025-09-15
Tag: https://github.com/ruby-oauth/oauth2/releases/tag/v2.0.17
PR: Add Hash‑based verb‑dependent mode https://github.com/ruby-oauth/oauth2/pull/682

Thanks

Thanks to everyone using oauth2 and filing issues. Keep the feedback coming!

Support & Funding Info

I am a full-time FLOSS maintainer. If you find my work valuable I ask that you become a sponsor. Every dollar helps!

🥰 Support FLOSS work 🥰	Get access	"Sponsors" channel	on Galtzo FLOSS	Discord 👇️

Photo (cropped) by Wonder KIM on Unsplash

💎 ANN: kettle-dev v1.1.20 w/ improved CHANGELOG handling

Peter H. Boling — Mon, 15 Sep 2025 11:53:14 +0000

1.1.20 - 2025-09-15

TAG: v1.1.20
COVERAGE: 96.80% -- 3660/3781 lines in 25 files
BRANCH COVERAGE: 81.65% -- 1504/1842 branches in 25 files
77.01% documented

Added

Allow reformating of CHANGELOG.md without version bump
--include=GLOB includes files not otherwise included in default template
more test coverage

Fixed

Add .licenserc.yaml to gem package
Handling of GFM fenced code blocks in CHANGELOG.md
Handling of nested list items in CHANGELOG.md
Handling of blank lines around all headings in CHANGELOG.md

Support & Funding Info

I am a full-time FLOSS maintainer. If you find my work valuable I ask that you become a sponsor. Every dollar helps!

🥰 Support FLOSS work 🥰	Get access	"Sponsors" channel	on Galtzo FLOSS	Discord 👇️

💎 ANN: oauth2 v2.0.16 w/ full E2E example (& Instagram Compat)

Peter H. Boling — Sun, 14 Sep 2025 23:07:29 +0000

Actually Instagram compatibility came in oauth2 v2.0.15, but I didn't make a separate post about it. So here's what you need to know:

verb-dependent token transmission mode for AccessToken makes it Instagram compatible.
Complete example included!

OK, now on with v2.0.16!

Complete E2E single file script

runs against navikt/mock-oauth2-server
E2E script in source

NOTE: The mock test server was added to source in oauth v2.0.11, and has now been upgraded to the latest version of mock-oauth2-server. The mock test server is not in the packaged gem.

docker compose -f docker-compose-ssl.yml up -d --wait
ruby examples/e2e.rb
# If your machine is slow or Docker pulls are cold, increase the wait:
E2E_WAIT_TIMEOUT=120 ruby examples/e2e.rb
# The mock server serves HTTP on 8080; the example points to http://localhost:8080 by default.

The output should be something like this:

➜  ruby examples/e2e.rb
Access token (truncated): eyJraWQiOiJkZWZhdWx0...
userinfo status: 200
userinfo body: {"sub" => "demo-sub", "aud" => ["demo-aud"], "nbf" => 1757816758000, "iss" => "http://localhost:8080/default", "exp" => 1757820358000, "iat" => 1757816758000, "jti" => "d63b97a7-ebe5-4dea-93e6-d542caba6104"}
E2E complete

Make sure to shut down the mock server when you are done:

docker compose -f docker-compose-ssl.yml down

Troubleshooting: validate connectivity to the mock server

Check container status and port mapping:
- docker compose -f docker-compose-ssl.yml ps
From the host, try the discovery URL directly (this is what the example uses by default):
- curl -v http://localhost:8080/default/.well-known/openid-configuration
- If that fails immediately, also try: curl -v --connect-timeout 2 http://127.0.0.1:8080/default/.well-known/openid-configuration
From inside the container (to distinguish container vs host networking):
- docker exec -it oauth2-mock-oauth2-server-1 curl -v http://127.0.0.1:8080/default/.well-known/openid-configuration
Simple TCP probe from the host:
- nc -vz localhost 8080 # or: ruby -rsocket -e 'TCPSocket.new("localhost",8080).close; puts "tcp ok"'
Inspect which host port 8080 is bound to (should be 8080):
- docker inspect -f '{{ (index (index .NetworkSettings.Ports "8080/tcp") 0).HostPort }}' oauth2-mock-oauth2-server-1
Look at server logs for readiness/errors:
- docker logs -n 200 oauth2-mock-oauth2-server-1
On Linux, ensure nothing else is bound to 8080 and that firewall/SELinux aren’t blocking:
- ss -ltnp | grep :8080

Notes

Discovery URL pattern is: http://localhost:8080//.well-known/openid-configuration, where defaults to "default".
You can change these with env vars when running the example:
- E2E_ISSUER_BASE (default: http://localhost:8080)
- E2E_REALM (default: default)

See the full changelogs after a word from (or is it for?) my sponsor (you!).

Support & Funding Info

I am a full-time FLOSS maintainer. If you find my work valuable I ask that you become a sponsor. Every dollar helps!

🥰 Support FLOSS work 🥰	Get access	"Sponsors" channel	on Galtzo FLOSS	Discord 👇️

2.0.16 - 2025-09-14

TAG: v2.0.16
COVERAGE: 100.00% -- 520/520 lines in 14 files
BRANCH COVERAGE: 100.00% -- 176/176 branches in 14 files
90.48% documented

Added

gh!680 - E2E example using mock test server added in v2.0.11 by @pboling
- mock-oauth2-server upgraded to v2.3.0
- https://github.com/navikt/mock-oauth2-server
- docker compose -f docker-compose-ssl.yml up -d --wait
- ruby examples/e2e.rb
- docker compose -f docker-compose-ssl.yml down
- mock server readiness wait is 90s
- override via E2E_WAIT_TIMEOUT
gh!676, gh!679 - Apache SkyWalking Eyes dependency license check by @pboling

Changed

gh!678 - Many improvements to make CI more resilient (past/future proof) by @pboling
gh!681 - Upgrade to kettle-dev v1.1.19

2.0.15 - 2025-09-08

TAG: v2.0.15
COVERAGE: 100.00% -- 519/519 lines in 14 files
BRANCH COVERAGE: 100.00% -- 174/174 branches in 14 files
90.48% documented

Added

gh!671 - Complete documentation example for Instagram by @pboling
.env.local.example for contributor happiness
note lack of builds for JRuby 9.2, 9.3 & Truffleruby 22.3, 23.0
- actions/runner - issues/2347
- community/discussions/15452
gh!670 - AccessToken: verb-dependent token transmission mode by @mrj
- e.g., Instagram GET=:query, POST/DELETE=:header

Changed

gh!669 - Upgrade to kettle-dev v1.1.9 by @pboling

Fixed

Remove accidentally duplicated lines, and fix typos in CHANGELOG.md
point badge to the correct workflow for Ruby 2.3 (caboose.yml)

Photo (cropped) by Zoha Gohar on Unsplash

👩‍🔧 How to Check License Compatibility in GHA

Peter H. Boling — Sat, 13 Sep 2025 22:27:37 +0000

Other posts in my Compatibility Matrix Series

You have a project made out of code, sprinkles, and spice, and you want to validate compatibility between your project's license and the licenses of its dependencies, as defined by:

Apache Software Foundation (ASF) Categorizations via apache.org
Free Software Foundation's (FSF) Free/Libre designations via spdx.org
Open Source Initiative (OSI) Approved designations via spdx.org
Any of the above

What is Compatible?

Apache Software Foundation

IANAL, but Apache Software Foundation has resolved many legal issues between licenses and determined their compatibility to my satisfaction. Take it up with them if your fractious children want to quarrel about it.

Category A licenses are compatible with each other and with Apache Software Foundation projects generally.
Category B licenses are compatible with each other, and with Apache Software Foundation projects when included as binary code.
Other licenses need manual validation, and compatibility can be configured and documented per project.

These categorizations are the backbone of the Apache SkyWalking Eyes license checker, see further down for a configuration example.

FSF Free/Libre

Supported. In your licenserc.yaml:

dependency:
  require_fsf_free: true # will only consider compatible if license is FSF Free/Libre; default false

OSI Approved

Supported. In your licenserc.yaml:

dependency:
  require_osi_approved: true # will only consider compatible if license is OSI Approved; default false

How can we check compatibility?

I've now pushed many PRs to a project called Apache SkyWalking Eyes (#205, #207, #208, #209, ... #247, #248, #249, #250). And now it is ready to write about.

It works for a basic use case of a project with MIT and Ruby licensed dependencies, such as oauth2:
https://github.com/ruby-oauth/oauth2/pull/676

It also works for more complex use cases with many dependencies across a broad set of open source licenses.

Project Setup

This example will use a Ruby project as an example, but there is support for Create two files:

# .licenserc.yaml

header:
  license:
    spdx-id: MIT # The license of your project!

dependency:
  require_fsf_free: false # if "FSF Free/Libre" is required, set to true
  require_osi_approved: false # if "OSI Approved" is required, set to true
  files:
    - Gemfile.lock      # If this is a Ruby project (Bundler). Ensure Gemfile.lock is committed.
    # - pom.xml           # If this is a maven project.
    # - Cargo.toml        # If this is a rust project.
    # - package.json      # If this is a npm project.
    # - go.mod            # If this is a Go project.

and

# .github/workflows/license-eye.yml

name: Apache SkyWalking Eyes

permissions:
  contents: read

on:
  push:
    branches:
      - 'main'
      - '*-stable'
    tags:
      - '!*' # Do not execute on tags
  pull_request:
    branches:
      - '*'
  # Allow manually triggering the workflow.
  workflow_dispatch:

# Cancels all previous workflow runs for the same branch that have not yet completed.
concurrency:
  # The concurrency group contains the workflow name and the branch name.
  group: "${{ github.workflow }}-${{ github.ref }}"
  cancel-in-progress: true

jobs:
  license-check:
    if: "!contains(github.event.commits[0].message, '[ci skip]') && !contains(github.event.commits[0].message, '[skip ci]')"
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v5

      - name: Check Dependencies' License
        uses: apache/skywalking-eyes/dependency@main
        with:
          config: .licenserc.yaml
          # Ruby packages declared as dependencies in gemspecs or Gemfiles are
          #   typically consumed as binaries; enable weak-compatibility
          #   so permissive and weak-copyleft combinations are treated as compatible.
          flags: --weak-compatible

Result

End result workflow runs look like:
https://github.com/ruby-oauth/oauth2/actions/workflows/license-eye.yml

Experiment: if we mark the Ruby license (which is category B) as incompatible in our MIT (category A) projects, this is what would happen:

Cool, right? I'm not suggesting you do that, since in Ruby dependencies are normally included as binaries, so Category B is generally compatible with Category A licenses in Ruby projects...

Projects that declare no license are problematic and will fail in this same way, alerting you to the problem.

You'll also get notified if downstream dependencies change their licenses to something incompatible.

Spread Awareness

Because licenses matter...

Now is a good time to make your community of users aware of your shiny license compliance via README.md badges...

[![Apache SkyWalking Eyes License Compatibility Check][🚎15-🪪-wfi]][🚎15-🪪-wf]
[![Compatible with Apache Software Projects: Verified by SkyWalking Eyes][📄license-compat-img]][📄license-compat]

[🚎15-🪪-wf]: https://github.com/ruby-oauth/oauth2/actions/workflows/license-eye.yml
[🚎15-🪪-wfi]: https://github.com/ruby-oauth/oauth2/actions/workflows/license-eye.yml/badge.svg
[📄license-compat]: https://www.apache.org/legal/resolved.html#category-a
[📄license-compat-img]: https://img.shields.io/badge/Apache_Compatible:_Category_A-✓-259D6C.svg?style=flat&logo=Apache
[📄license-compat-img-raster]: https://raster.shields.io/badge/Apache_Compatible:_Category_A-✓-259D6C.png?style=flat&logo=Apache
# note: dev.to will only render the PNG rasterized version;
#       in READMEs you should use the SVG for better image clarity.

Support & Funding Info

I am a full-time FLOSS maintainer. If you find my work valuable, I ask that you become a sponsor. Every dollar helps!

🥰 Support FLOSS work 🥰	Get access	"Sponsors" channel	on Galtzo FLOSS	Discord 👇️

Photo (cropped) by Zoha Gohar on Unsplash

💲ANN: awesome-sponsorships

Peter H. Boling — Fri, 12 Sep 2025 08:18:46 +0000

🪧 How do you get more open source sponsors? Now that I'm doing FLOSS full-time, I have to either starve or improve my marketing game.

I've talked with people who do it well (they shall remain nameless, so you'll have to trust me on that), and distilled the ideas into 2 actionable checklists - a short one and a long one. Now I just need to implement. I'd love to hear your thoughts, and get your ⭐ of approval.

github.com/floss-funding/awesome-sponsorships

#FLOSS #Funding #FiscalSponsor

Support & Funding Info

I am a full-time FLOSS maintainer. If you find my work valuable I ask that you become a sponsor. Every dollar helps!

🥰 Support FLOSS work 🥰	Get access	"Sponsors" channel	on Galtzo FLOSS	Discord 👇️

Photo (cropped) by Cajeo Zhang on Unsplash

💎 ANN: oauth2 v2.0.14

Peter H. Boling — Mon, 01 Sep 2025 03:24:45 +0000

oauth2 v2.0.14 has been released with:

📝 Added OAuth 2.1 draft specification as inline documentation throughout in PR #662
- PKCE required for auth code,
- exact redirect URI match,
- implicit/password grants omitted,
- avoid bearer tokens in query,
- refresh token guidance for public clients,
- simplified client definitions
📝 Added OIDC documentation, example, and spec references in OIDC.md in PR #663
📝 Add Example for JHipster UAA Server (Spring Cloud) Password Grant Integration in PR #664
📝 Document Mutual TLS (mTLS) usage with example in README in PR #665
✅ Documentation with Example for Flat Params Usage, with specs in PR #666
Purely a documentation release!

Yes, this is the second release in two days. There are no code changes in this release.

This project is used by over 100k other projects. It is downloaded millions of times per week. It currently has zero backers, and zero sponsors. Please consider supporting it.

Release Notes: github.com/ruby-oauth/oauth2/releases/tag/v2.0.14

Open Collective: opencollective.com/ruby-oauth

Support & Funding Info

I am a full-time FLOSS maintainer. If you find my work valuable I ask that you become a sponsor. Every dollar helps!

🥰 Support FLOSS work 🥰	Get access	"Sponsors" channel	on Galtzo FLOSS	Discord 👇️

Photo by Pawel Czerwinski on Unsplash