Split OAuth2 logic from input/output processing

[GoogleCodeExporter]

Currently, OAuth2 is implemented as a single class. It works good for usual php 
web-app cases, but makes it difficult to use the class for processing requests 
in daemonig fashion (in loop, when input is supplied as arrays and output is 
expected as return values).

I propose to introduce additional class, object of which will work as 
input/output proxy. Default implementation would do just what is currently done 
(getting data from _GET, _POST, _SERVER, filter_input_array, outputting data 
with header() and echo).

And custom implementations would allow to use OAuth2 in daemonic or 
batch-processing tasks. Also, this would allow to implement a clean set of tests

Original issue reported on code.google.com by [email protected] on 29 Dec 2010 at 7:25

[GoogleCodeExporter]

I think this is a good suggestion too. BTW, any code snippet as example of your 
idea?

Original comment by [email protected] on 12 Feb 2011 at 8:56

[GoogleCodeExporter]

I agree. Instead of directly accesing the the superglobals 
$_SERVER/$_POST/$_GET i would suggesto introduce kind of a "request" object, 
that can be injected to the actualy oauth object. 

This would be useful for unit testing as well since one could mock this request 
object.

Same should be done for the backend tocken handling. Instead of using 
inheritence i suggest to introduce a "backend object" implementing an interface 
and inject this as well.
So the the actual oauth lib would do nothing but talking its request and the 
backend object without knowing their inner logic aka data source.

Original comment by [email protected] on 14 Sep 2011 at 1:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Some visuals just to get an idea:
http://tinyurl.com/6aeguzd

the request should probably offer an opportunity to esplictly get "crytable" 
parameters (like $_POST) for web. (needed for grant access token and grant type 
password)

Original comment by [email protected] on 14 Sep 2011 at 2:12