问题描述
面临一个挑战，需要将来自GitLab（外部独立服务）的Webhook连接到位于Openshift上的Jenkins（一个容器化应用）。然而，当任何人尝试登录Jenkins时，他们首先会被重定向到Openshift，要求提供他们的凭据，然后会获得一个OAuth令牌，并被重定向回Jenkins。
因此，当GitLab尝试通知Jenkins有新的构建（由开发人员推送），它无法通过这个OAuth阶段。
问题评论： 谢谢你的问题。能否修改问题，说明你已经尝试过哪些方法来解决这个问题？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
在这种情况下，你需要找到一种方法来绕过OAuth重定向，以便GitLab能够成功地将Webhook传递给Jenkins。以下是几种可能的解决方案：
方案1：创建代理服务器
你可以创建一个位于Openshift之前的代理服务器，该代理服务器负责处理OAuth重定向。代理服务器可以在收到来自GitLab的Webhook请求后，执行OAuth流程，获取有效的令牌，然后将请求重定向到Jenkins。这样，Jenkins将接收到不受OAuth阻塞的Webhook请求。
下面是基本的步骤：
- 在代理服务器上设置一个端点，用于接收来自GitLab的Webhook请求。
- 当代理服务器收到请求时，执行OAuth认证流程，获取有效的令牌。
- 使用获得的令牌，代理服务器向Jenkins发送修改后的Webhook请求。
这样，代理服务器就充当了GitLab和Jenkins之间的中间人，负责处理OAuth认证并将Webhook传递给Jenkins。
方案2：使用Personal Access Token
如果你可以在Openshift上为Jenkins配置Personal Access Token（PAT），那么可以使用该PAT来绕过OAuth认证。PAT是一种无需进行OAuth流程即可进行身份验证的凭据。
以下是基本的步骤：
- 在Openshift上的Jenkins配置中创建一个Personal Access Token（可以在用户设置中找到）。
- 在GitLab中配置Webhook，将刚刚创建的Personal Access Token作为身份验证凭据，而不是OAuth令牌。
通过使用PAT，GitLab将不再需要执行OAuth重定向流程，而是直接使用Token进行身份验证，从而绕过了OAuth的问题。
请注意，这两种方案都需要一定的配置和设置，具体的步骤可能会因为版本差异而有所不同。在执行任何更改之前，请务必备份你的配置，以防万一出现问题。
总结
处理位于OAuth重定向后面的Webhook端点可能会涉及一些复杂的步骤和配置。你可以考虑创建代理服务器来处理OAuth认证，或者尝试使用Personal Access Token来绕过OAuth。在实施任何更改之前，请确保理解配置的影响，并确保备份重要的设置。