Every time there's a new release of OpenMapTiles tiles, I get a 403 forbidden error from maptiler.download. If I wait a day or two, the download works, but I'm paying good money for these weekly updates, so how do I download them on time?
Looks like they fixed it by moving to a different CDN provider.
Related
I really don't know where to start on this one. I have configured Tiki to use the File Galleries feature. Every time I try to upload a file, I get an error. I have tried to for a couple of days to find the right Google search but have had no luck.
or
The error occurs using the admin account or a regular user account.
I am using Tiki 20.2svn.
We've been receiving alerts for two endpoints, GET {anonymous-user-id} and GET {anonymous-user-id}/permissions, and we've been unable to track down the source. There has been no change to any of our client or server code bases that call the Facebook API. In fact, I'm not even sure that we call these endpoints with our code. We allow users to join our site through Facebook authentication and that's about it. So I guess I need some basic (or perhaps a better adjective: stupid? apologies) questions answered for my own understanding.
After a Facebook Login, we call https://graph.facebook.com/v2.2/me to get the user's information. Is this somehow the cause of dashboard/analytics as the GET endpoints we're seeing reported?
What is the significance of the {anonymous-user-id}? Every API call we make for user information includes their authorization token, which seems to be strictly non-anonymous.
The Alert messages list the error codes 412 "User has not installed the application" and 100 "Invalid parameter". Is there any way to get more information on which users are encountering this problem? A user ID, IP address, User agent string, etc. Or which parameter being passed in is invalid?
Even more strange than the sudden ramp up of errors is that they seem to be dying down on their own without any intervention on our part. The counts go like this:
Feb 6th: ~300 errors per day, steady for as far back as we could observe in the dashboard
Feb 15th: Gradual ramp up to ~15k per day, roughly following exponential growth
Feb 20th: Growth between +50% and +100% per day, reaching 250k / day
Feb 22nd: Finally peaks at 315k / day
Feb 25th: Steady fall off to ~250k / day then rapid fall off down to 2k on Mar 1st
Could this be some kind of brute force attempt on user records in our app? The total API call count graph shows a similar bulge in requests, so successful calls (subtracting the error counts) seemed to stay flat during this time. Finally, the deeper metrics for logins by platform did not budge. We have not been able to find any client or server logs that report any increase in errored calls to FB APIs.
One finer point: yes our server code is still using graph version 2.2. I am executing the upgrade now, after having been thoroughly side tracked by this investigation. Our Desktop/mWeb code was upgraded to version 2.8 last year, and our mobile clients are being upgraded now as well.
Please let me know if there is anywhere else I can turn to get more information on this.
Regarding this API: https://developers.google.com/admin-sdk/email-audit/#accessing_account_information
I have been using the Admin SDK to retrieve login history for users in our Google Apps for Business setup. When I request individual users at a time, the request sometimes takes a few hours to process (in which the state is PENDING). However, when those few hours pass, I still get the login history that I need.
The problem continues as I begin requesting more users. We have around 750 users, and of those 750~ requests I made, 725 gave me an error after waiting ONE WEEK for my requests to be processed. Even worse, the ones that did not error out are still pending! Here is the response I get when I check the status of a request that errored out:
{'status': 'ERROR', 'adminEmailAddress': '***#etsy.com', 'requestDate': '***', 'requestId': '***', 'userEmailAddress': '***#etsy.com'}
This has got to be the flakiest and most unreliable API I have ever been unfortunate enough to work with. Requests can take anywhere from an hour to over a week to process, with no indicator of success in the mean time. Errors can also happen for no apparent reason, and no messages or explanations as to why.
It looks like this issue has been resolved by the Google Engineers. Try to run the calls again. It shouldn't be in pending more than the "normal" expected time. I just tried earlier, and I was able to export login info for my users.
I am trying for the first time to setup Paypal PDT and want to test it against the sandbox.
When I try to go to http://sandbox.paypal.com, I am getting forwarded to https://www.sandbox.paypal.com/hk/webapps/mpp/home , then I get an error generated by Tomcat (404).
Is that normal? Is this site to be used only though APIs and am I doing something wrong when opening it directly in a browser?
Under the FAQ, I can read that
I'm a non-U.S. developer. How does the site redesign affect me?
The current new REST APIs and PayPal Mobile SDKs are currently
targeted for the US market only. We will be rolling out in all
geographies over the rest of the year.
Is this a reason for that? Is the sandbox a part of the REST API?
I apologize for the inconvenience. We are working to fix this as soon as possible. In the meantime please try using https://www.sandbox.paypal.com/webapps/mpp/home as a workaround to log in.
Just wanted to follow up and to let you know that the 404 issue has been resolved.
Nope, it's broken for me to in the UK. I tried using a US proxy, and it seems that it's broken for everyone, no matter where you are.
Best to just sit it out and wait, although in the meantime I'm going to be using something else. Way to go, PayPal.
With the Graph API, I publish a story by POSTing to the /me/feed connection. I get back a success or an error result from Facebook. So far so good. Once in a while, the API takes a long time and the connection times out. In that case, I don't know for sure if the request succeeded of failed (i.e. maybe the request never reached Facebook, or maybe it succeeded and the result never made it back to me). How do you handle this situation?
More details:
I publish a lot of posts to Facebook and Twitter, so the timeout situation happens often. With Twitter, the solution is easy. If the request times out the first time, I simply try again. Twitter detects duplicates, so if the post was successfully published the first time, then I'll get a "duplicate status" error on the second request and I know that I don't need to retry any more.
But Facebook doesn't detect duplicates, so if I retry the publish request, I risk having two copies of the post published to the user wall, which is not nice. On the other hand, if I don't retry, I risk having the post not published at all. Thoughts?
I get back a success or an error result from Facebook.
Hmmm. When I post to the Graph API, I get back an error or the id of the post. I never see any success message. What SDK are you using around the API?
Once in a while, the API takes a long time and the connection times
out.
Usually when things are running slowly, it's due to the channelUrl not being specified. See https://developers.facebook.com/docs/reference/javascript/
It is important for the channel file to be cached for as long as
possible. When serving this file, you must send valid Expires headers
with a long expiration period. This will ensure the channel file is
cached by the browser which is important for a smooth user experience.
Without proper caching, cross domain communication will become very
slow and users will suffer a severely degraded experience.