Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-64725

/p4/event endpoint doesn't work with the same permission scope as p4/change

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • Jenkins 2.263.2
      P4 plugin 1.11.1

      Hello,

      I am struggling with installation of additional P4 trigger for multibranch pipeline job.

      We have anonymous user with job build and read permissions granted. so curl without any user and pass onto p4/change works perfectly fine, pipeline jobs are triggered, poked, probed, built.

      When it comes to use a curl on the p4/event, for multibranch pipeline job, it throws a 403 No valid crumb was included.

      In the Pipeline job description, around Server authentication, one can find that manually providing CRUMB is not needed Deprecated as of 1.8.10 (CRUMB support is embedded). Shouldn't be a case also for p4/event end point?

      I am also guessing, when we would try the manual CRUMB obtaining, modern Jenkins would push as to use user/api key flow as well. That's not generally bad to follow up with both triggers to be properly secured, but initially I would like to make them work as-is, unless there is no other way.

      Thanks! Maciej

          [JENKINS-64725] /p4/event endpoint doesn't work with the same permission scope as p4/change

          Karl Wirth added a comment -

          Hi mmatczak - I'd like to get some more detailed information about this so can you please send an email to support@perforce.com including the following data:

          (1) Examples of the exact URL you are trying to call.

          (2) Screenshots from Manage Jenkins showing how you have setup your security.

          (3) A screenshot of the multibranch job.

          Thanks in advance.

          Karl Wirth added a comment - Hi mmatczak - I'd like to get some more detailed information about this so can you please send an email to support@perforce.com including the following data: (1) Examples of the exact URL you are trying to call. (2) Screenshots from Manage Jenkins showing how you have setup your security. (3) A screenshot of the multibranch job. Thanks in advance.

          Karl Wirth added a comment -

          Thanks to mmatczak for highlight this and thanks for the extra data. Agree that if you try to trigger p4/event without authorizarion it complains that the crumb is not valid when using .

          HTTP ERROR 403 No valid crumb was included in the request
             URI:   /p4/event/
             STATUS:  403
             MESSAGE: No valid crumb was included in the request
          

          Example Security Setup:

          Test reproduction code:

          P4_CHANGE=1234
          URL=http://My_Jenkins_URL:8080
          P4_PORT=My_P4D_Server:1666
          
          curl --header 'Content-Type: application/json' \
               --request POST \
               --data payload="{change:${P4_CHANGE},p4port:\"${P4_PORT}\",event_type:\"UPDATED\"}" \
               ${URL}/p4/event/
          
          

          Providing "--user USERNAME:API_TOKEN" works around the problem but this does not match the p4/changes endpoint behavior which works unauthenticated when using the above permission strategy.

          In my testing providing a CRUMB does not solve the problem.

          Marking as priority "A" bug for review by developers.

           

          Karl Wirth added a comment - Thanks to mmatczak for highlight this and thanks for the extra data. Agree that if you try to trigger p4/event without authorizarion it complains that the crumb is not valid when using . HTTP ERROR 403 No valid crumb was included in the request URI: /p4/event/ STATUS: 403 MESSAGE: No valid crumb was included in the request Example Security Setup: Test reproduction code: P4_CHANGE=1234 URL=http: //My_Jenkins_URL:8080 P4_PORT=My_P4D_Server:1666 curl --header 'Content-Type: application/json' \ --request POST \ --data payload= "{change:${P4_CHANGE},p4port:\" ${P4_PORT}\ ",event_type:\" UPDATED\ "}" \ ${URL}/p4/event/ Providing "--user USERNAME:API_TOKEN" works around the problem but this does not match the p4/changes endpoint behavior which works unauthenticated when using the above permission strategy. In my testing providing a CRUMB does not solve the problem. Marking as priority "A" bug for review by developers.  

            Unassigned Unassigned
            mmatczak Maciej Matczak
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: