[twitter-dev] Re: Open-source, distributed PHP app and consumer secret
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?
[twitter-dev] Re: Open-source, distributed PHP app and consumer secret
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?
[twitter-dev] Re: Open-source, distributed PHP app and consumer secret
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?
