On 11/06/2015 04:21 PM, Jakub Hrozek wrote:
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...
Yes, this makes sense.
> 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?
dp_err is in most cases generated in sdap_id_op and than bubbles up. If
sdap_id_op doesn't use it, we can get rid of most of its references.