Document Upload using REST API fails in CS 16.2.7+ 4
Comments
-
strPayload = "type=144&parent_id=12489667&name=RESTUploadTestD31doc&file=\\PC1060\upload\camupload2.txt"
With objRequest
.Open "POST", strUPLOADUrl, blnAsync
.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
.setRequestHeader "OTCSTICKET", strOTCSTicket
.Send strPayload'spin wheels whilst waiting for response
While objRequest.readyState <> 4
DoEvents
Wend
strResponse = .responseText
End WithCS 16.2.7 using Content-Type "application/x-www-form-urlencoded"
?func=admin.sysvars "Upload Directory" is blank : New document successfully created
===========================
CS 16.2.8 using Content-Type "application/x-www-form-urlencoded"?func=admin.sysvars
"Upload Directory" is blank : "Error: File could not be found within the upload directory."
"Upload Directory" is set : "An illegal attempt was made to upload a document"
0 -
Hi Kyle and Mattyew,
Do you know if the intention of LPAD-66061 "Further strengthen file upload process security" was to purposely disable the use of a "Content-Type" of "application/x-www-form-urlencoded" when uploading a document via REST, and force the use of of a "Content-Type" of "multipart/form-data" instead ?
Regards
0 -
Hello Kyle,
I believe my Client is experiencing this exact issue, only not directly with the REST API but with the Brava HTML Viewer, which uses the REST API.
We get an error when we try to save a Published Rendition as a new version.
We get this error on all systems, NON-PROD, and PROD.We get it with and without an upload directory set. I've tried setting the upload directory to
\OPENTEXT\temp\
It still errors.Based on the comments in this thread, this error seems to have been introduced in patch 16.2.8
I have contacted support and logged ticket number 4170371.
Attached please find more info.
Regards,
-MC0 -
If you want to upload the document by CS REST API, you have to send the content within the request. Making the POST request for the file upload and sending a filesystem path will not work.
If you write a PHP script for uploading files from the client's filesystem, you will use the <input type=file> element and your script will be able to access the file content by $_FILES. You would either stream it to a subsequential POST request, or you would save it to a local directory and perform the request with it.
If you write a PHP script, which is supposed to upload files already present in the filesystem on the server, you need to put the file content to the POST request body. Not a path to them. You can use methods file_get_contents and file_put_contents. You can have a look at HttpRequest or curl.
Because files are usually bigger and binary, the content type "application/x-www-form-urlencoded" is unlikely to be used because the encoding would make the payload way bigger. The content type "multipart/form-data" is optimal for the best performance and you should use it in your CS REST API POST request for uploading files.
About LPAD-66061
The content type of the request body was not the reason behind changes made for LPAD-66061. The security issue fixed was preventing a file upload, which the client does not have fully under control. You should not refer to some file on the server with trust, if the client runs on other machine.
The uploading REST call was able to refer to a file path in the upload directory by the "file" parameter. It was not intended - the "file" parameter was supposed to carry the file content. The recognition of a file path on the server was mere a side-effect from code sharing among REST API and other CS components.
0 -
"Making the POST request for the file upload and sending a filesystem path will not work."
Hi Ferdinand,
Specifying a "Content-Type" of "application/x-www-form-urlencoded" and making a POST request for the file upload and sending a filesystem path most definitely DID work, up until it was disabled in 16.2.8.
Even Reiner Merz on his blog "The Joy of Content Server" has this as an example of how to upload a document via REST
http://pos2007.de/upload-a-file-to-content-server-using-rest-and-javascript
But then the functionality gets disabled and years old third-party integrations break.
I spend weeks looking at the issues for clients, to the point of even identifying the new lines of code in a decompiled 16.2.8 OLL file that are causing the issue.
If I comment out the new lines of code, recompile the OLL and try again, Viola - it works again.
Nothing I can find in the documentation about this new prohibition. Product Management says that nothing has changed and OT Support tell me they can't reproduce the issue.
What can I tell my clients ? That they were imagining it working before ?0 -
Let me clarify this statement:
Making the POST request for the file upload and sending a filesystem path will not work.
I did not mean, what will be decided to be done by the company. This is a forum for developers. I meant, what is technically feasible, in general. Once more:
Making the POST request for the file upload and sending a filesystem path has not specified and documented for CS REST API, and in general, it cannot work. The filesystem is not shared between the server and the client. That is why it is always reliable to supply the content in the request body.
I can give you an advice how to impelement the upload scenario.
0 -
I am sending the content in the body but occasionally I am getting "File could not be found within the upload directory." In a 16.2.9 environment what would be causing this error to happen randomly? It seems to happen 2 out of every 10 items.
0 -
Given the ratio: is it possible you're doing this via a load balancer & ~ 20% of your nodes are mis-configured?
@siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you
1
Categories
- All Categories
- 122 Developer Announcements
- 53 Articles
- 151 General Questions
- 146 Thrust Services
- 56 OpenText Hackathon
- 35 Developer Tools
- 20.6K Analytics
- 4.2K AppWorks
- 9K Extended ECM
- 917 Cloud Fax and Notifications
- 84 Digital Asset Management
- 9.4K Documentum
- 31 eDOCS
- 179 Exstream
- 39.8K TeamSite
- 1.7K Web Experience Management
- 9 XM Fax
- Follow Categories
