Hi Stein, thanks a lot for bring this up.
As a general rules of thumb I do agree with Simone about backward compatibility. Since is already broken let's try to improve as many things as we can for next release. I will have some other proposals but I will write a separate mail for it. On Mar 24, 2013, at 2:16 PM, Stein Welberg wrote: > Hi Guys, > > Since Simone made a good remark in the another thread (changing/updating > groupId/artifactId) that we are breaking Amber backwards-compatibility, I > would like to suggest another change. I would also like your opinion about > the way to implement it. > > Currently the Oltu Authorization server implementation is not spec compliant > regarding the support for Basic Authentication (see OLTU-5 and OLTU-16). > According to the spec section 2.1.3 [0] the authorization server must support > basic authentication. I am currently trying to figure out a way to support > both unauthenticated requests and authenticated requests (either using basic > authentication or not). The unauthenticated requests will not have the > client_secret parameter since they possibly don't have a client_secret. > > The current setup of the validators does not allow us to dynamically make a > param (e.g. the client_secret) required or optional based on some parameter. > The validators are added in the OAuthTokenRequest so this is the place to > create the distinction between an unauthenticated request an an authenticated > request. Without doing a real big refactoring of the validators we have two > options to support both authenticated and unauthenticated requests: > > 1. One way to do this is by creating another OAuthTokenRequest class that > accepts only authenticated requests (the OAuthAuthenticatedTokenRequest > class). The plain OAuthTokenRequest class then only handles unauthenticated > requests. > > 2. The second option is to use a boolean in the constructor of the > OAuthTokenRequest class to indicate whether we want Oltu to treat the request > as an authenticated request or not. I would suggest that we enforce > authentication by default and that adding the boolean to the constructor > would make it possible to also support unauthenticated requests (secure > defaults). > > My preference goes to the first approach where we create a separate class > purely for authenticated requests since it creates more readable code. (code > with booleans in a method tend to get quite unreadable quickly!) > > I would like to have your opinions since this is quite a change in the API > for the developers that are going to use Oltu to create an authorization > server! I remember the discussion in OLTU-5 and after thinking about it I think we can go with the 2 different classes (so solution 1. above) as long as : - we document it - it is possible to use both the OauthTokenRequest and the OauthAuthenticatedTokenRequest together if needed. WDYT? Regards Antonio > > Thanks. > > Regards, > Stein > > [0] http://tools.ietf.org/html/rfc6749#section-2.3.1
