server error when trying to refresh mules

[Robonau]

when trying to refresh mules i get
loading data
server error
full response:{"count":0,"created":"2017-08-13T20:46:20Z","lang":"en-GB","results":null}

[Zeroeh]

Deca limits the rate at which you can refresh char/list now. Since the actual IP that sends the request is yahoo, nobody will be able to refresh.

[zaqxswcdevfrbgtnhy]

What is the maximum rate they set?

[zaqxswcdevfrbgtnhy]

It'd be nice if there was some way to make muledump not have to send the requests through the central yahoo IP, as well as some rate limiter for how quickly it attempts to refresh the accounts.

[Zeroeh]

You get 9 refreshes every minute. Currently working with some buddies to create a xml to json converted so we don't need yahoo.

[zaqxswcdevfrbgtnhy]

Issue 114 may have some relevance. Thank you for working on a fix.

[zackpollard]

So I've spent a bit of time looking into the code for this to see if I can PR a fix. I'm running into some issues (I don't write javascript much so if people know an immediate fix to the problem i'm facing please let me know).

I have removed the call to the yahoo API and instead make the call directly to the realm API and convert the XML to JSON locally instead of using the yahoo API. Now the problem with this is the AJAX request that was being made was using the jsonp datatype, which gets around any kind of CORS (Cross Origin Requests) issues. When using XML data type, it applies CORS rules, and therefore you have to send the Access-Control-Allow-Origin: * header along with the request. If you don't send this, then the browser won't allow the response to be processed. If you do send this, then it triggers the browser to send pre-flight checks in the form of an OPTION request to the realm API. The issue with this is that the realm API rejects OPTION requests as it doesn't support that request type, therefore the pre-flight check fails and the request doesn't go through. I believe this may be the reason the yahoo API was being used in the first place, as it negates these issues. I can't see a way around this currently, so unless somebody has an idea on how to get around this, we could have a bit of a problem with muledump going forwards unless realm reverts this change...

Could be fun times ahead xD

[zackpollard]

@Zeroeh just read that you're working on a fix, XML to JSON converters exist already but how do you plan to avoid the CORS issues when you make the XML request to realm?

[Zeroeh]

@zackpollard It doesn't have to be written in JS. Just sayin'. And what xml request? It's an http request.

[zackpollard]

@Zeroeh Doesn't matter what it's written in, it's the browser that does the CORs checks. It's an HTTP request with an XML response type, which is subject to CORs. The reason that the current one is not subject to CORs is because it uses JSONP which is simply padded json, but this is let through without any kind of checks for where the origin of the request was. Calling the realm API directly we can only get an XML response, which means we will be subject to CORs, and the realm API doesn't respond correctly to the CORs checks so everything fails.

[Nillad]

if it gives you 9 refreshes a min should it refresh 9 of my mules before giving me server error or let me individually refresh at my own pace... it doesnt let me refresh any of them

[Zeroeh]

@Nillad That's because there are thousands of people trying to refresh through one ip

[Nillad]

I see.. is there some way to make my own ip for it to refresh through?

[Zeroeh]

@Nillad That's more or less what we're trying to fix here :P

[Nillad]

This is the issue right?
}
$.ajax({
dataType: 'jsonp',
url: 'https://api.github.com/repos/thestdman/muledump/tags',
complete: function(xhr) {
xhr.done(checkupd);
}

[Zeroeh]

@Nillad Nope, it has to do with everyone using the yahoo query server.