
Security News
Nx npm Packages Compromised in Supply Chain Attack Weaponizing AI CLI Tools
Malicious Nx npm versions stole secrets and wallet info using AI CLI tools; Socket’s AI scanner detected the supply chain attack and flagged the malware.
Modware is a library for using middleware (pipeline) patterns in Ruby projects. It features a simple interface and supports "callback" style semantics in the middleware stack, including before
, after
, and around
methods.
As usual:
gem 'modware' # in a Gemfile
spec.add_dependency 'modware' # in a .gemspec
Create a stack using:
stack = Modware::Stack.new(env: klass)
where klass
is a Class for the environment instance that will be passed to the layers of the stack. As a shorthand for the common case, you can simply pass an array of keys, e.g.
stack = Modware::Stack.new(env: [:name, :options, :results])
and Modware will define a class that accepts those keys as keyword arguments, and has accessor methods for each
Define middleware by creating a module that defines one or more of these middleware methods:
module MyMiddleware
# define any of these as needed...
def before(env)
# code to be called before the base implementation
end
def after(env)
# code to be called after the base implementation
end
def around(env)
# setup/wrapper code
yield env # continues execution down the stack
# cleanup code
end
def implement(env)
# completely replaces the base implementation or any earlier middleware's implement()
end
end
The module may use instance variables and define other methods as needed (e.g. to abide by Metz' rule #2).
To add the middleware to a stack:
stack.add(MyMiddleware)
Middleware is always added to the end of the stack.
To execute a stack do:
stack.start(*args) { |env|
# base implementation
}
The execution sequence of the stack is as follows:
env = env_klass.new(*args)
before(env)
method, in the order they were addedaround(env)
method, in the order they were added. This bottoms out with the last implement(env)
method to be added, if any, otherwise the base implementationafter(env)
method, in the order they were addedstack.start
returns env
A common idiom is to wrap a modware stack around an existing operation:
class WrapsOperation < BaseClass
attr_reader :stack
def initialize(*args)
super
@stack = Modware::Stack.new(env: [:time, :place, :result])
end
def operation(time, place)
stack.start(time: time, place: place) { |env|
env.result = super env.time, env.place
}.result
end
end
Notice in the operation
wrapper method:
env
instance gets initialized with the method argumentsoperation
gets its arguments from the env
instance, giving clients a chance to modify them in :before
or :around
methods.env
, giving clients a chance to modify it in :around
or :after
methods.env
, from which the wrapper returns the result.Modware.is_middleware?(mod)
returns truthy if mod
's instance methods include any of the middleware methods :before
, :after
, :around
, or :implement
The middleware gem works well, following a rack-like execution model.
Contributions welcome -- feel free to open issues or submit pull requests. Thanks!
FAQs
Unknown package
We found that modware demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Malicious Nx npm versions stole secrets and wallet info using AI CLI tools; Socket’s AI scanner detected the supply chain attack and flagged the malware.
Security News
CISA’s 2025 draft SBOM guidance adds new fields like hashes, licenses, and tool metadata to make software inventories more actionable.
Security News
A clarification on our recent research investigating 60 malicious Ruby gems.