cpanvote integration with mobile apps

6 views
Skip to first unread message

Olaf Alders

unread,
Mar 7, 2011, 4:28:52 PM3/7/11
to cpan...@googlegroups.com
Hi Yanick,

First off, let me just say that I didn't RTFM. :) I'm currently working on an iPad app for metaCPAN and I was wondering if the cpanvote API is currently set up to handle authentication from mobile apps. I know you're using cookies at this point and I don't think that is going to be a good fit for something like an iOS application which won't retain that sort of information. Did you have anything in particular in mind for this sort of scenario?

Best,

Olaf

Yanick Champoux

unread,
Mar 7, 2011, 9:14:08 PM3/7/11
to cpan...@googlegroups.com, Olaf Alders
On 11-03-07 04:28 PM, Olaf Alders wrote:
> First off, let me just say that I didn't RTFM.:)

That's okay, considering that for the cpanvote API, I still have to
WTFM anyway. :-)


> I'm currently working on an iPad app for metaCPAN and I was wondering
> if the cpanvote API is currently set up to handle authentication from
> mobile apps. I know you're using cookies at this point and I don't
> think that is going to be a good fit for something like an iOS
> application which won't retain that sort of information. Did you
> have anything in particular in mind for this sort of scenario?

I had nothing specific in mind, mostly because I don't have much
experience with mobile apps. For that, I really should ask an expert.
So... hi Olaf! ;-)

Seriously, what do mobile apps use? Tokens as part of the urls, or
custom http headers? In both cases, supporting them will require
minimal tweaks. In any case, it'll probably boil down in the main
action 'base', in which we'll set up the session up from whatever
authentication transport we'll be using.

Joy,
`/anick

Olaf Alders

unread,
Mar 13, 2011, 11:10:15 PM3/13/11
to Yanick Champoux, cpan...@googlegroups.com

On 2011-03-07, at 9:14 PM, Yanick Champoux wrote:

> On 11-03-07 04:28 PM, Olaf Alders wrote:

>> I'm currently working on an iPad app for metaCPAN and I was wondering
>> if the cpanvote API is currently set up to handle authentication from
>> mobile apps. I know you're using cookies at this point and I don't
>> think that is going to be a good fit for something like an iOS
>> application which won't retain that sort of information. Did you
>> have anything in particular in mind for this sort of scenario?
>
> I had nothing specific in mind, mostly because I don't have much experience with mobile apps. For that, I really should ask an expert. So... hi Olaf! ;-)

Clearly, you overestimate my abilities! :)

>
> Seriously, what do mobile apps use? Tokens as part of the urls, or custom http headers? In both cases, supporting them will require minimal tweaks. In any case, it'll probably boil down in the main action 'base', in which we'll set up the session up from whatever
> authentication transport we'll be using.

I guess before we go into too much depth here, I need to do some reading. I guess I was just mostly wondering about the workflow. I can certainly have the user enter their Twitter login credentials into the app initially. I guess at that point I could connect have a process connect to cpanvote, which would then redirect to Twitter for login. I could login to Twitter with the credentials and then be redirected back to cpanvote with the tokens. At that point, I guess I'd just need cpanvote to provide me with some kind of token which I can then provide for future interaction. I'm not really that particular about what form that would take. As far as best practices go, I'd have to look into that as well. I must admit that when I read about OAuth implementations my eyes start to glaze over, so I'm hazy on a lot of details. :)

So, I'll just need to do my homework first, I guess!

Best,

Olaf

Olaf Alders

unread,
Mar 13, 2011, 11:12:14 PM3/13/11
to Yanick Champoux, cpan...@googlegroups.com
I should probably add that there are already some comments on this in the Github issues. Moritz has already started brainstorming: https://github.com/CPAN-API/cpan-api/issues/7#comment_845044

Best,

Olaf

Yanick Champoux

unread,
Mar 14, 2011, 11:16:41 PM3/14/11
to Olaf Alders, cpan...@googlegroups.com
Hi Olaf, all,

On 11-03-13 11:10 PM, Olaf Alders wrote:
>> I had nothing specific in mind, mostly because I don't have much
>> experience with mobile apps. For that, I really should ask an expert.
>> So... hi Olaf! ;-)
>
> Clearly, you overestimate my abilities! :)

You're the one building the mobile app. Clearly, that labels you as the
expert of the group. Your true abilities in the domain are
inconsequential. ;-)


>> Seriously, what do mobile apps use? Tokens as part of the urls, or
>> custom http headers? In both cases, supporting them will require
>> minimal tweaks. In any case, it'll probably boil down in the main
>> action 'base', in which we'll set up the session up from whatever
>> authentication transport we'll be using. >

> I guess before we go into too much depth here, I need to do some
> reading. I guess I was just mostly wondering about the workflow. I can
> certainly have the user enter their Twitter login credentials into the
> app initially. I guess at that point I could connect have a process
> connect to cpanvote, which would then redirect to Twitter for login. I
> could login to Twitter with the credentials and then be redirected back
> to cpanvote with the tokens.

I've re-looked at Net::Twitter, and if I'm not mistaken, we can't even
use raw username/password for applications. It's all OAuth
authentication where the app proxy the request to twitter, and end up
with a token that can only be used in the context of that app (which is
not a bad system, mind you). Is there anybody else on the list that can
confirm that I'm reading the Net::Twitter pod correctly? (or not, if the
case be)

> At that point, I guess I'd just need
> cpanvote to provide me with some kind of token which I can then provide
> for future interaction.

That part will not be a problem. We'll just have to generate a random
token, associate it with the internal identity of the user, and there we go.

> I'm not really that particular about what form
> that would take.

Whatever will make your life easy. From the web app, we can pass it as
a cookie, as a JSON response to a specific url, etc. It's all detail. :-)


> I must admit that when I read about OAuth implementations my
> eyes start to glaze over, so I'm hazy on a lot of details. :)

Same here. Only recently did I begin to understand the finer details of
the Oauth dance between the different parties. And even then,
I'm still at the 10,000 feet view of it. On the remote chance it could
help, I just crystallized my understanding of the process in an ASCII
strip: http://babyl.ca/misc/oauth.html :-)


Joy,
`/anick

Olaf Alders

unread,
Mar 15, 2011, 10:37:24 PM3/15/11
to cpan...@googlegroups.com, Yanick Champoux
Hi Yanick,

On 2011-03-14, at 11:16 PM, Yanick Champoux wrote:

>>
>> Clearly, you overestimate my abilities! :)
>
> You're the one building the mobile app. Clearly, that labels you as the expert of the group. Your true abilities in the domain are inconsequential. ;-)

Well played, sir!

> I've re-looked at Net::Twitter, and if I'm not mistaken, we can't even use raw username/password for applications. It's all OAuth authentication where the app proxy the request to twitter, and end up with a token that can only be used in the context of that app (which is not a bad system, mind you). Is there anybody else on the list that can confirm that I'm reading the Net::Twitter pod correctly? (or not, if the case be)

I guess I'm thinking of how TweetDeck, for example, authenticates with Twitter. I enter my username and password and the app then connects to Twitter on my behalf and provides my credentials. I never get bounced over to the site, but it all works via OAuth. So, I would guess it's just the app acting on my behalf?

>
> > At that point, I guess I'd just need
>> cpanvote to provide me with some kind of token which I can then provide
>> for future interaction.
>
> That part will not be a problem. We'll just have to generate a random token, associate it with the internal identity of the user, and there we go.

Perfect.


>
>> I must admit that when I read about OAuth implementations my
>> eyes start to glaze over, so I'm hazy on a lot of details. :)
>
> Same here. Only recently did I begin to understand the finer details of the Oauth dance between the different parties. And even then,
> I'm still at the 10,000 feet view of it. On the remote chance it could help, I just crystallized my understanding of the process in an ASCII
> strip: http://babyl.ca/misc/oauth.html :-)

It's "OAuth for Dummies". :) Actually, that's a very succinct summary of the problem. Thanks for that. Makes it very clear!

Best,

Olaf

Yanick Champoux

unread,
Mar 16, 2011, 9:52:14 AM3/16/11
to Olaf Alders, cpan...@googlegroups.com
Hi!

A quick targeted reply:


On 03/15/11 22:37, Olaf Alders wrote:
> I guess I'm thinking of how TweetDeck, for example, authenticates with Twitter. I enter my username and password and the app then connects to Twitter on my behalf and provides my credentials. I never get bounced over to the site, but it all works via OAuth. So, I would guess it's just the app acting on my behalf?

Good questions. Good enough to go back to the Twitter dev site. And
I think I found how they do it: http://dev.twitter.com/pages/xauth

That's right. There's oauth, and now there's also xauth. The fun,
it never stops! ;-)

I have to check, but I don't think Net::Twitter supports xauth right
now. If it doesn't, we might have to roll up our sleeves and submit a patch.

Joy,
`/anick

Olaf Alders

unread,
Mar 16, 2011, 12:53:51 PM3/16/11
to cpan...@googlegroups.com, Yanick Champoux

Ah, nice work. I believe it's already built in: http://search.cpan.org/~mmims/Net-Twitter-3.13000/lib/Net/Twitter/OAuth/XAuthRequest.pm I wanted to send you a MetaCPAN link, but it looks like this one is not in our index. :(

Best,

Olaf

Moritz Onken

unread,
Mar 16, 2011, 12:57:47 PM3/16/11
to cpan...@googlegroups.com
>
> Ah, nice work. I believe it's already built in: http://search.cpan.org/~mmims/Net-Twitter-3.13000/lib/Net/Twitter/OAuth/XAuthRequest.pm I wanted to send you a MetaCPAN link, but it looks like this one is not in our index. :(

That file has been removed in 3.13001 and included in OAuth it seems:

3.13001 2010-11
- use POST with Authorization header for XAuth (per Twitter documentation)
- replace homegrown XAuth support with Net::OAuth's native support
- accommodate 2 base URLs for API::Search (search and trends* methods use different base URLs)
- enable SSL support for API::Search

So the indexer is fine :)

Olaf Alders

unread,
Mar 16, 2011, 1:17:43 PM3/16/11
to cpan...@googlegroups.com

Ah, yes, you raise a good point. That's one of the things I find confusing about search.cpan.org I really wish it would default to just the very latest version of a module. I don't really care about stuff that won't be in the latest install. Since the current MetaCPAN index doesn't bother with anything but the latest stuff, I find our searches a bit cleaner that way. It's also handy that we'll be able to do the same with the next version!

Yanick Champoux

unread,
Mar 27, 2011, 3:39:12 PM3/27/11
to cpan...@googlegroups.com, Moritz Onken
On 11-03-16 12:57 PM, Moritz Onken wrote:
>> > Ah, nice work. I believe it's already built in:http://search.cpan.org/~mmims/Net-Twitter-3.13000/lib/Net/Twitter/OAuth/XAuthRequest.pm I wanted to send you a MetaCPAN link, but it looks like this one is not in our index.:(
> That file has been removed in 3.13001 and included in OAuth it seems:

Very true. It now lives as the xauth() method in
Net::Twitter::Role::OAuth. And judging from the doc,
we just have to use it like 'request_access_token'. That's even easier
than I was expecting. :-)

Joy,
`/anick

Reply all
Reply to author
Forward
0 new messages