Can we make `NGitLab.Impl.Json.Serializer` public?

[PMExtra]

NGitLab.Impl.Json.Serializer is an internal class for now.

I have 2 use cases where I want to reuse the serializer in my own code:

1. For a special purpose, we want the Get job token’s job API, it's not a common use case and it requires a special authentication mechanism that is different from other API. So, I don't think it falls under NGitLab. I made my own client for this API, and I reused some models from NGitLab. But as you know, we need some JSON converters to serialize or deserialize with GitLab. If we can't reuse the NGitLab.Impl.Json.Serializer we have to reimplement them.

2. We plan to carry out secondary development of GitLab in the future and may add some customized API. At this point, we have to implement our own clients, but they can still reuse some models from NGitLab, and they also follow GitLab's serialization rules which need the serializer.

To sum up, I request to make NGitLab.Impl.Json.Serializer public.

[meziantou]

I don't think exposing the serializer is the correct way to do it.

1. NGitLab doesn't support the Get job token’s job API endpoint, but it could be fixed.
2. If we need to expose something, I think it should be a way to send custom http request. That way you would be able to implicitly use the serializer and the retry policy.

[PMExtra]

@meziantou Awesome! The solution you gave is better for me. Can we put these on the schedule?

[meziantou]

1. This seem easy to add the new call to NGitLab
2. This will require an initial design. I'm not sure how/where we should expose this new method. If you have ideas, feel free to suggest.

I don't think we'll have time to work on this issue on our side, however we'll take time to review a PR or help someone working on it.

[PMExtra]

For the 1st, how can I disable the default credential from API class?

[meziantou]

You can create a new client with the job token as credential. This token is added as Authorization: Bearer <token> (https://github.com/ubisoft/NGitLab/blob/357e208431142fe680ef13e7439fa40cd1751a05/NGitLab/Impl/HttpRequestor.GitLabRequest.cs#L55). So, this should work for the Get job token’s job API

[PMExtra]

The documentation only says that you can put Personal/project/group access tokens in Authorization: Bearer <token>. There is another section for the job token, which does not indicate that it can be written in the Authorization header.

From the Get job token’s job API document, there are multiple ways to pass the job token, but there is also no option to pass it through the Authorization header.

I'm not sure it works this way, but it's not guaranteed by the documentation.

I think a safer way is to pass the job token from query parameters without any authentication headers.

[meziantou]

I'm not sure it works this way, but it's not guaranteed by the documentation.

The GitLab documentation sometimes lags behind the actual implementation. It would requires a test to ensure everything works as expected.

I think a safer way is to pass the job token from query parameters without any authentication headers.

I don't know if safer is correct. As URLs are often logged, the token could be part of logs. But I understand that it's the documented way.

I don't know how GitLab behaves when both the query string parameter and the header are used at the same time (i.e. new GitLabClient("url", "user token").Jobs.GetJobFromToken("job token")). If it doesn't work, we have 2 choices:

• Create a new client without the user token. I'm not sure this is supported with the current code.
• Allow a method to send an unauthenticated request. Would require some changes to the code, but I don't think it's complicated