On Fri, Nov 06, 2015 at 03:51:30PM +0100, Pavel Březina wrote:
Hi!
Since we have pretty nice custom error codes, I would like to get rid of
DP_ERR_* codes. They are practically useless and are adding non-trivial
complexity to the code.
I did only a quick look so it is possible that I missed something, but let's
talk about it. We have the following codes:
>#define DP_ERR_OK 0
DP_ERR_OK is usually used in combination with EOK and in most cases it is
treated as error (or worse not handled at all). There are some situations
when DP_ERR_OK and !EOK is used, it is mostly in combination with PAM error
code and access control, but we can handle this with custom error codes.
>#define DP_ERR_OFFLINE 1
DP_ERR_OFFLINE means EAGAIN, always. This should be changed to ERR_OFFLINE
or similar custom error o
This error code can't be returned from provider's can it?
>#define DP_ERR_TIMEOUT 2
This is not used at all.
I guess this was meant to be used for cases where the DP takes too long
to answer and the request is cancelled.
>#define DP_ERR_FATAL 3
This is other than EOK code and should be avoided.
Having only one error code from sdap operations would simplify code flow and
make the code less error prone.
I don't think we should leak sdap error codes to responders (and data
provider is mostly a layer between responders and providers). The
authentication code currently returns PAM error codes to DP..
What if the provider returned a single error code but we still retained
a tuple of (dp_err, provider_err) towards the responders? Then DP_ERR_OK
and DP_ERR_OFFLINE wouldn't use the minor error code but DP_ERR_FATAL
would transfer the error from the provider along with sss_strerror()
or similar explanation?
Then providers would return a single error code, but responder would
be able to distinguish between cases where all went fine, where provider
wasn't even contacted and failures...
In my opinion this should be part of or even prerequisite to ldap provider
and sdap_id_op refactoring.
How is DP interface related to sdap_id_op code?