This looks awesome! Thank you so much for writing all this and submitting it!

Before I merge it, we just need to do two things:

1. We need to convert all tabs to 4 spaces
2. We need to validate client credentials in the JWT token

Updated :) Hopefully everything's fine now :)

I'm sorry. This PR now touches every file in the repository, and has added tons of changes to files it does not need to edit. I cannot except this.

This PR has become too messy for me to understand the changes being requested. I am going to close it, but please submit another one once it's cleaned up.

Also, the method in the new Interface should be getClientDataFromRequest, not getTokenDataFromRequest

I think php-cs-fixer went and touch a lot of files to convert them to psr standards. I am going to revert back to before php-cs-fixer and start from there.

Hmm... I cannot find anywhere in the fig standards where there must be an empty line before a return. But I do want this repository to follow the PSR standards, so if it needs to be compliant, we should do so in a separate pull request.

I tried a revert and things started breaking :(

What I have done:

• Made a copy of my own working copy.
• Nuked my own fork.
• Reforked.
• Replaced the files that only applied to the change for JWT tokens.
• Implemented getClientDataFromRequest() and validateClientData() in OAuth2_ClientAssertionTypeInterface.

What I will then do is runphp-cs-fixer on the files I have updated only.

The only flaw is that if you run php-cs-fixer without explicitly telling it what to fix, it will also run some non-psr fixes which were designed for symphony.

I see, you ran it with the all flag. Try running it like this:

php php-cs-fixer.phar fix /path/to/project --level=psr2

I just tried with --dry-run to test and it seems to have touched a lot of files (even the ones I have not touched).

There also seems to be an issue with one of the class files:

! The class OAuth2_GrantType_AuthorizationCodeInterface in /www/oauth2-server-php/src/OAuth2/ResponseType/AuthorizationCodeInterface.php does not match the file path according to PSR-0 rules

Should I instead do a pull request that consists of the commits for JWT and a commit for the fixed files?

This travis-ci build also seems to be stuck: https://travis-ci.org/bshaffer/oauth2-server-php/builds/4175697

I'm just getting started but my first attempt to instantiate \OAuth\Server leads me to what appears to be a very similar message:

 PHP Fatal error:  Interface 'OAuth2\ResponseType\AuthorizationCodeInterface' not found in ...

Where the error originates is simply my storage object which is heavily modelled after the base Mongo storage adapter. The class starts like this:

namespace LG\OAuth;
use LG\Connection as Connection;
use \OAuth2\ResponseType\AuthorizationCodeInterface as AuthorizationCodeInterface;

class CouchbaseStorage implements AuthorizationCodeInterface,
    AccessTokenInterface,
    ClientCredentialsInterface,
    UserCredentialsInterface,
    RefreshTokenInterface,
    JwtBearerInterface
{ ... }

Because I'm operating in my own namespace I used the explicit use statement to disambiguate the namespace for AuthorizationCodeInterface but it seems to make no difference.

Ken

p.s. obviously I'd expect if this did work that I'd need to make the same "use" statements for the other interfaces referred to but I haven't bothered to tackle that one yet.

@ksnyde This looks like the class could not be found. Make sure you include the autoloader to load the classes from the library. See https://github.com/bshaffer/oauth2-server-php#installation

Alternatively, the library is PSR-0 compliant, so if you have a PSR-0 autoloader you can use that.

Or, if you are using composer, composer should generate a valid autoloader, so you can use that too.

Yes I have included the autoloader. Here's my code:

require_once('../oauth2-server-php/src/OAuth2/Autoloader.php');
OAuth2\Autoloader::register();

For what it's worth this is my index.php in Restler (aka, the first file loaded for any API request). It then handes off execution to a handler class which then instantiates my storage class.

The use statements do not require a prefixing backslash (ie \OAuth2...). This seems benign to me, but it may be confusing the autoloader. 
—
Brent Shaffer

On Tue, Jul 2, 2013 at 4:17 AM, Francis Chuang [email protected]
wrote:

@ksnyde This looks like the class could not be found. Make sure you include the autoloader to load the classes from the library. See https://github.com/bshaffer/oauth2-server-php#installation
Alternatively, the library is PSR-0 compliant, so if you have a PSR-0 autoloader you can use that.

Or, if you are using composer, composer should generate a valid autoloader, so you can use that too.

Reply to this email directly or view it on GitHub:
#24 (comment)

Actually they DO require a backslash when the object is in a namespace other than root. In any event I tried both but as you probably already know if I have this code:

 namespace Foo\Bar;
 use Monkey\See\MonkeyDo as MonkeyDo;

it will look for MonkeyDo in the \Foo\Bar\Monkey\See namespace.

No, this is incorrect. The prefixing slash is only necessary when a class is referenced outside the use statement. You have:

namespace LG\OAuth;
use LG\Connection as Connection;
use \OAuth2\ResponseType\AuthorizationCodeInterface as AuthorizationCodeInterface;

As the Autoloader looks for the prefix "OAuth2", it is possible this is causing the error. I suggest trying this instead:

namespace LG\OAuth;
use LG\Connection as Connection;
use OAuth2\ResponseType\AuthorizationCodeInterface as AuthorizationCodeInterface;

It's just a guess... I cannot fathom what else might cause this.

Well just for shits and giggles I thought I better try it again without the leading backslash. Same result but I was surprised to see the resolution to the appropriate namespace did work without the backslash ... I know I've seen the opposite behaviour and therefore including the backslash seems more defensive to me. Maybe the variation in behaviour comes from details in the PSR0 spec? I've been meaning to make sure that I am 100% compliant with ... I'm know I'm close.

In any event. I am quite certain this is not related to the issue as I've now just run from the interactive PHP environment three commands:

 require_once "../oauth2-server-php/src/OAuth2/Autoloader.php";
 OAuth2\Autoloader::register();
 include "include/oauth/CouchbaseStorage.php";

and I get the following:

 PHP Fatal error:  Class LG\Oauth\CouchbaseStorage contains 4 abstract methods and must therefore be declared abstract or implement the remaining methods (OAuth2\ResponseType\AuthorizationCodeInterface::enforceRedirect, OAuth2\ResponseType\AuthorizationCodeInterface::createAuthorizationCode, OAuth2\ResponseType\ResponseTypeInterface::getAuthorizeResponse, ...)

BTW, my CouchbaseStorage file now looks like this:

namespace LG\Oauth;
use LG\Connection as Connection;
use OAuth2\ResponseType\AuthorizationCodeInterface as AuthorizationCodeInterface;
use OAuth2\ResponseType\ResponseTypeInterface as ResponseTypeInterface;
use OAuth2\ResponseType\AccessTokenInterface as AccessTokenInterface;
use OAuth2\Storage\UserCredentialsInterface as UserCredentialsInterface;
use OAuth2\Storage\ClientCredentialsInterface as ClientCredentialsInterface;
use OAuth2\Storage\RefreshTokenInterface as RefreshTokenInterface;
use OAuth2\Storage\JwtBearerInterface as JwtBearerInterface;

/**
 * Couchbase storage for all storage types
 *
 * NOTE: based off of the example Mongo storage class written by Julien
 *
 * @author Ken Snyder <[email protected]>
 * @author Julien Chaumond <[email protected]>
 */
class CouchbaseStorage implements AuthorizationCodeInterface,
    AccessTokenInterface,
    ClientCredentialsInterface,
    UserCredentialsInterface,
    RefreshTokenInterface,
    JwtBearerInterface
{

Furthermore, I have checked and abstract references to enforceRedirect() exist in both AuthorizationCode.php and AuthorizationCodeInterface.php but there is no implementation anywhere in the source code.

Same applies to the other three cases.

In this first case, the implementation is probably just returning a boolean value ... effectively its configuration. I'll see if the other missing methods are this straight forward. Might be good to have the examples have a default value for these parameters if that's the case? Would allow them to work out-of-the-box.

Change your class header to this:

namespace LG\Oauth;
use LG\Connection as Connection;
use OAuth2\Storage\AuthorizationCodeInterface as AuthorizationCodeInterface;
use OAuth2\Storage\AccessTokenInterface as AccessTokenInterface;
use OAuth2\Storage\UserCredentialsInterface as UserCredentialsInterface;
use OAuth2\Storage\ClientCredentialsInterface as ClientCredentialsInterface;
use OAuth2\Storage\RefreshTokenInterface as RefreshTokenInterface;
use OAuth2\Storage\JwtBearerInterface as JwtBearerInterface;

As mentioned in your other ticket, you do not want to use the ResponseType interfaces in your Storage class.

Wow. That works. I'm at a loss. Where do I find the implementation of methods like enforceRedirect()? I did a global find with my editor and it didn't find it. :^/

Ok, I see the failure in my logic. I had added the \ResponseType references earlier because I had been trying to trace the classname backwards and didn't realise there were two classes of the same name.

Thanks for you patience/help.

No problem! Glad we could get it sorted out.

Yes, enforceRedirect (and other methods) are implemented in the OAuth2\ResponseType\... classes out of the box, so you don't need to create them yourself. Honestly, I'm not sure there are many use cases to use the ResponseType interfaces, but I added them just in case.