Details
-
New Feature
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Not A Defect
-
None
Description
It would be great if the plugin could use a Rocket.Chat API key, instead of having to store a username and password in the configuration.
Attachments
Issue Links
- links to
Activity
Sean Flanigan
added a comment - Well, I am in that boat (SSO, not an admin), and I later got an admin to create a special bot user for Jenkins to bypass SSO (without success so far: JENKINS-42365). Before that, I was hoping to avoid putting my password into Jenkins, and I'd prefer not to put the bot's password in either.
I was under the impression Rocket.Chat had API keys, but apparently not (just temporary tokens): https://rocket.chat/docs/developer-guides/rest-api/authentication/
Unless Rocket.Chat gets API keys with restricted capabilities (eg only write to a particular channel, no reading), they wouldn't really be more secure than passwords anyway.
Without API keys in Rocket.Chat, I think my request is invalid. Closing.
PS webhook integrations in Rocket.Chat do seem to have restricted capabilities, so I would support that idea. I think it should be a separate issue though.
Sean Flanigan
added a comment - ssbarnea
Well, I am in that boat (SSO, not an admin), and I later got an admin to create a special bot user for Jenkins to bypass SSO (without success so far: JENKINS-42365 ). Before that, I was hoping to avoid putting my password into Jenkins, and I'd prefer not to put the bot's password in either.
I was under the impression Rocket.Chat had API keys, but apparently not (just temporary tokens): https://rocket.chat/docs/developer-guides/rest-api/authentication/
Unless Rocket.Chat gets API keys with restricted capabilities (eg only write to a particular channel, no reading), they wouldn't really be more secure than passwords anyway.
Without API keys in Rocket.Chat, I think my request is invalid. Closing.
PS webhook integrations in Rocket.Chat do seem to have restricted capabilities, so I would support that idea. I think it should be a separate issue though. Code changed in jenkins
User: Robert Williams
Path:
src/main/java/jenkins/plugins/rocketchatnotifier/RocketChatNotifier.java
src/main/java/jenkins/plugins/rocketchatnotifier/RocketClientWebhookImpl.java
src/main/java/jenkins/plugins/rocketchatnotifier/rocket/RocketChatClientCallBuilder.java
src/main/java/jenkins/plugins/rocketchatnotifier/rocket/RocketChatClientImpl.java
src/main/java/jenkins/plugins/rocketchatnotifier/rocket/RocketChatWebhookAuthentication.java
src/main/resources/jenkins/plugins/rocketchatnotifier/RocketChatNotifier/config.jelly
http://jenkins-ci.org/commit/rocketchatnotifier-plugin/c7a069686e8c87c4e2390bb0f018dbe464fbaeb3
Log:
Add support for per-build webhook configuration
Add field to build for webhook token or URL. This overrides
any saved authentication and channel data and can only post
to a single channel.
Update `RocketChatClientImpl` and `RocketChatClientCallBuilder` to
take webhook token and invoke a new authenticator for webhooks.
Related: JENKINS-42099
How about webhook + token? The reality is that most big deployments are using some form of SSO with 2FA which renders username/password authentication useless. The user trying to configure Jenkins is almost not sure an admin on the IM server so he cannot create new accounts.