It's all about the answers!

Ask a question

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

Jyotsna Prasad (1920) | asked Oct 22 '20, 12:05 p.m.


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.

Matthias Buettgen commented Nov 06 '20, 8:39 a.m.
I assume HTTP POST requires the X-Jazz-CSRF-Prevent header to be set (more information about that can be found here

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

Jyotsna Prasad commented Nov 10 '20, 2:15 a.m.

 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
Kirk Woods (9158) | answered Oct 22 '20, 1:04 p.m.

 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).

Jyotsna Prasad commented Nov 05 '20, 5:03 a.m.

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.

Ian Barnard commented Nov 10 '20, 3:12 a.m. | edited Nov 10 '20, 3:20 a.m.

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 to post your answer.