OpenTransact on Android
[youtube=http://www.youtube.com/watch?v=EZefmK1tndc&w=560&h=315]
Update (June 15): Cyberwire on Google Play App Store
Cyberwire is an open source proof-of-concept for OpenTransact on Android. In the screencast, we see the Android app used to transfer 10 imaginary coffeebucks using one OpenTransact provider implementation. Even with a different OpenTransact provider implementation, we see the same functionality accessed by the same Android app.
OAuth Dynamic Client Registration Protocol is used to allow the Android app to start communicating with a new OpenTransact provider. A custom application_type request parameter is set to “noredirect” to indicate to the provider that instead of the client providing its own redirect_uri, the provider should choose a uri within its own domain and after authorization, the client will snarf the authorization code parameter from that uri instead of its own.
OpenTransact: Testing OAuth Scopes with Artifice and Cucumber
[blip.tv http://blip.tv/play/AYLP3wMA width=“480” height=“405”]
In this screencast, we’ll improve the code introduced in the previous post OAuth Scopes with UMA Action URLs with the help of our friends Artifice and Cucumber.
Calls to Net::HTTP can be intercepted by Artifice and sent to your rack application instead of the network. If you are developing an OAuth provider, Artifice makes testing the api a lot easier. Since the OAuth ruby gem uses Net::HTTP, we can wrap Artifice blocks around our client calls in tests and Artifice will intercept the calls and route them to our Rails app.
OAuth Scopes with UMA Action URLs
In a recent South Park episode, Kyle is kidnapped and subjected to product prototyping (made of people) by employees of a large, cult-like tech company who explain that it is all justified: Kyle failed to read the complex terms and conditions he agreed to. Unfortunately, the risks of consenting to the agreement were not clear to Kyle.
There is a new hope. Earlier this week, Twitter announced more precise controls over permissions granted to third parties. Twitter wants to make the risks of consent more clear. Access to your direct messages should be on a need-to-know basis. Twitter says that by mid-June, when you grant a third-party permission to your twitter account, it will no longer be able to access your direct messages unless you have explicitly granted that particular type of access.
CapCard: Opentransact with OAuth
The previous two screencasts demonstrated using Opentransact for simple web payments without using OAuth. Now we see how Opentransact web payments can be made with OAuth. Watch the original larger screencast to make reading the typing easier on the eyes.
To get OsCurrency to work with CapCard, I made this checkin.
Stupid Currency Tricks: Payment Dropbox with OAuthActiveResource
[youtube http://www.youtube.com/watch?v=2r-1MiN3lY4&hl=en&fs=1&]
OAuth support with the OsCurrency API was first demonstrated in January. Ruby on Rails developers may have noticed that I didn’t use ActiveResource with OAuth. Instead, in both the January screencast and the Twitter OAuth Consumer screencast, we coded in raw JSON. This was a bummer because, as easy as it is to write JSON, it is difficult to test, maintain and support. It would be much better if we could use ActiveResource.
Stupid Currency Tricks: Twitter OAuth Consumer
[youtube http://www.youtube.com/watch?v=mtIiECRbHqs&hl=en&fs=1]
3/27/09 Update - Twitter announced today a new method that apparently allows one to follow someone in one-click from another website but it is a negligible step forward. It seems to take two clicks and doesn’t return the follower back to where he came from as is done in this screencast with OAuth.
Twitter recently started rolling out OAuth support in a private beta for developers. Previously, as described in the Twitter Development Talk group, there was no way to automate a member of your website to follow your website’s twitter account, for instance. Now, with OAuth, today’s screencast shows that this can be done in a usable manner.
QR Codes
Brandon Wiley invented an ATM machine this week for complementary currency using QR codes. Writing python code on Google App Engine, he wrote code which can generate a QR code using Google Chart API and an oauth consumer to allow someone to redeem the currency without giving the ATM site the username and password to their account. The transaction was made with the OSCurrency API. Some more API support needs to be done to make the transaction more resistant to counterfeiting, but it already makes a cool demo.
Stupid Currency Tricks with OAuth
We interrupt our regularly scheduled program with a screencast for software developers.
If you are not a software developer, the screencast may not be useful, but it’s good to understand why OAuth is critical to online complementary currency. When you buy something online, you don’t log into your bank’s website to do the transaction. You may click on a PayPal purchase button or some other one-click button. So, a member may not want to log into a community currency website to make a payment to a peer. The community currency website needs to expose an application programming interface to third party applications (like Facebook) to make payments and execute other functions. How is the third party authorized to make a payment on behalf of the member? The OAuth protocol allows a member to seamlessly grant the third party application authorization to perform specific actions on his accounts, for instance. It’s kind of a big deal.
