POST /documents - 403 after initial success

[Justin_Horner]

I'm getting 403's after a successful (initial) attempt to archive a document, using the POST /documents endpoint[1].  When I run my code the first time, I get no errors and the document gets created without any issues.  However, all future attempts to go through the document creation APIs will always fail with a 403 error (message below) on the POST /documents endpoint.

403 with the error message:

User does not have rights to create document or when the user is trying to add read-only and hidden keywords without 'Access Restricted Keywords' privilege.

I looked in the forums and found this similar issue:

https://community.hyland.com/forum/threads/91882-sporadic-403-responses

but from what I can tell, I'm re-setting the FB_LB cookie on each new request (based on the data received in the previous API response)...as suggested here:

https://community.hyland.com/blog/posts/80436-how-to-use-the-api-server-within-a-load-balanced-envir...

Also, I'm not getting a 404 when calling the PUT /documents/uploads/{guid} [2].  I'm getting a 403 when trying to archive the document (after the PUT succeeds).  

One final note, on the first attempt, it always works.  But every subsequent attempt (using the same user, documentType, keywords, etc.) will always fail.

Any suggestions would be appreciated...I wasn't sure if creating a support ticket would be the best course of action but figured I would start here.

Thank you

1. Hyland API Portal (onbase.com)
2. Hyland API Portal (onbase.com)

[AdamShaneHyland]

Hi @Justin Horner ,

I'm guessing that this will be easier by engaging API support to review you code as without it, troubleshooting might be difficult.

However, here are some questions ...

- Could you provide more context on what you mean by the first attempt works and subsequent attempts fail? 

- Does this mean that you create a session and then iterate through multiple document uploads?

- What type of License are you using when you create the session?

- Does it work if you open a session, upload the document and then close the session prior to uploading a new document?

Thanks.

[Justin_Horner]

Hi Adam,

Thank you for your reply.  

> - Could you provide more context on what you mean by the first attempt works and subsequent attempts fail? 

Sure.  I'm making 8 API calls to do the full document upload process and in a brand new session, they all succeed.  

GET /document-types - Get all document types

GET /file-types - Get all file types

GET /keyword-types - Get all keyword types

GET /document-types/{documentTypeId}/default-keywords - Get the default keywords for given document type

GET /document-types/{documentTypeId}/keyword-type-groups - Get the default KTGs for given document type

POST /documents/uploads - Prepare the staging area to start the upload process

PUT /documents/uploads/{guid}?filePart=1 - Upload the data

POST /documents - Archive the document / finish the upload process

After the initial success, if I try to create another document (and rerun the 8 API calls), the final API call 'POST /documents' will always result in a 403.

> - Does this mean that you create a session and then iterate through multiple document uploads?

Yes, I'm just in the testing phase now.  So after having success creating a single document, I attempted to create another one (in the same session) and had these issues.

> - What type of License are you using when you create the session?

I believe it is the REST API Integration Toolkit.  I'm calling the IDP to get a JWT using an Admin level username and password

> - Does it work if you open a session, upload the document and then close the session prior to uploading a new document?

Yes.  If I restart the session, the POST /documents API call (and all other API calls) will succeed.

[AdamShaneHyland]

Thanks for the info @Justin Horner .

First though is related to the Cookie.Session.OnBase.Hyland cookie.  You will need to maintain that cookie in your requests to the Application Server.  This is how the users OnBase Core Session is maintained from one request to another.

https://sdk.onbase.com/rest/OnBase/Foundation23.1/document/programmers-guide/authentication.html#onb...

Additionally, you'll have to maintain the Access Token you received from the Hyland Identity Service in order to make requests to the REST API endpoints.  I'm assuming this is being performed correctly else all of the REST API endpoints would fail.

https://sdk.onbase.com/rest/OnBase/Foundation23.1/document/programmers-guide/authentication.html#usi...

Does it work if you open a session, upload the document and then close the session prior to uploading a new document?

I had asked about closing the session prior to trying to upload a new document ...

https://sdk.onbase.com/rest/OnBase/Foundation23.1/document/programmers-guide/authentication.html#dis... 

... but in your scenario it is failing when attempting to archive the document.  

https://sdk.onbase.com/rest/docs.html?product=OnBase&release=Foundation23.1&spec=document#operation/... 

This is before you would want to close the session.  However, since you are going to attempt to archive multiple Documents in a single session, there is no need to close the session until you completed the work you are looking to perform.

What type of License are you using when you create the session?

Yes, the REST API Toolkit license is requires to support the use of the REST APIs, but you also need a Client License.  Based on what you mentioned, you are using a default license which would be either a Concurrent Client or a Named User license, depending on the configuration of your user account.

https://sdk.onbase.com/rest/OnBase/Foundation23.1/onbase-administration/programmers-guide/license-he... 

I doubt this is related as you would run into other errors, but something to consider none-the-less.

For next steps, I would see what errors are logged under the ApiServer profile in Hyland Diagnostics. 

Best wishes.

[Justin_Horner · Accepted solution]

Figure out the issue, with help from this thread, REST API Request having issue updating keywords. (hyland.com)

I'm caching some of the results on API calls that are less subject to change and presumably have a long TTL.  It looks like the caching of one of those calls `GET /document-types/{documentTypeId}/default-keywords`, was resulting in the GUID I passed up in the `POST /documents ` to be considered invalid on the OnBase side.  Even though the default keywords didn't change, it sounds like the GUID associated with them is subject to change.  

Once I ignored the cache, and always fetched the default-keywords (in the document create chain), all subsequent calls to POST /documents succeed without issue.