Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Updating DNG attribute value with POST request using widget throws 403 Forbidden Error

 Hello,

I am trying to update a DNG artifact attribute within a module using a widget, but while updating it through widget, I get "403 Forbidden" Error after the POST command is executed in the background.

Steps in background :
1. Change set is created and widget is hosted in personal global stream.
2. Widget triggers a GET request for each artifact, stores the response including the "ETag" header value.
3. It forms relevant content to be updated in the artifact as response body, appropriate headers including "IF-Match" with above Etag value is added and POST request is executed.

After above steps, the attribute is not updated and it throws "403 Forbidden Error" in background.

The same logic is applied in java application and it works fine without any such error.

Could you please help?


Thank you.

0 votes

Comments
I assume HTTP POST requires the X-Jazz-CSRF-Prevent header to be set (more information about that can be found here https://sleroyblog.wordpress.com/2013/04/09/querying-rqm-40-through-oslc-and-rest-api/#cs_create_thru_rest).

Anyway, did you consider using the RM Client Extension API?

 Hi Matthias,


 Can you please guide me how to fetch JSESSIONID in javascript from GET response headers so that I pass it as value to X-Jazz-CSRF-Prevent header?

Thank you.



One answer

Permanent link

 A 403 can be caused by a number of things, but in this case it is likely because you are doing a POST (create) when you should be doing a PUT (update).

0 votes

Comments

Hello Kirk,


While doing PUT, I get error "PUT <requestURL> 412 (Precondition Failed)" .
I have verified the headers and all relevant headers are present but I am still unable to update DNG artifact attribute.

Could you please guide me?

Thank you.

412 is closer to working than 403 :-) I've seen 412 when a) the etag from the GET wasn't copied correctly into the If-Match header on the PUT, or b) when the etag in If-Match isn't valid any more because an update had been made since the GET, so the old etag from my GET was no longer correct. Don't modify the etag at all, simply copy from etag header into if-match header. As you say you're working in a changeset the second shouldn't apply - if you weren't in a changeset and if someone else had changed the artifact since you collected the etag, then the logic of, perhaps, retrying is a bit perilous because your update might overwrite the other update, so it may be best to stop and let the user decide what to do.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,952

Question asked: Oct 22 '20, 12:05 p.m.

Question was seen: 2,043 times

Last updated: Nov 10 '20, 3:20 a.m.

Confirmation Cancel Confirm