Earlier today this error started to come up which I have not seen before since using Yahoo OAuth for several years now.
OAuth oauth_problem="OST_FORMAT_ERROR"
Any ideas on how to fix this? There is no documentation anywhere about it and a Google search comes up with almost nothing for OST_FORMAT_ERROR.
This was a regression in Yahoo's code. They fixed it a few hours later.
It was only affecting clients using OAuth 1.0 (they are discontinuation support for it)
You should upgrade your code to use OAuth 2.0
Related
We've been doing some research for many hours already.
The first solution that appears everywhere (other StackExchange questions too) is using third-party service SendGrid.com and sometimes in conjunction with Zapier, but that's not the approach we are wanting to implement.
For sending without third-parties in the middle, the first solution that seemed viable was "Firebase Triggers", which was anounced on Google I/O 2014 but never came to life and seemingly was merged into Google Cloud Functions which is still in Alpha.
I'm pretty sure I had seen the solution almost a year ago in a link on the FireBase blog, but the only post that seems to have existed upon that matter is now empty.
We've never worked before with GCP, but our logic tells us this matter should be solved (inside Google) using with another GCP existing API, and the Mail API is apparently the correct one, but there seems not to be any way our Firebase Web App could make the request.
Could anyone (preferably with GCP experience) please explain what's the situation here, and how does Google expects it's FireBase developers to send emails to their clients?
Firebase Functions
As gracefully stated by #ajostergaard, TODAY Google has announced its much waited Google Cloud Functions, but precisely for Firebase they've implemented their own specific Firebase Functions which substitutes the Triggers shown in conferences since Nov. 2014 (more than 2 years ago!) and mentioned in Firebase groups .
This is an example link that explains exactly how to do what is asked in this question:
Sending emails from Firebase (FINALLY! and just in time for our WebApp)
I don't quite know if my question fits here, but I don't know who else to ask...
I recently upgraded my socialengine plugin, which should allow me login to my site via Facebook. The reason I had to upgrade it because it didn't work anymore since Facebook changed the API (API-KEY --> APP-ID). I think this was around 2010!?
Now I bought the latest version of the plugin, just to find out that it still requires an API-KEY. Their support told me that it's not supported anymore because the version of my CMS is not supported anymore (nice to find that out after paying for it). However they offered me to make the plugin work for me, if I am willing to pay, with a hint that due to the massive changes in the API it will need a lot of work.
To come to my question: Have there really been such massive changes? Has a task like logging into a site via Facebook become that different? I am coming from a programming background, may i be able to fix this myself?
The Facebook API is constantly evolving with breaking changes all the time. 2010 is a long time ago for the FB API, so it sounds likely it'll be a lot of work updating the plugin (if the required API features are even still available!)
I am about to start a new project in the Google Analytics API & PHP.
I read that Google Analytics will be deprecating XML v2.3 and v2.4 and in 6 months time, so aparently you will only be able to use v3 and retrieve information in JSON format.
http://analytics.blogspot.com/2011/12/introducing-google-analytics-core.html
My question is the following: Does this means that GAPI class won't work any longer? Anyone who has used this class before can help me answering this question ??
http://code.google.com/p/google-api-php-client/
In that case, any alternative suggestions of PHP classes that do the same thing.
Thanks so much
I've been using GAPI for a while now. And I can say with some confidence that yes it will break, if not due to XML it will be due to some other change google makes.
Having said that GAPI is the best solution I have found out there for php. It does break every 6 months to a year, usually needs one or two lines changing to fix. But GAPI is pretty popular so at least you know when your clients are calling saying analytics is throwing errors at them, you wont be the only dev tearing your hair out.
9 times out of 10, by the time I've got a problem someone else has found the fix - which is nice.
There are a few other php options out there but GAPI seems to be the most popular (usually the best way to go imho)
My approach is to build an analytics summary in the dashboard and provide a link to google analytics underneath so clients can see the full data or go there when GAPI breaks. I have been putting all my sites on the same modular system for a while now. I keep GAPI as a library in my admin layout module, this means I can make the fix once and roll it out to all my sites without too much drama.
In summary, use it but expect it to break - that way you wont be disappointed when it does.
Does anyone know what tumblr is written in? I have been trying to figure it out.
It's PHP...
http://www.marco.org/55384019
spiteshow:
I wonder if the Tumblr guys are using a framework or if it is all home brew.
Both: it’s a homebrew framework to add MVC structure and a useful secondary function library to PHP 5 that we started in 2006 and have constantly evolved into a very finely tuned framework for our needs. The same framework runs some of Davidville’s former consulting-client sites as well as all of my personal sites and projects. It’s not available publicly anywhere, but we may release it in the future.
The lead developer's blog features a lot of PHP-related material, and Tumblr was advertising for PHP developers a while ago. This isn't strong evidence, but it's possibly indicative and it's the best I could find.
Here's the full stack as of 2013.
"We're a LAMP based stack (Linux Apache MySQL PHP) with Scala for our many services. Other pieces of tech we use currently in production are Memcached, Varnish and Redis."
http://smcdermott.tumblr.com/post/46847264498/what-language-is-tumblr-written-in-all-php
I just logged in to my account and added the index.php and it worked, so it must be php.
http://www.tumblr.com/dashboard/index.php
For a new J2EE Facebook Connect project, do you recommend:
restfb (http://www.restfb.com), or:
Facebook Java API
(http://code.google.com/p/facebook-java-api)
The requirements cover pretty much everything supported by Facebook Connect.
Completeness, ease of use, stability, etc are important. But what matters the most to us are the odds that the selected library flourishes and ends up being the winner, if there is such at thing.
Thank you.
With the new OAuth2 based authorization flow and the Graph API, the amount of "work" an SDK does has been greatly reduced. I'd suggest that you choose a library that does not try to provide very high level abstractions, and instead understand and leverage the fact that you're making HTTP API calls (for instance, for parallelization of HTTP requests). We recently released an Android SDK which while not related to your question, may be a good point of reference.
For full disclosure, I mavenized RestFB and have commit rights to the project. That said, I was in the same position some time ago, needing some Java library for working with FB's Graph API. Originally, I tried out facebook-java-api, but it didn't support all the newer APIs. I peaked into the code at the time and saw some inherent inflexibility that made it overly complicated to do what I needed so I looked around for alternatives. In all fairness to facebook-java-api, perhaps I just caught them at a bad time (around 6 months ago, there were only minor updates to 2.x and no 3.x in sight at the time. I see they've released 3.0.2 recently).
Anyhow, I then found RestFB. What I liked about it from the very beginning was how clean and extensible the code was and that it didn't require any extra dependencies. The basic Graph API objects are built-in and it's very simple to create new ones. There were one or two minor things that didn't work out of the box, so I opened issues and Mark Allen, the founder of the RestFB project, seemed pretty responsive with fixing them so I stuck to using it. More recently, I contributed Maven build to the project since I was keen on seeing the RestFB libs on Maven Central to make it easier for myself to use them.