Open nevans opened 2 years ago
FWIW, I've already implemented much of this in my forked IMAP client. But I haven't implemented the (configurable) backward-compatible error handling yet. Capabilities handling is the next thing on my list to merge & implement, because it's needed for several of the other extensions.
The API for Net::IMAP#ignore_server_capabilities=
in the description is just a proposal. Please let me know what you think. Hopefully I'll have code and proper documentation soon.
replaced ignore_server_capabilities
with enforce_capabilities
Using capabilities information
The client should track whenever it is knowingly violating capabilitied, either server reported or client enabled. At the very least, this should include checking capabilities before sending specific commands or command arguments.
Client-enabled capabilties
There will be no API to work around
client.enable(capability)
. Users who are determined to evade this limitation can figure out how cheat withclient.instance_variable_set(...)
.Server reported capabilities
The server capabilties cache will always be kept up-to-date when capabilities are checked. If the server hasn't sent its capabilities unsolicited, the client will request
capabilties
whenever capabilities are checked.If the capabilities check fails:
CapabilityError
will be raised without issuing any command to the server,CapabilityError
will be raised without issuing any command to the server,$stderr
but the command will still be sentIn some future version of
Net::IMAP
(perhaps the version released with ruby 3.2 or 3.3), the default for existing commands should change to match the behavior for new commands.Configuration
To opt-out of the new behavior or to opt-in to more strict behavior:
Net::IMAP#enforce_capabilities=
nil
-- Uses the current default behavior, which can change in future releases.true
-- Always raise an exception for any failed capabilities checks. Never knowingly sends unsupported commands or command arguments to the server.:warn
-- Prints a warning to$stderr
for non-security-related capabilities, regardless of the command or the currentNet::IMAP
default. Still raises for security-related capabilities checks.false
-- Restores old default behavior: client doesn't care about server capabilities. Still warns for security-related capabilities checks.def []: (CapabilityError, Net::IMAP) -> (nil | true | false | :warn)
, eg. aProc
. May change security-related capabilities handling.. The command, command args, required capabilities, etc will all be available on CapabilityError.Net::IMAP#initialize(*args, **kwargs, enforce_capabilities: cfg)
Net::IMAP.new(...).tap {|client| client.enforce_capabilities = cfg }
Net::IMAP#cmdname(..., enforce_capabilities: cfg)
#cmdname
represents any command which might check server capability.#starttls
,#authenticate
,#login
.opting out of security errors
enforce_capabilities: false
will still raise a warning for security related violations. These warnings can only be disabled with a proc.Allow fine-grained configuration with a Proc
The arguments will be a
CapabilityError
exception (which can be raised) and theNet::IMAP
client object (in case the proc is shared between multiple clients).CapabilityError
should have at least one sub-class,SecurityCapabilityError
, to representLOGINDISABLED
,AUTH=
,STARTTLS
capabilities, etc.CapabilityError
and its subclasses should allow pattern matching via#deconstruct
and/or#deconstruct_keys
This could be used to:
net-imap
yet