Questions about "DingTalk bot command" epic
Hi, there
There are some questions related epic "DingTalk Bot Command/Slash Command".
I am so sorry I write so many context and raise so many questions, but I really want to hear your suggestion and feedback Integration
@.luke I create video to demonstrate dingtalk workflow, please take a look.
Background
DingTalk, an intelligent working platform in China, is similar like Slack, JiHu will create DingTalk bot on Ding Market Place and enable our customer to install that bot, communicate with JiHu, such as create issue and so on.
Differences and Constraints However there are some differences and constraints as Slack Integration:
- There is only one bot instance in DingTalk platform.
- The bot can be installed in group chat channel or personal channel for different customers.
- The bot can only forward message from Ding Platform to JiHu, there is no chance for us to add more logic inside bot in Ding Platform.
Create Bot & Install the Bot
When JiHu define the bot on Ding Platform, we can define two endpoint,
-
installed bot event
end point: When customer install Bot in their group channel, Ding platform will send "installed event" message to JiHu, message contains basic customer company's info and we need store that info into db. It will only send one time for one customer. -
forward message
end point: when user send message to bot, bot will forward that message to specific end point, such as gitlab.com/xxxx.
Because different customers share the same bot, so we have to provide one api endpoint to accept all customer's "installed event" message, another api endpoint to receive all customer' message.
Questions:
- what is the correct api path I shall build? such as
gitlab/api/v4/integration/ding/installation
for receive installed event message?gitlab/api/v4/integration/ding/message
form receive message? is there any suggestion? - which file should I focus for defining above api endpoints?
- After we receive the
installed event
, we will store that event in DB, we expect the table schema is like below, make sense?
platform_name | corporation_id | status | active_timestamp | inactive_timestamp |
---|---|---|---|---|
dingtalk | company_1 | active | 2022-02-02 00:00:00 |
Authentication & Authorization
Ding Platform will generate Bot Secret
after we create the bot, we need config this secret into GitLab and use it to verify the Ding message by calculate message content's signature and compare with original signature in message.
What's more, we also need authorize user before execute the Ding message. When user send message first time, Gitlab need response gitlab's link to user, after user open that link, Gitlab will bind Ding User Id
to Gitlab user id
, save the linkage to db. Then Gitlab will figure out which gitlab user from ding user id in message.
Questions:
- How do I add the DingTalk Bot secret into Gitlab? which file should I modify? The secret is instance level, not group/project level.
- Where should I put the logic of
verify message signature
? I found there are 5 ways to Authenticate API,OAuth2 tokens
,Personal access tokens
,Project access tokens
,Session cookie
,GitLab CI/CD job token (Specific endpoints only)
, none of these can be used in Ding's scenario, do you think JH can introduce 6th way of API Authenticate? If so, how can I introduce it in codebase? - We are planing to introduce a feature toggle to turn of/off gitlab
receive DingTalk bot command message
, it is still instance level, do you agree? - we are planning to add
Ding Slash Command
inGroup/Project's Integration page
, there is nothing to config, but just control whether Ding bot message is executable in this group/project. make sense? - User should visit specific page to
binding Ding user
, we notice gitlab use pagehttps://gitlab.com/-/profile/chat_names
to list all chat mapping for user, however DingTalk scenario is different, there is noTeam domain
andProject
in Ding's mapping, we expect the table schema should like below, I don't think JH can reuse existing modelChatName
, JH should build new model or inherit existingChatName
model, do you have some suggestion?
gitlab_user_id | platform_name | platform_global_id | platform_user_id |
---|---|---|---|
gitlab_user_1 | dingtalk | ding_global_1 | ding_user_1 |
gitlab_user_2 | wecom | wecom_global_1 | wecom_user_1 |
gitlab_user_3 | feishu | feishu_global_1 | feishu_user_1 |
- When user visit "bind Ding user" page, they may redirect to login page first, after login they will redirect back to "bind Ding user" page. However I notice there are several ways to login, username/password, 3rd platform OAuth(Facebook, Google) and Group SAML. Do you think these 3rd party login method may break "return back to bind Ding user page after login"?
Self Manage GitLab
JiHu will create official GitLab Ding Bot
on Ding platform to integrate with SAAS GitLab. For Self Manage GitLab instance, we will provide document to guide customer to create their own Ding Bot
on Ding Platform to integrate with Self Manage GitLab instance. The reason is official GitLab Ding Bot
can only have one message endpoint, always be gitlab sass. any feedback about this idea?
Upstream Feature or JH Feature
after reading all stuff above, do you think this feature belongs to upstream, or JH only?
thanks again for reading this and answering our questions
update @arturoherrero @g.hickman @.luke I generate the DingTalk Workflow chart, please take a look
also have a video to explain the dingtalk workflow