Upload screenshot to social media endpoints

he guys …

i want users to be able to post screenshots of my app on a social media account i’ve set up. i’ve checked out twitter and imgur so far which use api’s providing endpoints for uploading images. i do:

pc.http.prototype.post(‘endpointforupload’, base64image, {options including authorization headers}, callback) …

my problem is the callback. which is:

function(err, response){

while the response i log turns out undefind examining console shows me that there is indeed a response containing among other information a link to the uploaded image. so how do i retrieve the response correctly? is the problem about response types?

the response i see in the console/network looks like this:

{“data”:{“id”:“PpAJH1c”,“title”:null, …
ending with …

Hi @rtz23 , I think you are close.

If you press the little arrow when your object prints out in the console you can see the expanded form:


From there you can pinpoint the exact location of the link. Unless the response is a JSON string (simple text), then before printing it in the console run parse to get an object out of it:

const obj = JSON.parse(response);

he @leonidas … thanks. i do use this feature alot actually to find anything … but the response i get from the callback is undefined so there’s nothing to pinpoint. so i assume it is a json string then… will try that …

If it’s undefined then most likely the server isn’t sending a response back.

You can check the network tab in the browser console, under XHR to debug this request. It will be easier to see there if there is something wrong (e.g. the response ID returned).

You can find more about that in the Chrome browser docs:

@leonidas yep i also thought that there is no response but :

there it is … exactly what i need … there’s the link to my file as described in the api … but it does not reach my callback somehow …

Ah, I can see there are two requests for image, maybe is the case the first one is an OPTIONS request sent before POST?

If that the case the response callback may fire twice, and the first time it’s empty. That happened to me in the past (the cause is a long story: What Is That Options Request Before Post And Cross Origin Resource Sharing · Nikhil Soni).

Can you check if your console.info statement is firing twice?

it does indeed … the first one is labeled ‘preflight’ for a moment and afterwards the second one pops up. preflight is described in the api … so it could be as you say… i’ll check that .

1 Like

@Leonidas console info is not firing twice … but as described in the article it is exactly what happens. the first image request in network says
‘failed to load response data’ … still not sure what the solution is …


after thinking about it it seems obvious that it’s still a cors issue and i need to adjust the authorization header accordingly. i’ll post the solution when i’ve figured it out.

1 Like


so let’s close this one. i don’t see a possibility for me to get this done. actually posting base64 on plattforms like twitter or imgur seems not that much of a problem if you’re able to use node.js and some libs that will handle oauth exchange of tokens for propper authorization. doing this without kinda exceeds my salary class.

1 Like

Are there none that have a UMD version so that you can use it directly in browser?

he @yaustar

can you further elaborate … google said UMD is a universal module definition,- way to make scripts work in different environments…which is as of now everything i know about it. was investigating setting up a node js server… i sucessfully managed to do communication between my app and the server … but will need to find go deeper today … so if there’s a smarter and less complicated way i’d be super happy.

what i need in the end is a link to the screenshot so i can just use a twitter intent for sharing it…

Ah sorry, I thought you meant you needed node modules to build out the client, I didn’t realise you needed a node.js server

@yaustar @Leonidas

he … so i almost made it work. i installed myself a node server on aws elastic beanstalk using express & cors as well as some packages that handle twitter.

worked well for a moment locally and on server. but i started to get CORS issues. realized that the bug was somewhere else and now the problem seems extremly peculiar to me.

i initially used the screenshot script from here:

the problem with this was that transparent materials were all messed up. i admit that i didn’t spend any time to understand the screenshot script. though i found out that using the following gave me a propper screenshot without any transparency issues:

var canvas = document.getElementById('application-canvas');
var dataURL = canvas.toDataURL('image/png').split(',')[1];

now here’s the thing - if i use the screenshot script i get the opacity glitch but i can actually post it through my server without any issues to twitter. if i just use the above code snippet to get the base64 image with correct visuals it’s giving me a cors error - but only from server while it works locally.

this is how i POST to my node server:

TwitterBot.prototype.initialize = function(){
    this.app.on('screenShotter:ready', this.upload, this);

TwitterBot.prototype.upload = function(file) {
	var xhr = pc.http.post('https://myTwitterBot.de:3000/api/image', {'image':file, 'myText':'gotta try another line'}, {
	'Content-Type': 'arraybuffer',
	responseType: "text"
	}, function (err, response) {

so it seems it makes a difference where the base64 data comes from while logging them both ways produce something that looks quite like base64 is supposed to. from what i’ve read i thought 'Content-Type': 'arraybuffer' should be something different but in pc docs i found that this would be the appropriate content type to transfer base64 … i hope i described it comprehensably. will be happy for every hint or direction.

1 Like

From Twitter: Media Best Practices | Docs | Twitter Developer Platform

  • The image passed should be the raw binary of the image or binary base64 encoded, no need to otherwise encode or escape the contents as long as the Content-Type is set appropriately (when in doubt: application/octet-stream).

Maybe try application/octet-stream

1 Like

@yaustar not quite … i use .split(',')[1]; to get rid of mime types… but thanks, helped me still since i started to look into the base64 data again i discovered that there’s a ‘client_max_body_size’ when you upload to aws … and also found logs that statet this is a problem. i think i’ll be done when i fix it.