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. Tom 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?
