Uploaded image for project: 'Jira Cloud'
  1. Jira Cloud
  2. JSWCLOUD-22729

As an admin, I want to be able to hide values in automation rules, e.g. web requests using tokens in header

XMLWordPrintable

    • 5

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Problem Definition

      Oftentimes users create rules to send web requests using tokens/keys in the authorization header. As tokens/keys act like passwords for accounts, this can bring security issues as those keys are exposed to other users in the instance that have access to the automation rules.

      Suggested Solution

      Create a new section in automation where admins can create smart value variables to be used in any automation rule, where those values will be managed only by the users the admins allow.

          Form Name

            [JSWCLOUD-22729] As an admin, I want to be able to hide values in automation rules, e.g. web requests using tokens in header

            Mohsin Shaikh made changes -
            Link New: This issue was cloned as JSWCLOUD-26819 [ JSWCLOUD-26819 ]
            Mike Howells made changes -
            Workflow Original: JAC Suggestion Workflow JSWCLOUD [ 4266985 ] New: JAC Suggestion Workflow 3 [ 4374979 ]
            Armando Neto made changes -
            Link New: This issue is related to JIRAAUTOSERVER-522 [ JIRAAUTOSERVER-522 ]

            Kalin Uzhdrin added a comment -

            Oh, I see and completely agree with your points, Ignacio. Yes, a message/warning on the component page will be very beneficial. I lost valuable time troubleshooting this.

            Kalin

            Kalin Uzhdrin added a comment - Oh, I see and completely agree with your points, Ignacio. Yes, a message/warning on the component page will be very beneficial. I lost valuable time troubleshooting this. Kalin

            Ignacio Pulgar added a comment -

            Hi e6207b92a2be ,

            I think that's the expectable and desirable behaviour, except for the fact that it is not being notified through a message.

            Imagine you have used your own user credentials for setting a rule that targeted Jira REST API for reading a value and adding a comment to an issue, according to the information collected, just as an example of a harmless and legit good usage of the rule.

            Now, think that someone else with bad intentions edits/copies your rule to delete all issues in the Jira instance... in your own name! since it would be using your credentials...

            So, for me it is the correct behaviour for security reasons, but not well informed through the UI.

            Thanks and regards

            Ignacio Pulgar added a comment - Hi e6207b92a2be , I think that's the expectable and desirable behaviour, except for the fact that it is not being notified through a message. Imagine you have used your own user credentials for setting a rule that targeted Jira REST API for reading a value and adding a comment to an issue, according to the information collected, just as an example of a harmless and legit good usage of the rule. Now, think that someone else with bad intentions edits/copies your rule to delete all issues in the Jira instance... in your own name! since it would be using your credentials... So, for me it is the correct behaviour for security reasons, but not well informed through the UI. Thanks and regards

            Kalin Uzhdrin added a comment -

            I was excited to use this functionality and it initially worked.

            However, I found a couple of cases where the functionality breaks:

            1. the header is obfuscated, the rule is saved, then a validation is performed in the "send web request" component > after this the obfuscated value is no longer passed to the API endpoint correctly.
            2. an automation rule is copied with an already obfuscated header in the webhook component > the copy rule no longer passes the obfuscated value to the API endpoint correctly.

            A fellow user has found a third case when the "send web request" component (webhook) with an obfuscated header is nested in the rule tree - see https://jira.atlassian.com/browse/AUTO-192

             89403358cf11, I am looking forward for your feedback. Hopefully, you can address these.

            Kalin Uzhdrin added a comment - I was excited to use this functionality and it initially worked. However, I found a couple of cases where the functionality breaks: the header is obfuscated, the rule is saved, then a validation is performed in the "send web request" component > after this the obfuscated value is no longer passed to the API endpoint correctly. an automation rule is copied with an already obfuscated header in the webhook component > the copy rule no longer passes the obfuscated value to the API endpoint correctly. A fellow user has found a third case when the "send web request" component (webhook) with an obfuscated header is nested in the rule tree - see https://jira.atlassian.com/browse/AUTO-192   89403358cf11 , I am looking forward for your feedback. Hopefully, you can address these.
            Charlie Gavey made changes -
            Resolution New: Fixed [ 1 ]
            Status Original: Gathering Interest [ 11772 ] New: Closed [ 6 ]

            Charlie Gavey added a comment -

            Outgoing webhooks now have the option to obfuscate headers

            Charlie Gavey added a comment - Outgoing webhooks now have the option to obfuscate headers
            Charlie Gavey made changes -
            Link New: This issue is duplicated by JSDCLOUD-11747 [ JSDCLOUD-11747 ]
            Charlie Gavey made changes -
            Link New: This issue is duplicated by JSWCLOUD-22727 [ JSWCLOUD-22727 ]

              89403358cf11 Charlie Gavey
              bd0e47de2684 Yuri Moura (Inactive)
              Votes:
              23 Vote for this issue
              Watchers:
              20 Start watching this issue

                Created:
                Updated:
                Resolved: