Hi Tom,

Thanks for the thoughts. I like your second solution. To host a tweet
service on my site ("You can use your own server as a service which
sends all requests to twitter. "). I spoke with a colleague of mine
and his advice was the same. My question (concern) is doesn't this
open me up as a potential target for would-be-do-badders and create an
additional layer of potential security issues?

Michael

On Aug 1, 1:21 pm, Tom <allerleiga...@gmail.com> wrote:
> 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?

Reply via email to