I've thought about this a lot myself as well, and haven't really came
up with a proper solution either.

- You can try encoding all of your code with zend encoder and hope
that nobody decodes it.
- You can use your own server as a service which sends all requests to
twitter. (This would be my solution)
- You can simply not care at all about the keys - after all, there is
(imo) no real threat in exposing them to customers.
- You can let them use the new Twitter extension for open source
twitter clients - although I am not sure whether it's ready yet.


On Aug 1, 1:49 am, Michael Babcock <mjet...@gmail.com> wrote:
> So, I think the solution has to be that the user downloads my app,
> installs it on their site, then registers my app as their own app with
> dev.twitter. After which, they will receive their own key & secret
> pair. They will then input their key & secret pair into my app which
> is living on their site, stored in some configuration file or database
> settings table.
> This way I don't distribute my secret. They will have to store their
> own key & secret pair, but this wouldn't be different than a site with
> its own proprietary solution. The only stick point is that I will not
> get any branding rights on their posts/tweets, as they will have
> registered the app as their own and will be in control of the post
> branding.
> The other option is to host a tweet service somewhere in the cloud. My
> app, installed on their site, would point to the service and they
> would have to grant permission to the service to make the tweets to
> their accounts. I like this second solution because it seems cleaner
> for the end user to set up and get running. However, this would mean
> that I would then be responsible for maintaining a service. And
> frankly, that sounds like a drag on resources.
> These two are the best solutions I can figure given the circumstances.
> Normally, I would wait for Twitter to get this sorted, however, I
> don't want to risk disappointing my user base when the August 16th
> deadline rolls around.
> Does these solutions sound viable or am I all wet?
> Pros, cons, alternatives?
> Thx.
> On Jul 27, 7:18 am, Decklin Foster <deck...@red-bean.com> wrote:
> > Excerpts from Michael Babcock's message of Mon Jul 26 19:28:15 -0400 2010:
> > > So, I after spending the day looking through documentation,
> > > developer's discussion and testing various OAuth code bits, it is my
> > > understanding that there is no secure OAuth solution for open-source
> > > PHP developers. But, the August 16th deadline is still looming.
> > I am also concerned about this. Here is the response I got from support:
> > "we're continuing to experiment with this feature, and have not made it
> > available further. I apologize for the delay and inconvenience, but keep
> > an eye on our developer talk group for future announcements."
> > I have been watching this list for about a month (prior to checking with
> > support) in case the feature is discussed here before being announced.
> > @twitterapi, could we get some clarification on whether or not something
> > will be ready before the August 16 deadline?

Reply via email to