Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-59980

JQL filter for Webhooks doesn't work correctly when "Comment" and "Worklog" related events are fired - CVE-2017-18104

      NOTE: This bug report is for JIRA Server. Using JIRA Cloud? See the corresponding bug report.

      Security information

      The Webhooks component of Atlassian Jira before version 7.6.7 and from version 7.7.0 before version 7.11.0 allows remote attackers who are able to observe or otherwise intercept webhook events to learn information about changes in issues that should not be sent because they are not contained within the results of a specified JQL query.

      Summary

      JQL filter for Webhooks dosn't work correctly when Comment or Worklog related events are fired.

      Steps to Reproduce

      1. Create an webhook as follows
        • Issue related events
          • JQL: project = <PROJECTKEY>
          • Issue: created, updated
          • Comment: created, updated
          • Worklog: created,updated
      2. Comment or log work on an issue in a project aside from the one which is specified with the JQL

      Expected Results

      The webhook shouldn't be fired.

      Actual Results

      The webhook was fired.

      Notes

      When it comes to NOT "Comment" or "Worklog" related events (like creating issue, updating issue),
      the JQL filters the events correctly.

        1. jql.diff
          3 kB
        2. webhooks.png
          webhooks.png
          27 kB
        3. webhook.png
          webhook.png
          323 kB

            [JRASERVER-59980] JQL filter for Webhooks doesn't work correctly when "Comment" and "Worklog" related events are fired - CVE-2017-18104

            Hello zansm,

            The issue is resolved since Jira 7.6.7 and above. We recommending upgrading the instance to address the issue.

            Cheers,
            Ignat Alexeyenko
            Jira bugmaster.

            Ignat (Inactive) added a comment - Hello zansm , The issue is resolved since Jira 7.6.7 and above. We recommending upgrading the instance to address the issue. Cheers, Ignat Alexeyenko Jira bugmaster.

            Zans McLachlan added a comment - - edited

            Any updates on this issue? This is causing a ton of spam from "on comment" events across the instance...

            We are on 7.4.5 if that helps.

            Zans McLachlan added a comment - - edited Any updates on this issue? This is causing a ton of spam from "on comment" events across the instance... We are on 7.4.5 if that helps.

            iavxhi
            Could you tell me if project is at least correctly filtered?
            If issue was ever transitioned from progress to done it will be searchable by this query.
            "Status" searches by history not by current transition...
            Maybe this is the case?

            Waiting for your reply.

            ΞΔ (Inactive) added a comment - iavxhi Could you tell me if project is at least correctly filtered? If issue was ever transitioned from progress to done it will be searchable by this query. "Status" searches by history not by current transition... Maybe this is the case? Waiting for your reply.

            Irdi Avxhi added a comment - - edited

            I downloaded the Jira locally and i try the following for an updated issue ( Kanban)

            It triggers when you change the workflow for each state. so change isn't included in the version that i have downloaded or this case is not fixed 7.11.0-x64.

             project = "projectName" and status CHANGED FROM "In Progress" TO "Done"

             Probably i am gonna have to handle it myself by ignoring the post.

            Irdi Avxhi added a comment - - edited I downloaded the Jira locally and i try the following for an updated issue ( Kanban) It triggers when you change the workflow for each state. so change isn't included in the version that i have downloaded or this case is not fixed 7.11.0-x64. project = "projectName" and status CHANGED FROM "In Progress" TO "Done"  Probably i am gonna have to handle it myself by ignoring the post.

            Hello,
            Comment fix is awaiting release.
            Worklog fix is undergoing quality process and will be merged soon.

            ΞΔ (Inactive) added a comment - Hello, Comment fix is awaiting release. Worklog fix is undergoing quality process and will be merged soon.

            Hello,
            I'm sorry it took so long, however we had a lot on our side recently.
            Currently comment webhook is going to be merged soon.
            However worklog hook still needs to be assesed.

            ΞΔ (Inactive) added a comment - Hello, I'm sorry it took so long, however we had a lot on our side recently. Currently comment webhook is going to be merged soon. However worklog hook still needs to be assesed.

            how is this going? we would like to have this fixed sooner or later  

            Stefano Brillante added a comment - how is this going? we would like to have this fixed sooner or later  

            Do we know the hold up then? It is actually a security vulnerability - or at least we treat it as such.

            Aaron Freeman added a comment - Do we know the hold up then? It is actually a security vulnerability - or at least we treat it as such.

            @David Sumlin - it's worse than that! They've already FIXED IT in their cloud version and aren't including the fix for JIRA Server.

            Nathan Neulinger added a comment - @David Sumlin - it's worse than that! They've already FIXED IT in their cloud version and aren't including the fix for JIRA Server.

            So, let me get this straight.  According to Atlassian this is a verified bug, yet over 2 years later, no comment, no ... nothing.  And Nathan above is basically telling them what code they need to change.

            Come on guys...instead of dumping a bajillion hours into Stride, how about fixing the product that got you the customers in the first place?

            David Sumlin added a comment - So, let me get this straight.  According to Atlassian this is a verified bug, yet over 2 years later, no comment, no ... nothing.  And Nathan above is basically telling them what code they need to change. Come on guys...instead of dumping a bajillion hours into Stride, how about fixing the product that got you the customers in the first place?

            Vote for treating this as security vulnerability because this nearly caused a security incident on our system!

            Lauri Korpela added a comment - Vote for treating this as security vulnerability because this nearly caused a security incident on our system!

            Was able to hack at the sources and disable the frontent npm/gulp stuff enough to let me build this one plugin, and this patch appears to solve this. I have not gone through much other than trivial testing to see that I no longer get comment webhook calls when the jql doesn't match:

            jql.diff

            Atlassian - please do your part and apply this if it looks good, and if not, please indicate why it doesn't look ok.

            Nathan Neulinger added a comment - Was able to hack at the sources and disable the frontent npm/gulp stuff enough to let me build this one plugin, and this patch appears to solve this. I have not gone through much other than trivial testing to see that I no longer get comment webhook calls when the jql doesn't match: jql.diff Atlassian - please do your part and apply this if it looks good, and if not, please indicate why it doesn't look ok.

            Well, apparently ability to build from source has been broken for quite some time now - https://jira.atlassian.com/browse/JRASERVER-66224

            So I likely will not be able to test this out.

            Nathan Neulinger added a comment - Well, apparently ability to build from source has been broken for quite some time now - https://jira.atlassian.com/browse/JRASERVER-66224 So I likely will not be able to test this out.

            Nathan Neulinger added a comment - - edited

            I took a look at the sources and it looks like fixing this may be simple - some notes below.
            I may be misinterpreting here, but it looks like just getting the comment event handlers changed
            to the 4 argument creator functions would address the lack of filtering.

            jira-project/jira-components/jira-plugins/jira-webhooks-plugin/src/main/java/com/atlassian/jira/plugins/webhooks

            registration/RegisteredWebHookEventFactory.java:
            
                private RegisteredWebHookEvent event(final String id, final String namei18nKey, final Class<?> eventClass) {
                    return RegisteredWebHookEvent
                            .withId(id)
                            .andDisplayName(namei18nKey)
                            .firedWhen(eventClass)
                            .isMatchedBy(EventMatchers.ALWAYS_TRUE);
                }
            
                private <T> RegisteredWebHookEvent event(String id, String displayName, Class<T> eventClass, EventMatcher<? super T> matcher) {
                    return RegisteredWebHookEvent
                            .withId(id)
                            .andDisplayName(displayName)
                            .firedWhen(eventClass)
                            .isMatchedBy(matcher);
                }
            

            the call to set up the event handler for issue events calls event() using the 4 argument form:

                    WebHookEventGroup issueGroup = WebHookEventGroup.builder()
                            .nameI18nKey("webhook.group.issue")
                            .addEvent(event("jira:issue_created", "webhook.group.issue.created", IssueEvent.class, Sets.newHashSet(EventType.ISSUE_CREATED_ID)))
                            .addEvent(event("jira:issue_updated", "webhook.group.issue.updated", IssueEvent.class, Sets.newHashSet(EventType.ISSUE_ASSIGNED_ID,
                                    EventType.ISSUE_CLOSED_ID, EventType.ISSUE_REOPENED_ID, EventType.ISSUE_RESOLVED_ID,
                                    EventType.ISSUE_COMMENT_EDITED_ID, EventType.ISSUE_COMMENTED_ID, EventType.ISSUE_MOVED_ID,
                                    EventType.ISSUE_UPDATED_ID, EventType.ISSUE_WORKSTARTED_ID, EventType.ISSUE_WORKSTOPPED_ID,
                                    EventType.ISSUE_GENERICEVENT_ID, EventType.ISSUE_COMMENT_DELETED_ID)))
                            .addEvent(event("jira:issue_deleted", "webhook.group.issue.deleted", IssuePreDeleteEvent.class, Collections.<Long>emptySet()))
                            .addEvent(event("jira:worklog_updated", "webhook.group.issue.worklog.changed", IssueEvent.class, Sets.newHashSet(EventType.ISSUE_WORKLOG_UPDATED_ID,
                                    EventType.ISSUE_WORKLOG_DELETED_ID, EventType.ISSUE_WORKLOGGED_ID)))
                            .build();
            

            where the comment and worklog handlers use the 3 argument form with the corresponding "EventMatches.ALWAYS_TRUE":

                    WebHookEventGroup commentGroup = WebHookEventGroup.builder()
                            .nameI18nKey("webhook.group.comment")
                            .addEvent(event("comment_created", "webhook.group.comment.created", CommentCreatedEvent.class))
                            .addEvent(event("comment_updated", "webhook.group.comment.updated", CommentUpdatedEvent.class))
                            .addEvent(event("comment_deleted", "webhook.group.comment.deleted", CommentDeletedEvent.class))
                            .build();
            
                    WebHookEventGroup worklogGroup = WebHookEventGroup.builder()
                            .nameI18nKey("webhook.group.worklog")
                            .addEvent(event("worklog_created", "webhook.group.worklog.created", WorklogCreatedEvent.class))
                            .addEvent(event("worklog_updated", "webhook.group.worklog.updated", WorklogUpdatedEvent.class))
                            .addEvent(event("worklog_deleted", "webhook.group.worklog.deleted", WorklogDeletedEvent.class))
                            .build();
            

            As near as I can see - there are event type ids for comments in jira-project/jira-components/jira-api/src/main/java/com/atlassian/jira/event/type/EventType.java

                public static final Long ISSUE_CREATED_ID = 1L;
                public static final Long ISSUE_UPDATED_ID = 2L;
                public static final Long ISSUE_ASSIGNED_ID = 3L;
                public static final Long ISSUE_RESOLVED_ID = 4L;
                public static final Long ISSUE_CLOSED_ID = 5L;
                public static final Long ISSUE_COMMENTED_ID = 6L;
                public static final Long ISSUE_REOPENED_ID = 7L;
                public static final Long ISSUE_DELETED_ID = 8L;
                public static final Long ISSUE_MOVED_ID = 9L;
                public static final Long ISSUE_WORKLOGGED_ID = 10L;
                public static final Long ISSUE_WORKSTARTED_ID = 11L;
                public static final Long ISSUE_WORKSTOPPED_ID = 12L;
                public static final Long ISSUE_GENERICEVENT_ID = 13L;
                public static final Long ISSUE_COMMENT_EDITED_ID = 14L;
                public static final Long ISSUE_WORKLOG_UPDATED_ID = 15L;
                public static final Long ISSUE_WORKLOG_DELETED_ID = 16L;
                public static final Long ISSUE_COMMENT_DELETED_ID = 17L;
            

            I may try to see if what looks like a trivial addition to the code would resolve this problem on a test instance
            (assuming I can get the plugin built), but someone in a position to build jira from source should be easily able to test
            out the above.

            Nathan Neulinger added a comment - - edited I took a look at the sources and it looks like fixing this may be simple - some notes below. I may be misinterpreting here, but it looks like just getting the comment event handlers changed to the 4 argument creator functions would address the lack of filtering. jira-project/jira-components/jira-plugins/jira-webhooks-plugin/src/main/java/com/atlassian/jira/plugins/webhooks registration/RegisteredWebHookEventFactory.java: private RegisteredWebHookEvent event( final String id, final String namei18nKey, final Class <?> eventClass) { return RegisteredWebHookEvent .withId(id) .andDisplayName(namei18nKey) .firedWhen(eventClass) .isMatchedBy(EventMatchers.ALWAYS_TRUE); } private <T> RegisteredWebHookEvent event( String id, String displayName, Class <T> eventClass, EventMatcher<? super T> matcher) { return RegisteredWebHookEvent .withId(id) .andDisplayName(displayName) .firedWhen(eventClass) .isMatchedBy(matcher); } the call to set up the event handler for issue events calls event() using the 4 argument form: WebHookEventGroup issueGroup = WebHookEventGroup.builder() .nameI18nKey( "webhook.group.issue" ) .addEvent(event( "jira:issue_created" , "webhook.group.issue.created" , IssueEvent.class, Sets.newHashSet(EventType.ISSUE_CREATED_ID))) .addEvent(event( "jira:issue_updated" , "webhook.group.issue.updated" , IssueEvent.class, Sets.newHashSet(EventType.ISSUE_ASSIGNED_ID, EventType.ISSUE_CLOSED_ID, EventType.ISSUE_REOPENED_ID, EventType.ISSUE_RESOLVED_ID, EventType.ISSUE_COMMENT_EDITED_ID, EventType.ISSUE_COMMENTED_ID, EventType.ISSUE_MOVED_ID, EventType.ISSUE_UPDATED_ID, EventType.ISSUE_WORKSTARTED_ID, EventType.ISSUE_WORKSTOPPED_ID, EventType.ISSUE_GENERICEVENT_ID, EventType.ISSUE_COMMENT_DELETED_ID))) .addEvent(event( "jira:issue_deleted" , "webhook.group.issue.deleted" , IssuePreDeleteEvent.class, Collections.< Long >emptySet())) .addEvent(event( "jira:worklog_updated" , "webhook.group.issue.worklog.changed" , IssueEvent.class, Sets.newHashSet(EventType.ISSUE_WORKLOG_UPDATED_ID, EventType.ISSUE_WORKLOG_DELETED_ID, EventType.ISSUE_WORKLOGGED_ID))) .build(); where the comment and worklog handlers use the 3 argument form with the corresponding "EventMatches.ALWAYS_TRUE": WebHookEventGroup commentGroup = WebHookEventGroup.builder() .nameI18nKey( "webhook.group.comment" ) .addEvent(event( "comment_created" , "webhook.group.comment.created" , CommentCreatedEvent.class)) .addEvent(event( "comment_updated" , "webhook.group.comment.updated" , CommentUpdatedEvent.class)) .addEvent(event( "comment_deleted" , "webhook.group.comment.deleted" , CommentDeletedEvent.class)) .build(); WebHookEventGroup worklogGroup = WebHookEventGroup.builder() .nameI18nKey( "webhook.group.worklog" ) .addEvent(event( "worklog_created" , "webhook.group.worklog.created" , WorklogCreatedEvent.class)) .addEvent(event( "worklog_updated" , "webhook.group.worklog.updated" , WorklogUpdatedEvent.class)) .addEvent(event( "worklog_deleted" , "webhook.group.worklog.deleted" , WorklogDeletedEvent.class)) .build(); As near as I can see - there are event type ids for comments in jira-project/jira-components/jira-api/src/main/java/com/atlassian/jira/event/type/EventType.java public static final Long ISSUE_CREATED_ID = 1L; public static final Long ISSUE_UPDATED_ID = 2L; public static final Long ISSUE_ASSIGNED_ID = 3L; public static final Long ISSUE_RESOLVED_ID = 4L; public static final Long ISSUE_CLOSED_ID = 5L; public static final Long ISSUE_COMMENTED_ID = 6L; public static final Long ISSUE_REOPENED_ID = 7L; public static final Long ISSUE_DELETED_ID = 8L; public static final Long ISSUE_MOVED_ID = 9L; public static final Long ISSUE_WORKLOGGED_ID = 10L; public static final Long ISSUE_WORKSTARTED_ID = 11L; public static final Long ISSUE_WORKSTOPPED_ID = 12L; public static final Long ISSUE_GENERICEVENT_ID = 13L; public static final Long ISSUE_COMMENT_EDITED_ID = 14L; public static final Long ISSUE_WORKLOG_UPDATED_ID = 15L; public static final Long ISSUE_WORKLOG_DELETED_ID = 16L; public static final Long ISSUE_COMMENT_DELETED_ID = 17L; I may try to see if what looks like a trivial addition to the code would resolve this problem on a test instance (assuming I can get the plugin built), but someone in a position to build jira from source should be easily able to test out the above.

            Atlassian - this should be getting treated as a security vulnerability, not a bug to ignore. If an admin sets up a web hook with a narrow restriction on the content - this bug could be resulting in internal information being transmitted to the web hook destination that is explicitly not covered by the JQL definition. 

            Nathan Neulinger added a comment - Atlassian - this should be getting treated as a security vulnerability , not a bug to ignore. If an admin sets up a web hook with a narrow restriction on the content - this bug could be resulting in internal information being transmitted to the web hook destination that is explicitly not covered by the JQL definition. 

            Still appears to be the case in 7.4.4 at least. Got bit by this today when I deleted a project and it fired off web hook to a external server 10,000+ times. Huge additional load from all the web hook processing not to mention the impact on the targer server. 

            Nathan Neulinger added a comment - Still appears to be the case in 7.4.4 at least. Got bit by this today when I deleted a project and it fired off web hook to a external server 10,000+ times. Huge additional load from all the web hook processing not to mention the impact on the targer server. 

            Sylvia Law added a comment -

            Was this fixed in 7.2?

            Sylvia Law added a comment - Was this fixed in 7.2?

            CGM added a comment -

            We have this problem too and it's very annoying.
            Due to this Bug and some missing information in the worklog json (https://jira.atlassian.com/browse/JRASERVER-66134 please vote for it) we have to establish a filter on a "proxy" server that inspects every single WebHook before routing it to the target server.
            This generates a lot of traffic and server load in our environment.
            Please fix this or provide a workaround. Even editing a configuration file on the server will be ok for us.
            We need this very urgently.

            CGM added a comment - We have this problem too and it's very annoying. Due to this Bug and some missing information in the worklog json ( https://jira.atlassian.com/browse/JRASERVER-66134 please vote for it) we have to establish a filter on a "proxy" server that inspects every single WebHook before routing it to the target server. This generates a lot of traffic and server load in our environment. Please fix this or provide a workaround. Even editing a configuration file on the server will be ok for us. We need this very urgently.

            Aaron Freeman added a comment - - edited

            Same here. Should not be left broken for this long. We have a couple integrations that we would like to do but can't because JQL is skipped.

            Aaron Freeman added a comment - - edited Same here. Should not be left broken for this long. We have a couple integrations that we would like to do but can't because JQL is skipped.

            I'd like to add my voice to this.  Updated comment please?  Workaround?

            Stephen Welsh added a comment - I'd like to add my voice to this.  Updated comment please?  Workaround?

            Can we please get an update on this, or at least a supported and simple workaround for firing webhooks when an issue is commented on i a single project...

            Deleted Account (Inactive) added a comment - Can we please get an update on this, or at least a supported and simple workaround for firing webhooks when an issue is commented on i a single project...

            This appears to also affect jira:version_released events.

            Nathan Lowe added a comment - This appears to also affect jira:version_released events.

            We were able to get around this with custom scripting to parse the "Issue Updated" webhook trigger (which does respect JQL)

            Deleted Account (Inactive) added a comment - - edited We were able to get around this with custom scripting to parse the "Issue Updated" webhook trigger (which does respect JQL)

            Is this story dead? We are hoping to aquire the WebHooks in a new setup. Especially the comments section is important - but as it seems now, we are unable to use the JQL filter so ensure relevant triggers being activated?

            Jim Andersen added a comment - Is this story dead? We are hoping to aquire the WebHooks in a new setup. Especially the comments section is important - but as it seems now, we are unable to use the JQL filter so ensure relevant triggers being activated?

            DoD Support added a comment - - edited

            For anyone else that runs into this, pretty significant, problem. Here is how we worked around this issue:

             

            Note that this is written in `php` and is in a `laravel` app. If your environment is different, you'll need to convert the code but you should get the general idea.

            Also, this only works if your backend has access to your JIRA's REST API

             

            Comments in the code explain it pretty well but basically, add these parameters to the webhook, and the function will validate the JIRA request matches the intended targets only

             

            ?issue_id=${issue.id}&project_id=${project.id}&req_project_id=10300&req_issue_type_id=10601

             

             

            /**
             * Filters incoming jira web hooks requests for specified events to confirm that the event was
             * fired on a project and issuetype we care about. This is needed because jira webhook JQL only affects
             * issue events. This means that if you use comment events or others, they will fire and send the message
             * on EVERY COMMENT IN JIRA. This method acts as a shim to allowing us to dynamically filter those
             * requests on the server side before hitting the API and reject failing requests
             *
             * @link More events https://developer.atlassian.com/static/connect/docs/1.1.95/modules/common/webhook.html
             * @link Vote for a fix so this wont be needed https://jira.atlassian.com/browse/JRA-59980 JQL should do this.
             *
             * @example  Add the following query string to the webhook url in JIRA:
             *
             *           ?issue_id=${issue.id}&project_id=${project.id}&req_project_id=10300&req_issue_type_id=10601
             *
             *           issue_id=${issue.id}      Will add the current issue's id automatically
             *           project_id=${project.id}  Will add the current issue's project id, not present for comment events
             *
             *           req_project_id=10300      The project id we want the webhook to apply to (10300 in this case)
             *           req_issue_type_id=10601   The issueType id we want the webhook to apply to (10601 in this case)
             *
             *           This provides the backend with enough data to determine if the webhook message really matches
             *           the webhook we set up, regardless of Atlassian's half working system
             *
             * @param array $filteredEvents Array of event names that should be filtered. Defaults to all comment events.
             * @return bool True if the request was not a web hook or, was but passed the filter checks. Allow request.
             */
            public function validateJiraWebhook($filteredEvents = null)
            {
                $validRequest = true;
            
                $webHookType = $this->request->input('webhookEvent');
                $filteredEvents = $filteredEvents ? $filteredEvents : ['comment_created','comment_removed','comment_updated'];
            
                if($webHookType && in_array($webHookType, $filteredEvents)){
            
                    $projectId = $this->request->input('project_id'); // will be null comment events
                    $issueId = $this->request->input('issue_id');
            
            
                    $reqProjectId = $this->request->input('req_project_id');
                    $reqIssueTypeId = $this->request->input('req_issue_type_id');
            
                    if($projectId && $projectId != $reqProjectId){
                        // project id is present but doesnt match the one required by the webhook
                        $validRequest = false;
                    }
                    else{
                        $response = Jira::getIssueById($issueId, true);
                        if(!empty($response['errorMessages'])){
                            // there was some error getting the issue we'll take that to mean it's not an issue we care about
                            $validRequest = false;
                        }
                        else{
                           if( $reqIssueTypeId != $response['fields']['issuetype']['id'] ||
                               $reqProjectId != $response['fields']['project']['id']){
                               // issuetype or project dont match those required by the webhook
                               $validRequest = false;
                           }
                        }
                    }
                }
                return $validRequest;
            }
            
            
            
            

             
            And here is the implementation of `Jira::getIssueById($issueId, true)`
             

            /**
             * Get a JIRA issue by its issue ID (NOT issue key)
             * 
             * @param string $issueId The issue id of the issue to retrieve
             * @param bool $asArray If true, the issue JSON will be converted to an assoc array
             * @return mixed JSON string or associative array containing issue data
             */
            public static function getIssueById($issueId, $asArray=false)
            {
                $ch = curl_init();
                curl_setopt_array( $ch, array(
                    CURLOPT_URL            => config( 'jira.url' ) . '/rest/api/2/issue/' . $issueId,
                    CURLOPT_USERPWD        => config( 'jira.username' ) . ':' . config( 'jira.password' ),
                    CURLOPT_HTTPHEADER     => array( 'Content-type: application/json' ),
                    CURLOPT_RETURNTRANSFER => 1,
                ) );
                $response = curl_exec( $ch );
                curl_close( $ch );
                return $asArray ? json_decode($response, true) : $response;
            }
            
            
            
            

             

             

            DoD Support added a comment - - edited For anyone else that runs into this, pretty significant, problem. Here is how we worked around this issue:   Note that this is written in `php` and is in a `laravel` app. If your environment is different, you'll need to convert the code but you should get the general idea. Also, this only works if your backend has access to your JIRA's REST API   Comments in the code explain it pretty well but basically, add these parameters to the webhook, and the function will validate the JIRA request matches the intended targets only   ? issue_id =${issue.id}& project_id =${project.id}& req_project_id =10300& req_issue_type_id =10601     /** * Filters incoming jira web hooks requests for specified events to confirm that the event was * fired on a project and issuetype we care about. This is needed because jira webhook JQL only affects * issue events. This means that if you use comment events or others, they will fire and send the message * on EVERY COMMENT IN JIRA. This method acts as a shim to allowing us to dynamically filter those * requests on the server side before hitting the API and reject failing requests * * @link More events https: //developer.atlassian.com/ static /connect/docs/1.1.95/modules/common/webhook.html * @link Vote for a fix so this wont be needed https: //jira.atlassian.com/browse/JRA-59980 JQL should do this . * * @example Add the following query string to the webhook url in JIRA: * * ?issue_id=${issue.id}&project_id=${project.id}&req_project_id=10300&req_issue_type_id=10601 * * issue_id=${issue.id} Will add the current issue's id automatically * project_id=${project.id} Will add the current issue's project id, not present for comment events * * req_project_id=10300 The project id we want the webhook to apply to (10300 in this case ) * req_issue_type_id=10601 The issueType id we want the webhook to apply to (10601 in this case ) * * This provides the backend with enough data to determine if the webhook message really matches * the webhook we set up, regardless of Atlassian's half working system * * @param array $filteredEvents Array of event names that should be filtered. Defaults to all comment events. * @ return bool True if the request was not a web hook or, was but passed the filter checks. Allow request. */ public function validateJiraWebhook($filteredEvents = null ) { $validRequest = true ; $webHookType = $ this ->request->input( 'webhookEvent' ); $filteredEvents = $filteredEvents ? $filteredEvents : [ 'comment_created' , 'comment_removed' , 'comment_updated' ]; if ($webHookType && in_array($webHookType, $filteredEvents)){ $projectId = $ this ->request->input( 'project_id' ); // will be null comment events $issueId = $ this ->request->input( 'issue_id' ); $reqProjectId = $ this ->request->input( 'req_project_id' ); $reqIssueTypeId = $ this ->request->input( 'req_issue_type_id' ); if ($projectId && $projectId != $reqProjectId){ // project id is present but doesnt match the one required by the webhook $validRequest = false ; } else { $response = Jira::getIssueById($issueId, true ); if (!empty($response[ 'errorMessages' ])){ // there was some error getting the issue we 'll take that to mean it' s not an issue we care about $validRequest = false ; } else { if ( $reqIssueTypeId != $response[ 'fields' ][ 'issuetype' ][ 'id' ] || $reqProjectId != $response[ 'fields' ][ 'project' ][ 'id' ]){ // issuetype or project dont match those required by the webhook $validRequest = false ; } } } } return $validRequest; }   And here is the implementation of `Jira::getIssueById($issueId, true)`   /** * Get a JIRA issue by its issue ID (NOT issue key) * * @param string $issueId The issue id of the issue to retrieve * @param bool $asArray If true , the issue JSON will be converted to an assoc array * @ return mixed JSON string or associative array containing issue data */ public static function getIssueById($issueId, $asArray= false ) { $ch = curl_init(); curl_setopt_array( $ch, array( CURLOPT_URL => config( 'jira.url' ) . '/ rest /api/2/issue/' . $issueId, CURLOPT_USERPWD => config( 'jira.username' ) . ':' . config( 'jira.password' ), CURLOPT_HTTPHEADER => array( 'Content-type: application/json' ), CURLOPT_RETURNTRANSFER => 1, ) ); $response = curl_exec( $ch ); curl_close( $ch ); return $asArray ? json_decode($response, true ) : $response; }    

            DoD Support added a comment - - edited

            Yet another half working, crappily implemented JIRA  feature. The JQL feature is almost worthless under it's current implementation and no word since Feb. Nice work guys.....again.

             

            DoD Support added a comment - - edited Yet another half working, crappily implemented JIRA  feature. The JQL feature is almost worthless under it's current implementation and no word since Feb. Nice work guys.....again.  

            I just noticed that above the JQL textarea, the label says Issue related events, which probably means that the JQL is only meant to apply to events under the Issue heading below it. Ideally, it would be able to apply to the other headings as well, since (to my knowledge) there's no such thing as a worklog or comment that isn't also tied to an issue.

            But if this will not be fixed anytime soon, then I think the JQL section needs to reflect more clearly that it does not apply to Worklog and Comment events. Perhaps something as simple as clearer verbiage explaining this, or hide the textarea altogether when it does not apply.

            Deleted Account (Inactive) added a comment - I just noticed that above the JQL textarea, the label says Issue related events , which probably means that the JQL is only meant to apply to events under the Issue heading below it. Ideally, it would be able to apply to the other headings as well, since (to my knowledge) there's no such thing as a worklog or comment that isn't also tied to an issue. But if this will not be fixed anytime soon, then I think the JQL section needs to reflect more clearly that it does not apply to Worklog and Comment events. Perhaps something as simple as clearer verbiage explaining this, or hide the textarea altogether when it does not apply.

            I experienced this issue while setting up a Slack integration. We are a dev shop and have many clients, one wanted to get a Slack notification whenever we log work on their project. We set up the JQL to only trigger the webhook for their project, but it was sending them notifications for work logged on all projects.

            Deleted Account (Inactive) added a comment - I experienced this issue while setting up a Slack integration. We are a dev shop and have many clients, one wanted to get a Slack notification whenever we log work on their project. We set up the JQL to only trigger the webhook for their project, but it was sending them notifications for work logged on all projects.

              psuwala ΞΔ (Inactive)
              yokamoto Yuki Okamoto (Inactive)
              Affected customers:
              82 This affects my team
              Watchers:
              96 Start watching this issue

                Created:
                Updated:
                Resolved: