Add HeyBoxChat to the list of supported providers

[gehongyan]

This pull request would like to add HeyBoxChat to the list of supported providers.

[gehongyan]

Docs

• OAuth: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/7145802m0
• Auth Page: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/329051392e0
• Token Request: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/329070402e0
• User Info Request: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/329599863e0
• Token Refresh Request: https://s.apifox.cn/43256fe4-9a8c-4f22-949a-74a3f8b431f5/329079907e0

Hints

• HeyBoxChat is a product similar to Discord, and its API provides bot-like capabilities.
• HeyBoxChat currently hosts its documentation on Apifox, a product similar to Postman.
• The user authorization page does not have a "Deny" button.
• The token request requires additional query parameters to declare to their gateway that the requests are coming from a bot, rather than from their own client or web product carrying user login information. Although the documentation does not explicitly state this, it is the case in practice.
• The token request requires the bot token to be included in the request headers.
• In the response body of user info requests, the user information is wrapped in the "result" field.

Note

Question 1: Of the 7 additional query parameters that need to be passed, "chat_version" may change as their product updates, while the other fields remain the same for requests coming from a Bot. Do we need to introduce a setting for "chat_version"?

Useful Screenshots (Machine translated from Chinese)

• Bot development platform

  Here is the bot token.

  

• Auth page.

  

• Console demo.

  

[kevinchalet]

Thanks for your PR! ❤️

Token requests and user info requests require additional query parameters to declare to their gateway that the requests are coming from a bot, rather than from their own client or web product carrying user login information. Although the documentation does not explicitly state this, it is the case in practice.

👍🏻
AFAICT, you added the code necessary to add these query string parameters to the token request but not the userinfo request. Is it deliberate?

Question 1: Of the 7 additional query parameters that need to be passed, "chat_version" may change as their product updates, while the other fields remain the same for requests coming from a Bot. Do we need to introduce a setting for "chat_version"?

Hum, good question. If that "chat version" thing is like an API version, we usually don't expose that as a setting: instead, it's purely an internal thing we update when the schema changes and requires changing something in our implementation.

FYI: I see you blurred the oi_reg_id claim in your screenshot: unless you explicitly set it to a specific value, it's just a SHA256 hash of the issuer URI and provider name (if present). In this case both values are known and public so no point wasting too much time hiding it:

openiddict-core/src/OpenIddict.Client/OpenIddictClientConfiguration.cs

Lines 309 to 341 in 4902658

	static string ComputeDefaultRegistrationId(OpenIddictClientRegistration registration)
	{
	Debug.Assert(registration.Issuer is { IsAbsoluteUri: true }, SR.GetResourceString(SR.ID4013));
	using var algorithm = CreateAlgorithm();
	TransformBlock(algorithm, registration.Issuer.AbsoluteUri);
	if (!string.IsNullOrEmpty(registration.ProviderName))
	{
	TransformBlock(algorithm, registration.ProviderName);
	}
	algorithm.TransformFinalBlock([], 0, 0);
	return Base64UrlEncoder.Encode(algorithm.Hash);
	[UnconditionalSuppressMessage("Trimming", "IL2026",
	Justification = "The default implementation is always used when no custom algorithm was registered.")]
	static SHA256 CreateAlgorithm() => CryptoConfig.CreateFromName("OpenIddict SHA-256 Cryptographic Provider") switch
	{
	SHA256 result => result,
	null => SHA256.Create(),
	var result => throw new CryptographicException(SR.FormatID0351(result.GetType().FullName))
	};
	[MethodImpl(MethodImplOptions.AggressiveInlining)]
	static void TransformBlock(HashAlgorithm algorithm, string input)
	{
	var buffer = Encoding.UTF8.GetBytes(input);
	algorithm.TransformBlock(buffer, 0, buffer.Length, outputBuffer: null, outputOffset: 0);
	}
	}

😃

[gehongyan]

Is it deliberate?

The user info API indeed does not require those parameters now; only the token API does.

Only the token API requires those query parameters. I also want to push for them to remove all these query parameters. If there are any optimizations, I think I will update them here as well.

It seems that the user info API does not require a bot token anymore.

it's purely an internal thing we update when the schema changes and requires changing something in our implementation.

Copy that!

both values are known and public so no point wasting too much time hiding it

Many thanks! ❤️

[gehongyan]

I have received news from their development team that one day those query parameters will no longer be required, but it is still uncertain when this change will happen. When they update it, they will inform me, and I will also update it here.

[kevinchalet]

Many thanks! ❤️

My pleasure! ❤️

I have received news from their development team that one day those query parameters will no longer be required, but it is still uncertain when this change will happen. When they update it, they will inform me, and I will also update it here.

👍🏻

Do you think we can ship this provider as-is (or maybe with the parameters added to the userinfo request, just in case) or do you prefer waiting until they change their implementation?

7.1.0 is around the corner, so if you prefer the first option, it may ship quickly 😃

[gehongyan]

7.1.0 is around the corner, so if you prefer the first option, it may ship quickly

Sounds great! I will make another pull request to update the code if they make any further changes.

[gehongyan]

Now, only chat_os_type is required in the query string. chat_version is optional, but keeping the version control working may be a good choice.

[kevinchalet]

Now, only chat_os_type is required in the query string. chat_version is optional, but keeping the version control working may be a good choice.

Should we also add these parameters to the userinfo request, tho' you said they are not currently required in practice? Just in case, you know 😄

[kevinchalet]

Regarding the name, do we know what the official casing is?

A quick search on Google doesn't return a lot of results (I guess the Chinese name is a lot more popular?), but "Heybox Chat" seems to be the most common result.

If it's the correct casing, we should probably name the provider HeyboxChat and add a DisplayName="Heybox Chat" attribute so Heybox Chat is used in all the documentation code.

[gehongyan]

Should we also add these parameters to the userinfo request, tho' you said they are not currently required in practice? Just in case, you know 😄

I confirmed with the official development team earlier today that the /chatroom/api/* information retrieval endpoints only require a bearer token if a bearer token has been obtained.

Regarding the name, do we know what the official casing is?

Before I opened this pull request, I had asked them what English names they prefer. The answer was that they do not have an official English name, and HeyBoxChat should be okay. However, the HeyBoxChat is a derivative product of HEYBOX, which is written with all uppercase letters.

• HEYBOX: 小黑盒 (xiao hei he), means a little black box if translated directly.
• HeyBoxChat: 黑盒语音 (hei he yu yin), means black box voice if translated directly.

---

About the parameter necessities and official English names, I will communicate with the development and operations teams tomorrow for confirmation.

If you need to release a new version as soon as possible, it is okay to postpone completing this pull request, since it is not urgent.

[gehongyan]

Should we also add these parameters to the userinfo request

They have confirmed that the userinfo API does not require those parameters. This API is located under the /api request path, and APIs under this path will not be reused with requests from the HeyBoxChat client and web with user login info. Therefore, there is no need to differentiate the source, and those parameters are not needed.

Regarding the name, do we know what the official casing is?

They have confirmed the name HeyBoxChat, rather than other spellings or variations in capitalization. Based on their reply, this should be regarded as a proper noun as a whole.

---

Based on the above, it seems that there is currently no code that needs further modification. Of course, if you have any ideas or hold certain opinions, I am also happy to listen to and respect them. 😄

[kevinchalet]

Therefore, there is no need to differentiate the source, and those parameters are not needed.

👍🏻

They have confirmed the name HeyBoxChat, rather than other spellings or variations in capitalization. Based on their reply, this should be regarded as a proper noun as a whole.

Perfect! Thanks for taking the time to deal with that! It's nice to see they positively replied to your demand 😄

Based on the above, it seems that there is currently no code that needs further modification. Of course, if you have any ideas or hold certain opinions, I am also happy to listen to and respect them. 😄

Great, let's merge it then! ❤️

[kevinchalet]

Merged, thanks a lot for this great contribution! 👏🏻

[kevinchalet]

Hey @gehongyan,

FYI, 7.1.0 just shipped with your new provider: https://github.com/openiddict/openiddict-core/releases/tag/7.1.0 🎉