Thursday 21 October 2010 12:36:37 pm
I'm working on an OAuth support for this.
The issue is to have the admin authorize the extension at install time.
1 - use ssh terminal to generate the request token and access token request URL
2 - the user open the access token request URL in a browser and get a PIN code
3 - use ssh terminal to validate the request token with the pin code and generate the access token and token secret
4 - the admin save the token/token secret in an INI file.
Zend seems not to be supporting PIN code validation but use Callback URL redirections instead. So this leads to...
1 - create a module/view for the extension
2 - after installing and activating the extension, the admin goes to http://.../site_admin/autostatus/twitter_setup?action=register this will redirect him to Twitter where he will login and authorize the extension
3 - after authorization it will redirect him back to http://.../site_admin/autostatus/twitter_setup?action=validate the callback script will then display the token and secret
4 - the admin copies/pastes the token and secret in a INI file
Alternatively, solution 3:
1 - create a new extension let say eztwitteroauth lib and include Arc90 Twitter OAuth library
2 - configure autostatus to use eztwitteroauth extension to access twitter
3 - use solution 1 to setup the tokens/secret
What do you think?
Thursday 21 October 2010 1:06:34 pm
Hi Quoc Huy and thanks for these explanations.
Let us say we find a way to generate OAuth tokens and store them somewhere/somehow : can then the Zend lib (the currently used one) support this new authentication mode ?
A positive answer would let us only slightly alter the autostatus extension, and create a brand new one, as you suggested, properly decoupled, to handle authorization in a generic manner.
Friday 22 October 2010 11:36:18 am
@Jerome, I will check and confirm how doable is solution 1 without breaking other services. And will also see the "drivers" solution, already have an idea for this.
@Nicolas, if we can generate and store the tokens then the Zend lib will support it. See my test on my twitter @quochuync: "test zend twitter oauth - about 24 hours ago via eztweeter" It was sent with a PHP script that uses Zend OAuth and the tokens from the extensions that comes with the tutorial I sent you.
@kracker, it looks more like for eZ to act as a OAuth server not client.
Saturday 23 October 2010 6:06:29 pm
Sorry for the late reply I was quite busy those days... I'm happy to see such an animation here
To complete Nicolas' answer only a part of an old version of the Zend Framework is embed in the extension. I don't remember exactly the version number (and unfortunately there's no info on that in the source code), but I think it's a part of the version 1.8 or 1.9. The current version of Zend Framework is 1.10.8 and the version 1.11 has reached the rc status.
In addition, there's a Zend_Oauth component  and the documentation explains how it works with Twitter as example So I think it would be nice to stay with Zend Framework as the only "external" requirement.
On the oauth support, there are many things to keep in mind. One of the purpose of autostatus was to be able to configure everything in the admin interface and to be able to use several accounts on several social plateform on the same site. That's why you are currently able to configure the event type in the workflow edit interface of eZ Publish. Given that, I think a solution based on the "solution 2" is the best. In fact, we need to add a module/view where the admin user can enter the twitter login and ask the permission for posting messages on his behalf. When he is redirected, the token is saved in the database. Then in the template used to configure the event type for twitter, we have to replace the login / password fields by a drop down list where we let the user to choose the right account.
I hope to be able to work on autostatus next week, but if you want to contribute, feel free to register as a member of the project
Monday 25 October 2010 3:36:16 pm
On the tests I've done earlier, I used the Ubuntu version of Zend Framework and used the OAuth component. It's working as in the normal OAuth process where you need to redirect the user to Twitter and then back with the tokens. But we are creating a bot and the issue is to generate the tokens. I'm happy with staying with Zend but we need to agree on a way to generate the token and secret. That's the solutions I suggested. I suggested in solution #3 to use Arc90 because the Zend Component does not support PIN validation, it needs to be URL redirections, which is why I suggested solution #2.
If we go with solution #2, how would we save the token/secret? In an INI file or as you said in a DB? If DB then do you think we should create a new table? Or new 1 content classes: "Twitter accounts" which can contain multiple "Twitter account".
Sunday 26 June 2011 2:36:26 am
The OAuth support is finally there See http://websvn.projects.ez.no/wsvn...nk/extension/autostatus/?op=revision
Wednesday 29 June 2011 9:06:32 am
Bad URL, gives something like http://master.loc/index.php/plain...php/plain_site_admin/workflow/edit/2
Tested with revision 50
Thursday 07 July 2011 3:06:45 pm
Now Autostatus supports OAuth authentication for Twitter and identi.ca, that's nice.
However, the way it's implemented avoid other authentication methods (like OAuth2 for Facebook). Indeed, in <b>autostatusType::customWorkflowEventHTTPAction()</b>, you force the use of <i>Zend_Oauth_Consumer</i> which only supports OAuth 1.
A nice thing would be to allow to define an <i>authenticator</i> per social network. The social network class would define a method returning the right authenticator for instance.
What do you think ?
Friday 08 July 2011 11:36:44 pm
That seems to be a good idea but that also means that all authenticators should implement the same Interface and have a close system (same method calls/steps)
Is it possible given the differences between OAuth 1.0a and 2.0? I don't know OAuth 2.0 enough to answer
Another solution would be to have a specific "custom workflow action" depending on the auth mechanism to use on a given social network. Since, this part is loaded with an Ajax request , this is quite easy to achieve. I know this is a bit procedural and this also means that a autostatus/oauth2 view will be required. On the other side, this would be very flexible if one day we need to implement another authentication system.
In fact, it really depends to the differences between OAuth 1.0a and 2.0. So I'll let you choose the wiser solution