In 99% of the cases, Cloudflare chokes on a base64 posted string coming from Javascript's toDataURL() resulting in a "502 Bad Gateway" error. In some rare occasions the post succeeds, but for most of the time the error appears.
How can I work around that?
Below the actual POST variables. Note that the base64 string has been shortened for demonstration reasons (otherwise it would be a very very long blob).
action=createCanvasImg&q=loremipsum.png&hash=cd09a136415d11542410f62eb89c6221&string=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAA
Update 1: The host is Mediatemple
Update 2: I posted a more general "Bad Gateway" question on Stackoverflow, so this problem may not be related to the specific case described above.
"disabled it" isn't an answer. If you didn't already contact CloudFlare's support team with full details please do that so we can actually investigate the issue.
Related
That's a quite puzzling problem. I've multiple MediaWiki installations. In this specific case: Version 1.34.
Now I can login to all of these MediaWikis. Everything works fine.
Now I can access all of these MediaWikis via API --- EXCEPT ONE. The strange thing is: All of them are configured almost identical. I even copied the configuration from one wiki where everything was working to the second wiki.
To be more precise. If I send ...
/wikiA/api.php?action=query&meta=tokens&format=json&type=login
... I get a very reasonable answer, e.g.:
{"batchcomplete":"","query":{"tokens":{"logintoken":"37ec2e690eeb48a10ac66b2ccbca2b576000f9f4+\\"}}}
If I send ...
/wikiB/api.php?action=query&meta=tokens&format=json&type=login
... I get the following answer, e.g.:
{"error":{"code":"readapidenied","info":"You need read permission to use this module.","*":"See http://xxx.xxx.xxx.xxx/wikiB/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."}}
This can be reproduced using any web browser.
Q: What could be the reason that on this wikiB I even can't access the normal login module? It can't be the configuration. It's almost completely identical. It can't be the source code. I ran a diff on the PHP files and found no significant differences. What could be wrong here? It seems it must be something with the database. But how do I approach this? Does anyone have an idea? I would appreciate it very much if you could help!
I analyzed the data base: No difference. I did more research using google: And found a bug report.
It's a bug in MediaWiki. They provided an official software release with THAT kind of bug.
It turnes out there is a 1.34.0 version and a 1.34.1 version. My WikiA has 1.34.1 while WikiB had 1.34.0. After copying this one single file includes/api/ApiQuery.php from WikiA to WikiB and everything worked fine.
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/580097/
Background: I'm trying to log into an HTTPS site with my valid credentials, navigate to a page that has a frequently updated list, and then scrape the list.
I was using code someone else wrote, which worked until a few weeks ago. I am new to this, but even i can see that the code was not very good, so i am trying to rewrite.
First I log into the site and create an tunnel. Then I move to the page where my list is and grab the list, etc.
Here's what's weird. The login fails every time, until I turn on Fiddler. With Fiddler running it succeeds every time.
Any idea about why this would happen and how to fix?
Many thanks.
I got it working!
For anyone who finds themselves in the same situation (I've seen a number of posting of similar questions - but the answers hadn't worked for me, so I expect I am not alone), I eventually saw that I needed to set the security protocol to TLS. The specific syntax I used was:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
The setting needs to be specified before the Httpwebrequest get or post event occurs.
If you have a similar problem, I hope this helps.
I had an invalid "User-Agent" header. It contained invalid characters (ä, ö, ü).
Is it a bad practice when writing a RESTful API to use custom HTTP response codes like:
417 - Password not provided
418 - Database error
I see there is a list of standard HTTP response codes. However, from looking at Twitter's API, it appears Twitter tries to return standard HTTP response codes when available but their own error codes when they cannot align the error with a standard HTTP response (correct me if I am wrong).
What is the best practice for response codes (especially for errors) while creating a RESTful API? Any comments on the practice which Twitter chose to use?
Yes, yes it is bad practice... mostly.
One of the tenets of REST is that you work with the underlying protocols, as such HTTP has already defined a good set of response codes.
However, not every situation is catered for perfectly. Take Twitters 'arrest your calm', that response code is used when the request was valid, it simply is not being handled due to too many request being made.
I don't see another response code that quite matches that. The other two options are to either lie, and tell the user the request failed for some other response or give a generic 400 'you did something bad' (then in the body give a more detailed explanation).
I would favour using the generic X00 codes, and use headers or the body to add more detail about what actually went wrong. This at least conforms better to standards and less brittle.
Note though, it is terrible to take an existing error code, and repurpose it. 404 should always be used only for 'not found' errors. Don't start using it because the user can't make that request at this time of day.
The problems in using your own codes are:
The code you choose may get officially assigned to something completely different, and that could break your API in the future. (e.g. compare a 306 with a 301)
Intermediaries don't know what your code means, so cannot optimise anything. The internet works so well because it is a distributed system, not an end-to-end system.
There are generic responses for each category, x00, which should be used if nothing better exists.
You can send your own more specific error code in either the response body or (not as good) a response header. There should be no need to make up your own codes. If you have truly found something that would benefit the rest of the internet and no-one else has thought of until now, you can always submit an Internet Draft to the IETF (this is fairly easy to do).
I would not hold up Twitter as a shining example of good internet practice, though. :)
Good Morning (morning in Oregon). I am going through the Intuit Developer Testing process and continue to get errors when attempting to render the PayPage with ticket and opid strings that were provided to me in the previous step. To prevent links in this message, I separated the https:// from the remainder of the url.
Using:
Firefox browser (internet explorer for intuit is under construction?)
Windows XP Professional version 2002 service pack 3
ORIGINAL DATA FROM PREVIOUS STEP AND VARIABLE URL FOR RENDER PAYPAGE STEP:
Ticket=JiRr77+9RA7vv73vv70JdVcrYWnvv71b77+977+977+9Cu+/vW7vv70a13061215442877+9DhprATIXA++/ve+/vXfvv73vv73vv73doO+/vXDvv70nHWTvv73v
OpId=77-977-9VO--vX130612154428Dvv73vv70ZHyo7
PTC url with variables: (https://) paymentservices.ptcfe.intuit.com/checkout/terminal?Ticket=(X)&OpId=(Y)&action=checkout
When I DO NOT encode the url, I get the Secure Payment Processing window with the following message: Transaction Not Processed - Our system is currently facing some intermittent problems. Please try again in few minutes.
Unencoded url used:
(https://) paymentservices.ptcfe.intuit.com/checkout/terminal?Ticket=JiRr77+9RA7vv73vv70JdVcrYWnvv71b77+977+977+9Cu+/vW7vv70a13061215442877+9DhprATIXA++/ve+/vXfvv73vv73vv73doO+/vXDvv70nHWTvv73v&OpId=77-977-9VO--vX130612154428Dvv73vv70ZHyo7&action=checkout
When I encode the ticket portion of the url only and then paste the results into the url, I get the Transaction not processed screen again.
Resulting url w/ encoding of ticket only:
(https://) paymentservices.ptcfe.intuit.com/checkout/terminal?Ticket=JiRr77%2B9RA7vv73vv70JdVcrYWnvv71b77%2B977%2B977%2B9Cu%2B%2FvW7vv70a13061215442877%2B9DhprATIXA%2B%2B%2Fve%2B%2FvXfvv73vv73vv73doO%2B%2FvXDvv70nHWTvv73v&OpId=77-977-9VO--vX130612154428Dvv73vv70ZHyo7&action=checkout
When I encode the entire original url I get the QBMS Error Page and [Intuit Logo] - Not Found - Error Code 404
Encoded url entire resulting url encoded:
(https://) paymentservices.ptcfe.intuit.com/checkout/terminal%3FTicket%3DJiRr77%2B9RA7vv73vv70JdVcrYWnvv71b77%2B977%2B977%2B9Cu%2B%2FvW7vv70a13061215442877%2B9DhprATIXA%2B%2B%2Fve%2B%2FvXfvv73vv73vv73doO%2B%2FvXDvv70nHWTvv73v%26OpId%3D77-977-9VO--vX130612154428Dvv73vv70ZHyo7%26action%3Dcheckout
I feel I have tried everything and I do not know what else to try. I am under a deadline to get this done. I tried everything suggested in the one thread I found where this issue was discussed. But I noted there was never really an answer on that thread. I hope you can help me out. :)
I just had this problem, and found the cause. They want the value for Ticket and OpId url encoded. In most scripting languages like PHP, that will turn spaces into "+" symbols. They then expect those plus symbols to also be url encoded. So, in PHP if you do something like this to the Ticket and OpId and any other parameters you pass it will fix the problem (this assumes $ticket and $op_id are already set):
$ticket = str_replace('+','%2B',urlencode($ticket));
$op_id = str_replace('+','%2B',urlencode($op_id));
While trying to debug my openid implementation with Google, which kept returning Apache 406 errors, I in the end discovered that my hosting company does not allow to pass a string containing "/id" as a GET parameter (something like "example.php?anyattribute=%2Fid" once URL encoded).
That's rather annoying as Google openid endpoint includes this death word "/id" (https://google.com/accounts/o8/id) so my app is returning 406 errors every time I log in with Google because of this. I contacted my hosting company who told me this has been deactivated for security purposes.
I could use POST instead, for sure. But has anyone got an idea why this could cause security problems ???
It can't, your host is being stupid. There's nothing magical about the string /id.
Sometimes people do stupid things with the string /id, like assuming no one is going to guess what follows, so that example.com/mysensitivedata/id/3/ shows my data because my user has id 3, and being the sneaky sort, I wonder what happens if I navigate to example.com/mysensitivedata/id/4/, and your site blindly lets me through to see someone else's stuff.
If that sort of attack breaks your site, no amount of mollycoddling by your host will help you anyway.
One reason a simple ID in the URL could be a security concern is that a user could see their ID and then type another one in, such as if its an integer they may select the next integer up, and potentially see another users info if it is not protected.