Consider intermediate getter/putter level
vanrein opened this issue · 4 comments
Between lillyget_ldapmessage() and lillyget_operation() there is a use for a level that only unpacks the opcode, but not the arguments given. This is useful to permit efficient redirection of operations between based on just the opcode.
For example, one might
- redirect bind/unbind to an authentication / authorisation unit
- redirect traffic inside an authorised session to a private backend
- redirect traffic outside of authorisation to a public backend
- use the Proxy Authorization Control for the private backend
This requires very little parsing of operations to be able to pass them through; one would only be concerned with the markers of a BindRequest and UnbindRequest and one would need to inspect if a BindResponse reported success.
In a slight variation, the redirecting LillyDAP node might perform authentication / authorisation locally, in which case any BindRequest would be parsed locally, and BindResponse produced locally. This is still possible with the intermediate level proposed here, simply by calling lillyget_operation() for these specific opcodes (while still redirecting other opcodes as before).
An operation lillyput_opcode() makes less sense than lillyget_opcode(), but should nonetheless be there for mirrorring purposes.
The dual parameter dercursor operation and some_int opcode make less than perfect sense because they mention the operation data in two places; the overriding concern must be the impact the opcode has on the structure of the operation parameter, so in lillyput_opcode(), even though it mentions the opcode parameter for mirrorring reasons, the parameter will be ignore.
We may implement lillyput_opcode() as a static inline function in <lillydap/api.h>.
Note that the lillyput_opcode() will be called from lillyput_operation(), so it does represent an extra tapping point on the outgoing side, similar to the extra tapping point on the incoming side.
Potential problem, an oversight when designing LillyDAP: In ExtendedResponse the field responseName is OPTIONAL. The reasoning being that the LDAPMessage contains a messageId that refers back to a request whose opcode was sent by the initiating party. This means that complete stateless handling is not always possible.
We currently treat the messageId-based binding as an application concern, not the concern of LillyDAP. This really helps to keep the parser simple and stateless. It would be a pitty to break that.
The suggested extra callback for lillyget_opcode() can be helpful in just that: it can be called with opcode 24 for ExtendedResponse, which can then be handled in that routine by calling the library's routine with a more detailed code, if so required. Application handlers know what response connects to what request, after all.
Most ExtendedResponse messages have an empty or even absent responseValue anyway, so it will not be needed in many cases anyway. Only the LDAPResult fields, which are included in the ExtendedResponse, are of value, but see issue #6 for that.
Decision made:
lillyget_opresp()overrideslillyget_opcode()for message dispatchlillyget_response()overrideslillyget_operation()for message dispatch- these overrides are only used for results (depending on the opcode)
- there are no library implementations for overrides; use the overridden one instead
- when not overridden, the original function is called
- mirrorring upward operations are added with
lillyput_prefix - result and operation calls are type compatible and may be mixed as desired
