Two proposals for the future of OAuth-PHP

[Morten Fangel]

Hi oauth-php..

I have two proposals, one minor and one major.. So let's ease
into it, and start out with the minor one

1) Add 2-legged Support
Add support for 2-legged requests (known by some as
Tokenless Requests). The main concern is how the API should
be modified. You can either change OAuthServer
::verify_request( $req) to OAuthServer::verify_request( $req,
$require_token = true )

Or you can add a new method, OAuthServer
::verify_2legged_request( $req )

So what do we think about this? Personally I'm for the change of
::verify_request, instead of adding a new method.

---

2) Refactor Library with Interfaces and Type Hints
I think we should add at least two interfaces, one for tokens and
one for datastorages. We should then type-hint all methods
that takes one of these requests as arguments..

The main advantage of this is to use exitings ORM objects as
tokens in a well-documented way (it works as is now, as long
as you have the public properties "token" and "secret")

Currently there is the OAuthDataStorage class which kind of
works as a base for the datastorage-class you need. Except it
really isn't, because two of the methods are called the wrong
thing, in that OAuthServer calls the method by another name
(fetch_*_token vs new_*_token)

Having Interfaces with good docs would make it a bit easier
to actually implement the library in a server-functionality..

I wouldn't mind doing all the coding myself - but I would make
such changes without first checking if people would accept them.
(I will keep backwards-compatibility as much as can be expected)

So, let's count up the votes php-internals style (because that
always works reeeally well)
I'm
+1 for 2-legged with verify_request( $req, $require_token)
+1 for refactoring

Regards
Morten Fangel // fangel

[Chris Messina]

Without commenting on your specific proposal Morten, have you taken a
look at the Mediamatic OAuth library?

http://www.marcworrell.com/article-2990-en.html

I think it would be great if these two libraries could be brought
together and merged, creating one code-base for OAuth in PHP.

I don't know what it would take, but I would like to throw that idea
out there and see what y'all think?

Chris

[Morten Fangel]

Hi Chris

As I have sort of mentioned in some other mail (can't recall which) the
scope of oauth/php ("our") and oauth-php (mediamatic) is pretty
different

Mediamatics is, or at least how I see it after scanning through their
howtos, more rigid but easier to use. This will probably lead to
a lot of beginner and intermediate users, as they have a fairly clear
cut route to success. I might be horribly mistaken because I haven't
had the time to look through their code yet.


"Our" is mainly just a bunch of utility functionality coupled with a
light
data storage. So you can pretty much bend it any way you so want
(that is, as long as this way is tree-legged). Okay, that's a pretty
rough
generalization, but this is how I see it. Termie (the orig. author)
might
not agree.
This will, especially if we go the interface-way, probably lead to more
advanced use cases (like an existing framework that wants to add
OAuth support using their existing ORM system)

But for the two different libraries to really live together, I would
opt for
us catering even more to the advanced-use-case crowd, and make it
real easy to extend and assimilate into your existing system..


-Morten

[Will Norris]

I would agree that making tokens and data storage replaceable by the
platform using the library is definitely a good thing. I feel pretty
confident in saying that the Mediamatic library was not intended to be
designed in a rigid fashion preventing that. In fact, the data
storage works quite well, and there is a clear abstract class to
extend for this. I would agree that there should be a formal
Interface as well, and that's something I'm working on patching in the
Mediamatic library.

Basically, I wouldn't say that the intended scope of the two libraries
is different. It may be that in practice they are different because
of the specific use-cases for which they were respectively developed.
But I don't think that is representative of a conscious or deliberate
difference in design.

-will

[Morten Fangel]

Yes. Currently I use my own ORM classes as tokens and consumers, which
the library happily pushes along, so when the data storage gets sent a
token, I can also find it's database-id by doing $token->id. Had you
been forced to cast the token a OAuthToken, then all your "extra" data
besides token+secret gets lost..

Which is why the "sane" way of doing it, would be making a interface
with a getToken and getSecret method, which you can just shape your
own ORM objects to follow, and then you can safely use these within
the library..

(As it is, this only works in the library because there is never any
check on the form of the token, as long as it can use the public
variables $token and $secret. Which is.. sub-optimal)

--

But I still don't really see a way for the two libraries to merge. You
could decide that oauth-php is more mature / better designed, and then
replace the current "official" library with it. But it wouldn't be
worth the effort to try and merge the two..
And I'm not saying that we _shouldn't_ just make oauth-php the
official library. It does seem to have a somewhat more sane structure
from the brief glimpses that I have taken at the code..

-Morten

[Marc Worrell]

Will and Chris pointed me to this interesting discussion. I am the
author of the oauth-php library. The main objective was to have oauth
support in a cms, anyMeta, that Mediamatic builds and maintains for
their own projects. Recognizing that the library could be useful for
other people as well, I decided to rework it a bit and open source it.

At the time we didnt' use Andy's code because we had some different
requirements.

Will is completely right when he states that he library was not
intended to be rigid. We just didn't have the need to add more
flexibility. That said, we are developing the need for easier use in
applications that are only consumer or provider.

As for the proposal to add some more/better/whatnot interfaces to the
library, I warmly welcome work in that direction. And I would also be
very happy to make the library a bit more 'formally' supported and
less of a Mediamatic effort. Especially since the library turns out
to be quite functional and stable, and I am not part of Mediamatic
anymore.

- Marc Worrell