>
> Sorry for the late reply. yes, please do. Please close the review and JIRA
> issue.
>
Thanks,
Li
Li. Thanks again for committing my changes. This is gonna really help our
implementation. Do I need to close out the review and jira?
doug
On 12/12/11 3:10 PM, "Li Xu" wrote:
> ah, I see, no worry. I can clean up the code style when committing it.
> thanks.
: 12/12/2011 02:54 PM
Subject:Re: OAUTH2 ClientAuthenticationHandler: No access to
security token
Awesome Li! As far as the code style comment. I'm an IntelliJ person.
Anyone have the templates for that? If not, I'll see about moving over to
Eclipse to do the edits.
doug
O
Li, revision submitted. Cleaned up the code to use Maps, used the Eclipse
formatters, and added a junit test.
Thanks for your help.
doug
On 12/12/11 3:10 PM, "Li Xu" wrote:
> ah, I see, no worry. I can clean up the code style when committing it.
> thanks.
ah, I see, no worry. I can clean up the code style when committing it.
thanks.
Awesome Li! As far as the code style comment. I'm an IntelliJ person.
Anyone have the templates for that? If not, I'll see about moving over to
Eclipse to do the edits.
doug
On 12/12/11 2:50 PM, "Li Xu" wrote:
> Thanks for the patch, Doug! It looks pretty good to me. only a few minor
> thin
Thanks for the patch, Doug! It looks pretty good to me. only a few minor
things I have added to the review.
Thanks!
li
You may need to tell your SVN client to add them to source control
Then create the patch and make sure they are selected. (if you're using
eclipse, that's what I use)
From: daviesd
To: ,
Date: 12/12/2011 11:38 AM
Subject: Re: OAUTH2 ClientAuthenticationHandler: No
Hmmm... I included 2 NEW files in the diff, but they didn't get added to the
review. How do I do this?
doug
On 12/12/11 11:18 AM, "daviesd" wrote:
> I have submitted a revision to the review (3064) that implements the
> OAuth2RequestParameterGenerator class. I look forward to your responses
I have submitted a revision to the review (3064) that implements the
OAuth2RequestParameterGenerator class. I look forward to your responses and
getting this integrated as quickly as possible.
Thanks for the guidance,
doug
On 12/8/11 3:50 PM, "Li Xu" wrote:
> I see. Just a thought, Inject an
We were having the same discussion here. Stayed tune... I have my project
for tomorrow. :)
doug
On 12/8/11 3:50 PM, "Li Xu" wrote:
> I see. Just a thought, Inject an OAuth2RequestParameterGenerator here might
> be helpful...It could provide a function to generate parameter based on
> HttpRequ
I see. Just a thought, Inject an OAuth2RequestParameterGenerator here might
be helpful...It could provide a function to generate parameter based on
HttpRequest. The default implemenation doesn't have to generate any
parameter.
thanks,
li
>
>
I guess my disconnect is that OUR implementation of the GrantRequestHandler
used the security token to PULL OUT the value we needed. In other words our
container had set the security token with trustedJson that held the extra
parameters we needed. Thus when the intial makeRequest happened, the 's
Hi Doug,
Sure, np.
Yes, it's hard to filter the parameter. Maybe all the query parameters as a
first step?
NO need to say sorry... we have all been new to Shindig once before. Let's
still use the same issue and review request to keep track of this. When a
new patch is ready, please just upload the
I agree with Li's suggested approach.
Making the request parameters available on the OAuth2Accessor means they'll
be generally available to all the different handlers/phases of the OAuth2
flow. Plus it doesn't require signature changes on the handler interfaces,
which is nice.
On Thu, Dec 8, 2
Thanks Li. That was my initial implementation (to add something to the
accessor). However I backed off because I was trying to be the least
intrusive.
Mike and I will go back and see if there is a better way to do this. Just
not sure how you'd make it generic enough to figure out what request
p
Hi, Mike
Thanks for the usecase. It makes sense to me and it could be quite common
to have vendor specific extension parameters. Just think we may need a
generic way to support that for both authorization endpoint and token
endpoint...
Here's a suggestion...
Pass in real request parameters from H
Hi Li.
Doug and I work at the same organization.
We have an application where users authenticate and are associated with an
organization. There is contextual data that our application puts in
Shindig's SecurityToken via it's trustedJson field. One of these fields is
an identifier for the user's
Doug,
Thanks for submit the review request.
Would you please elaborate your usecase why you need to pass additional
parameter to authorization url? would like to understand how common is the
usecase.
thanks,
li
Thanks, Doug! Please remove the demo code from the patch and create a
review request. Thanks!
li
indig ,
Date: 12/07/2011 12:08 PM
Subject: Re: OAUTH2 ClientAuthenticationHandler: No access to
security token
I¹m not 100% sure of how I submit a patch as a non-committer, but I¹ve
created
https://issues.apache.org/jira/browse/SHINDIG-1672
with a proposed patch for this
I¹m not 100% sure of how I submit a patch as a non-committer, but I¹ve
created
https://issues.apache.org/jira/browse/SHINDIG-1672
with a proposed patch for this issue.
Essentially it passes the HttpRequest object along to the
GrantRequestHandler so that it has access to things like the security
I see where my misunderstanding was. I thought the
ClientAuthenticationHandler was called to set authentication values before
the authorization code request, based on this link (it¹s misleading).
http://docs.opensocial.org/display/OSD/Client+Authentication
> "Allows shindig developers to inject
Argh! Not so great. The security token seems to be null even though I see
the st param on the makeRequest call.
I don¹t see any way inside of my ClientAuthenticationHandler to get at the
original request object or the security token. This presents a bit of a
problem for me, since we need to pas
24 matches
Mail list logo
