Validating at the start makes sense to me. The key difference right now is that, when I start the Authorization Code Grant flow (Section 4.1) with no credentials, I want CXF to redirect to the login UI instead of returning 401.
Craig On Thu, Jan 24, 2013 at 7:43 AM, Sergey Beryozkin <[email protected]>wrote: > The only thing which is different from the way CXF manages the start of > the authorization request is that Salesforce will validate the redirect > parameters (client id, redirect uri, request type) before actually > presenting that initial authentication screen, while CXF will do it at the > end of the authorization request. > > Is this difference in the way the authorization request is managed > important for your purpose of interposing Salesforce service ? > > I think we can relatively easy configure AS to validate at the start of > the process too, let me know please > > Sergey > > > On 24/01/13 13:11, Sergey Beryozkin wrote: > >> Hi >> On 22/01/13 21:11, Sergey Beryozkin wrote: >> >>> On 22/01/13 18:58, Craig McClanahan wrote: >>> >>>> On Tue, Jan 22, 2013 at 9:10 AM, Sergey >>>> Beryozkin<[email protected]**>wrote: >>>> >>>> >>>>> Yes, the only limitation in CXF at the moment is that it does it >>>>>>> with a >>>>>>> >>>>>> sequence of forms, whereas you'd like to have a single form asking >>>>> for both >>>>> authentication credentials and the authorization approval/denial in the >>>>> same/single view - obviously a presentation builder would need to know >>>>> somehow of the authentication scheme supported by AS. >>>>> >>>>> I need to think a bit more about it. >>>>> >>>>> Thanks, Sergey >>>>> >>>>> At the end of the day, what I'm trying to do is set up a "mock" >>>>> version of >>>>> >>>> Salesforce, including a couple of dummy services, for the purposes of >>>> exercising our OAuth client code against something easy to set up in >>>> a CI >>>> environment. I was delighted to see that I might not have to implement >>>> all >>>> the server side logic, but need to figure out a way around this one. >>>> >>> >>> I'll experiment with the way Salesforce does it; I might just add a >>> property to AS that will let users configure it to accept >>> unauthenticated requests in which case it will set a flag for the >>> presentation layer to know it needs to offer an authentication option >>> alongside the authorization data - the way things are done now, it is >>> completely up to the security layer how to collect the authentication >>> credentials, but I guess when it is well known that say Basic Auth is >>> used then this composite presentation option is also possible, I'll look >>> into it >>> >>> I haven't proceeded to actually creating a Salesforce account, still >> reading a bit, in here: >> >> http://wiki.developerforce.**com/page/Getting_Started_with_** >> the_Force.com_REST_API<http://wiki.developerforce.com/page/Getting_Started_with_the_Force.com_REST_API> >> >> >> it shows two separate screens, first the user is prompted to >> authenticate (if not authenticated), next - approve. >> >> This style will definitely work with CXF, but I guess those screens may >> be outdated >> >> Actually - just spent some time creating a SalesForce developer account, >> a basic test application and then updated Talend demo to redirect to it >> to authorize just to see the screens and I do see only the >> authentication dialog on the first screen. >> >> Can we talk more about the actual requirements on your end ? >> >> >> >> Thanks, Sergey >> >> >>>> BTW, do you know of any open sourced sample apps that use the OAuth 2 >>>> stuff? It's always interesting to learn from how other people have >>>> used it. >>>> >>>> Apache Oltu (formerly Amber) may be of help too, there are few >>> differences in the way OAuth2 is implemented there, but check them out >>> please too - there could be some relevant demos >>> >>> Cheers, Sergey >>> >>> Craig >>>> >>>>
