I was trying to use the GadgetSpec class to retrieve some metadata fields
from xml I passed into the constructor. However, this failed with
³/OAuth/Service/Request is required² on the ModulePrefs OAuth section. Are
these fields really required? I thought they were optional and only used to
cached, but the common container never purges the cache. It
wouldn't be hard to check for whether the container is in debug mode and
disable the caching. Unless we want to introduce a separate caching param
for the container as well...
On Thu, Oct 25, 2012 at 9:57 AM, daviesd davi
I have a scenario where a gadget is rendered from a known url, dropbox lets
say. If later on if I remove the gadget from dropbox and my container tries
to re-render it I get the message
Unable to retrieve spec for
https://dl.dropbox.com/u/x/gadgets/oauth2.xml. HTTP error 404
Which seems to
Here's what we do.
container.rpcRegister(requestNavigateTo, function
requestNavigateTo(rpcArgs, view, params) {
var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY],
url = site.getActiveSiteHolder().getUrl(),
renderParams = {};
If I wanted to implement my own Authority implementation (replacing
BasicAuthority) it appears that I would have to completely override the
DefaultGuiceModule and just change one line to bind to my implementation.
However, this means every time I upgrade artifacts I have to make sure the
default
the DefaulyGuiceModule with a module that
does you binding.
-Stanton
On Sep 4, 2012 9:47 AM, daviesd davi...@oclc.org wrote:
If I wanted to implement my own Authority implementation (replacing
BasicAuthority) it appears that I would have to completely override the
DefaultGuiceModule and just change one
.
-Stanton
On Sep 4, 2012 9:47 AM, daviesd davi...@oclc.org wrote:
If I wanted to implement my own Authority implementation (replacing
BasicAuthority) it appears that I would have to completely override the
DefaultGuiceModule and just change one line to bind to my implementation.
However
the auth request, we would have a way to do it
before a render. It certainly would need more work, but it's a start.
On Wed, Aug 22, 2012 at 2:17 PM, daviesd davi...@oclc.org wrote:
Does this
http://docs.opensocial.org/display/OSD/Fixing+OAuth+in+Core+Gadget+Spe
c
Come into play at all
with the
oauth callback urls that are used if they aren't provided in the db (set to
null).
doug
On 8/1/12 4:55 PM, Henry Saputra henry.sapu...@gmail.com wrote:
Doug,
Did you resolve the issue with rpc endpoint?
- Henry
On Wed, Aug 1, 2012 at 1:50 PM, daviesd davi...@oclc.org wrote:
Looks
I just recently noticed a behavior with the rpc interface that I have
discovered in the 11th hour and we are ready to rollout, so any input asap
is appreciated.
Shindig at some point makes an rpc call back to itself for listMethods. I
thought this use to happen upon startup, but I might be
endpoints?
- Henry
On Tue, Jul 31, 2012 at 8:03 AM, daviesd davi...@oclc.org wrote:
I just recently noticed a behavior with the rpc interface that I have
discovered in the 11th hour and we are ready to rollout, so any input asap
is appreciated.
Shindig at some point makes an rpc call back
+1 (non-binding)
The two issue I needed (SHINDIG-1799 SHINDIG-1812) are working for me.
BTW... Not sure why 1799 doesn't show up in your fixed list, but I show it
as being fixed after beta2.
doug
On 7/25/12 10:56 PM, Ryan Baxter rbaxte...@apache.org wrote:
Hi,
We solved 19 issues:
,
There has been an issue identified on the private list that is
blocking the release. The fix should be checked in early next week
and I will kick off a beta 3 RC right after that.
-Ryan
On Fri, Jul 20, 2012 at 2:57 PM, daviesd davi...@oclc.org wrote:
Ideas when beta3 is coming? I know
Ideas when beta3 is coming? I know there was talk about it earlier in the
month. I¹d love to get a beta3 before too many more changes go in, since
I¹m really only interested in 2 things that got fixed post beta2, and I¹d
hate to have to do the amount of work I had to do to get from beta1 to
. Will that work for you?
-Ryan
From: daviesd davi...@oclc.org
To: dev@shindig.apache.org,
Date: 06/25/2012 06:12 PM
Subject:Re: Horoscope gadget and the common container
Ok, I will retest with your patch in the morning.
Ryan... You're not even gonna like my
I noticed that the horoscope gadget is not working in the common container
anymore. I see the following error in the javascript console.
NetworkError: 400 Invalid url parameter -
http://localhost:8080/gadgets/makeRequest?url=http%3A%2F%2Fapi.tarot.com%2Fa
:47 PM, Dan Dumont ddum...@us.ibm.com wrote:
Are you able to set a debug point in the makeRequest servlet to see where
the exception is being thrown? Do you get any server stack traces?
From: daviesd davi...@oclc.org
To: shindig dev@shindig.apache.org,
Date: 06/25/2012 02:37 PM
Ya, I went back and tested on beta1 and it doesn't work there either, so
perhaps I won't worry about it.
On 6/25/12 3:23 PM, daviesd davi...@oclc.org wrote:
Ya, it's complaining about the %up_uid% parameter.
http://feeds.tarot.com/f/ws/dh/igoogledh/locale/en/timezone/-4/uid/%up_uid%?pa
,
-Stanton
From: daviesd davi...@oclc.org
To: dev@shindig.apache.org,
Date: 06/25/2012 17:18
Subject:Re: Horoscope gadget and the common container
Thanks Ryan. I had that set on my container but not on my shindig trunk.
So I was able to reproduce the problem now
Adam,
So I suppose sometime in the future this would be something shindig might
expose? (even though it's not in the spec)
I guess rather than boxing myself in, I'm just wondering if the shindig
project did expose an api for this would it do it like current apis and
provide a REST and RPC
provided or
homebrew this admin api myself.
doug
On 6/19/12 2:38 PM, daviesd davi...@oclc.org wrote:
Thanks Stanton. So it sounds like you were saying to roll my own on this and
not try to leverage off of any existing shindig handlers? I certainly agree
on the security aspect. This would
to not be
plaintext on the wire. That's my first thought, but I'm no security
expert. :)
Maybe I'm missing the point altogether...
Thanks,
-Stanton
From: daviesd davi...@oclc.org
To: shindig dev@shindig.apache.org,
Date: 06/18/2012 16:28
Subject:Adding additional APIs
I am still having issues.
I rebuilt everything with secure tokens enabled, but skipped tests so that
the build would complete. Now the listMethods call succeeds, but then the
metadata call fails with org.apache.shindig.auth.SecurityTokenException:
Invalid security token
Guys, I apologize for the confusion.
Ok, tested in my container. There needs to be one more fix.
The container needs to be passed into retrieveServices and used instead of
default. We define our own container in addition to default. Not sure why
it doesn¹t find default, but it was throwing an
I'm a little bit confused on this. I'm trying it and I'm getting an
exception (it could be because I provide my own
BlobCrypterSecurityTokenCodec and maybe I have some work to do here).
When DefaultServiceFetcher creates an AnonymousSecurityToken and then calls
encodeToken, won't that throw an
;
}
Thanks,
doug
On 6/14/12 12:29 PM, daviesd davi...@oclc.org wrote:
I'm a little bit confused on this. I'm trying it and I'm getting an exception
(it could be because I provide my own BlobCrypterSecurityTokenCodec and maybe
I have some work to do here).
When DefaultServiceFetcher
is the new list of issues fixed in the beta:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=
project+%3D+SHINDIG+AND+resolved+%3E%3D+2012-03-26
Vote open for 72 hours.
[ ] +1
[ ] +0
[ ] -1
-Ryan
From: daviesd davi...@oclc.org
To: dev@shindig.apache.org
Nice patch. I had overriden
AnonymousAuthenticationHandler.getSecurityTokenFromRequest to accomplish the
same thing. Now I can back that out.
doug
On 6/13/12 1:53 PM, siever...@gmail.com siever...@gmail.com wrote:
LGTM
http://codereview.appspot.com/6306074/
on the the daily snapshots but have been on beta1 for quite a while, so
I didn¹t even realize no new artifacts were being generated.
doug
On 6/11/12 2:34 PM, daviesd davi...@oclc.org wrote:
I¹m having issues again getting the latest maven artifacts (I¹ve been using
beta1 for a while now
Not to get greedy about all the stuff I need for beta2, but... :)
Ryan, is this going in before you do the beta2 rebuild?
Thanks for all your help on getting these things resolved so quickly. I'm
still testing this fix, but having maven repo issues this morning, and I was
trying to apply the
I¹m having issues again getting the latest maven artifacts (I¹ve been using
beta1 for a while now). This is the repository I¹m using (for both beta and
snapshot)
https://repository.apache.org/content/groups/public/org/apache/shindig
However the snapshots don¹t seem to have been updated since
The fix for SHINDIG-1732 introduces a bug with the oauth2 token expires and
issue times (or at least a documentation change). The time stored in
OAuth2Token use to be in seconds (and is documented that way). Now it¹s
storing them in milliseconds in TokenAuthorizationResponseHandler. This
causes
like this check is not right !scriptEls i
scriptEls.length so the container always set to default
- Henry
On Thu, Jun 7, 2012 at 12:37 PM, daviesd davi...@oclc.org wrote:
The for loop in init.js is broken.
If I change
for(var i = 0; !scriptEls i scriptEls.length; i
I had not opened one. I was waiting for Ryan's response to my follow-up.
doug
On 6/8/12 9:16 PM, Henry Saputra henry.sapu...@gmail.com wrote:
Hi Doug, do you have a JIRA opened for this issue?
- Henry
On Wed, Jun 6, 2012 at 9:52 AM, daviesd davi...@oclc.org wrote:
Some changes were
Ryan,
I'd love to +1 but I'm still having some integration issues (I'm composing a
separate email for the GroupId issue). I'm also getting the dreaded HTTP
Status 401 - Malformed security token %st%Invalid security token %st% I
think when a gadget makes a request to the container (Flash gadgets
In beta1 I use to see the following flow.
Request the javascript using container=oclc
http://ocwms.worldkat.qa.oclc.org/opensocial/gadgets/js/oclccontainer:userpr
efsui:rpc.js?nocache=1c=1debug=1container=oclc
The iframe request would then look as follows
, Henry Saputra henry.sapu...@gmail.com wrote:
Seems like the iframe URL returned from the metadata call gets the
wrong container.
Doug, could you debug in the DefaultIframeUriManager.buildUri what is
the container returned?
- Henry
On Thu, Jun 7, 2012 at 9:30 AM, daviesd davi...@oclc.org
with this.
- Henry
On Wed, Jun 6, 2012 at 9:52 AM, daviesd davi...@oclc.org wrote:
Some changes were made to GroupId between 2.5-beta1 and 2.5-beta2 that
are
affecting me.
GroupId.Type changed from this
all, friends, self, deleted, groupId;
To this
objectId(0), self(1), friends(2), all
not contain the
expected pattern
/.*gadgets\/js\/.*container.*[.]js.*[?]c=1(|$).*/
- Henry
On Thu, Jun 7, 2012 at 9:30 AM, daviesd davi...@oclc.org wrote:
In beta1 I use to see the following flow.
Request the javascript using container=oclc
http://ocwms.worldkat.qa.oclc.org
-1 until SHINDIG-1794 is fixed (if deemed necessary for release).
doug
On 6/6/12 9:39 AM, Ryan J Baxter rjbax...@us.ibm.com wrote:
Hi All,
I finished the 2.5.0-beta2 release last night, here is all the info.
We solved 52 issues:
That first link does not work for me (IssueNavigator). I get
The selected filter is not available to you, perhaps it has been deleted or
had its permissions changed.
Also, do you know if SHINDIG-1787 made it in?
doug
On 6/6/12 9:39 AM, Ryan J Baxter rjbax...@us.ibm.com wrote:
Hi All,
I
Some changes were made to GroupId between 2.5-beta1 and 2.5-beta2 that are
affecting me.
GroupId.Type changed from this
all, friends, self, deleted, groupId;
To this
objectId(0), self(1), friends(2), all(3);
We had extended AppDataService to support a groupId of @institution
(something
Does anyone (Dan?) have any idea why this code
container.rpcRegister(requestNavigateTo, function
requestNavigateTo(rpcArgs, view, params) {
var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY],
url = site.getActiveSiteHolder().getUrl(),
renderParams =
Doh! It¹s Friday. I guess I should have described the symptoms. I end up
with a gadget with no content area (collapsed).
On 6/1/12 10:50 AM, daviesd davi...@oclc.org wrote:
Does anyone (Dan?) have any idea why this code
container.rpcRegister(requestNavigateTo, function
actually in the site? Maybe the
adjustHeight call is not working / the CSS for the site element needs to
change.
[1] https://issues.apache.org/jira/browse/SHINDIG-1766
[2] https://issues.apache.org/jira/browse/SHINDIG-1767
-Ryan
From: daviesd davi...@oclc.org
To: shindig
in
SiteHolder.dispose that are causing the problem here. While I think using
a buffering element would solve the problem, the API (at this point)
indicates the buffering element is optional, so everything should work
without it.
-Ryan
From: daviesd davi...@oclc.org
To: dev
I would agree. I'm scared to death with the number of changes that have been
made between the beta we are using and the next one. :)
On 5/18/12 10:06 AM, Franklin, Matthew B. mfrank...@mitre.org wrote:
There are quite a few of us Shindig users who are unable to depend on SNAPSHOT
releases or
.
doug
On 4/26/12 6:35 PM, Ryan J Baxter rjbax...@us.ibm.com wrote:
Doug, I have not tried this in a while, but last time I did OAuth was not
required.
-Ryan
From: daviesd davi...@oclc.org
To: shindig dev@shindig.apache.org,
Date: 04/26/2012 06:13 PM
Subject:Does data
Henry,
Thanks. I tried that and I still had trouble. However if I switch to
os:DataRequest method=people.get userId=@viewer/
Then it works without signing.
doug
On 4/27/12 2:09 PM, Henry Saputra henry.sapu...@gmail.com wrote:
I think you can workaround this by instead of using @viewer in
A quick yes or no question which is plaguing us right now.
Does an oauth2 enabled gadget ALWAYS have to do the popup oauth2 dance? In
other words, there is no way to make a service call without first having a
user click the authorization url and the authorization server redirecting
the browser
Thanks. Working now.
On 3/30/12 2:59 PM, Paul Lindner lind...@inuus.com wrote:
weird, I went back and checked and it wasn't listed as released.
Tried now, and will check back in a while to see if it's properly working.
On Fri, Mar 30, 2012 at 6:26 AM, daviesd davi...@oclc.org wrote
, which may be convenient if you are using
Jetty to run you app :)
http://docs.codehaus.org/display/JETTY/Asynchronous+Proxy+Servlet
-Ryan
From: daviesd davi...@oclc.org
To: dev@shindig.apache.org,
Date: 03/26/2012 04:58 PM
Subject:Re: Shindig running on different
+1 (tested with our project and all is well)
On 3/26/12 2:25 PM, Henry Saputra henry.sapu...@gmail.com wrote:
Hi All,
Paul Lindner has prepared a release candidate for Shindig 2.5.0-beta1.
Staging repo:
https://repository.apache.org/content/repositories/orgapacheshindig-114/
SVN
the javascript. Probably my misunderstanding of CORS and XHR. Any
suggestions on how to best implement this? Or perhaps I'm not gonna get off
easy with just a few lines of code. :)
doug
On 3/22/12 5:19 PM, daviesd davi...@oclc.org wrote:
Again... Thanks Stanton for the quick response. Ok, I'll
Ok, one step forward. If I add
servletResponse.addHeader(Access-Control-Allow-Headers, Content-Type);
It starts working and the gadget renders. Cool. But then the first
makeRequest from a gadget seems to be having difficulty.
doug
On 3/26/12 3:59 PM, daviesd davi...@oclc.org wrote:
Started
try to tackle this but
if it's on someone's roadmap I'll live with the proxy solution in the
meantime.
doug
On 3/26/12 4:38 PM, daviesd davi...@oclc.org wrote:
Ok, one step forward. If I add
servletResponse.addHeader(Access-Control-Allow-Headers, Content-Type);
It starts working
to implement CORS for the
JsonRpcServlet.
Regards,
-Stanton
From: daviesd davi...@oclc.org
To: dev@shindig.apache.org,
Date: 03/22/2012 17:08
Subject:Re: Shindig running on different domain than container
REVISITED
Hi Stanton,
So is your earlier statement about
About a year ago there was a discussion about shindig running on a different
domain than the container.
http://permalink.gmane.org/gmane.comp.web.shindig.devel/6824
Up till this point we have been running our shindig servers and our
container webapps on the same domain. We¹d like to move away
at it. If he
doesn't get to it by the end of the day I will commit it.
-Ryan
From: daviesd davi...@oclc.org
To: dev@shindig.apache.org, Paul Lindner lind...@inuus.com,
Cc: Ryan Baxter rbaxte...@gmail.com
Date: 03/20/2012 11:04 PM
Subject: Re: Review Request: Fix
Thanks Ryan. How do I go about getting a committer to commit this? I was
hoping Paul would review before then, but I'd love to see this get in before
the next 2.5 beta.
doug
On 3/19/12 9:09 AM, Ryan Baxter rbaxte...@gmail.com wrote:
should be selected? I think the method modifiers will give me enough
details to determine this. I imagine the interface or abstract ones can be
thrown out. Ideas?
doug
On 3/14/12 10:39 AM, daviesd davi...@oclc.org wrote:
Paul,
I¹m trying to track down this LocalCache problem
up with
java.lang.IllegalArgumentException: duplicate key: value
If I rollback JsonUtil to the version before this commit I no longer have
the issue.
Ideas?
doug
On 3/5/12 5:33 PM, daviesd davi...@oclc.org wrote:
I just got back from vacation and pulled down today¹s 2.5.0. Some of my unit
Is there a way for a feature to include css? I noticed minimessage does
this, but messily through container.js. I¹d like to have a feature.css that
sits along side the feature.xml and feature.js. Any ideas are appreciated.
Doug
anything I think
- Henry
On Tue, Mar 6, 2012 at 1:03 PM, daviesd davi...@oclc.org wrote:
Ya it's the difference between insecure and secure. ?If I use insecure
tokens it works. ?If I switch to secure (our default) it gets this exception
when encoding the token.
doug
On 3/6/12 3:29
is not working well. I
will put up the patch to fix this.
- Henry
On Wed, Mar 7, 2012 at 8:11 AM, daviesd davi...@oclc.org wrote:
Henry,
I changed our security token implementation to extend AbstractSecurityToken
instead of just implementing SecurityToken. ?No difference. ?As I said, if I
Yep. Works. Thanks!
On 3/7/12 2:22 PM, Henry Saputra henry.sapu...@gmail.com wrote:
Done, could you try the fix by pulling from trunk?
- Henry
On Wed, Mar 7, 2012 at 10:45 AM, daviesd davi...@oclc.org wrote:
Thank you. I've been banging my head on this all morning. ?Now if I can get
Paul,
I think this has to do with version 1290973 of JsonUtil.java which you made
changes to. If I roll this file back to version 950407 my tests work again.
Ideas? I¹m banging my head against the wall on this one.
doug
On 3/5/12 5:33 PM, daviesd davi...@oclc.org wrote:
I just got back
Henry,
I¹m having issues with the fix for SHINDIG-1719. The stacktrace looks as
follows:
Mar 6, 2012 3:04:20 PM
org.apache.shindig.gadgets.servlet.GadgetsHandlerService createErrorResponse
WARNING: Error handling request:
java.lang.UnsupportedOperationException: Unsupported function:
On Tue, Mar 6, 2012 at 12:13 PM, daviesd davi...@oclc.org wrote:
Henry,
I¹m having issues with the fix for SHINDIG-1719. ? The stacktrace looks as
follows:
Mar 6, 2012 3:04:20 PM
org.apache.shindig.gadgets.servlet.GadgetsHandlerService createErrorResponse
WARNING: Error handling request
reproduce this?
- Henry
On Tue, Mar 6, 2012 at 12:13 PM, daviesd davi...@oclc.org wrote:
Henry,
I¹m having issues with the fix for SHINDIG-1719. ? The stacktrace looks as
follows:
Mar 6, 2012 3:04:20 PM
org.apache.shindig.gadgets.servlet.GadgetsHandlerService createErrorResponse
I just got back from vacation and pulled down today¹s 2.5.0. Some of my
unit tests that derive from AbstractLargeRestfulTests are failing deep in
the bowels of LocalCache.java. Specifically I get a
java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException:
duplicate key: value
To: dev@shindig.apache.org dev@shindig.apache.org,
Date: 02/21/2012 05:33 PM
Subject:RE: User Prefs Panel Brainstorm
-Original Message-
From: daviesd [mailto:davi...@oclc.org]
Sent: Tuesday, February 21, 2012 4:44 PM
To: shindig
Subject: User Prefs Panel Brainstorm
I¹m working on this user preferences ui. I have the need to listen for a
view change request. For example my chrome has a dropdown with all the
views supported by the gadget listed as well as a preferences view added
(even if the gadget doesn¹t support it). Now I want to know when the
I¹ve started to implement a User Prefs panel. I¹m thinking of implementing
it as a feature. My problem is I¹m flip flopping between it being a
container feature v.s. a gadget feature. There are benefits and drawbacks
to both. I kind of like having it as a gadget feature. It could provide a
Li (and anyone else that is interested). I've reopened SHINDIG-1672 with a
more specific usecase. As I started using the the auth_code/access_token
flow I discovered that what was previously implemented didn't fully meet my
needs.
I've tested this fix locally and it does what I need it to do.
On 1/27/12 3:25 PM, daviesd davi...@oclc.org wrote:
I¹m just wondering if it¹s as easy as having BasicHttpFetcher transfer the
HttpRequest params to the httpMethod params. Was it an oversight or were they
not copied for a reason?
doug
On 1/27/12 2:23 PM, daviesd davi...@oclc.org wrote
Dan,
I hadn¹t updated my shindig artifacts in about a week. There were some
changes to GadgetSite that broke me (my chrome around gadgets). Hopefully
you can point me to substitutes.
gadgetSite.currentGadgetEl_ - yes I realize I shouldn¹t have been using the
private member, but I need access
Back in December Li Xu helped me get a patch submitted that added the
OAuth2RequestParameterGenerator interface. It is meant to be implemented if
you want to pass additional parameters along to the various oauth2 flow
requests.
I¹ve since noticed an issue with this. The parameters I add get
I¹m just wondering if it¹s as easy as having BasicHttpFetcher transfer the
HttpRequest params to the httpMethod params. Was it an oversight or were
they not copied for a reason?
doug
On 1/27/12 2:23 PM, daviesd davi...@oclc.org wrote:
Back in December Li Xu helped me get a patch submitted
I have a gadget that was using
var moduleId = new gadgets.Prefs().getModuleId();
To get the current moduleId (siteId) of the gadget so that it could retrieve
userprefs
osapi.userprefs.get( { siteId : moduleId } )
This is now return 0 instead of the id I have for the element the gadget was
the bits, otherwise they return 0 as they always
have.
I'm curious how you got numbers other than 0. Especially for the security
token, moduleId was always 0 in shindig.
From: daviesd davi...@oclc.org
To: shindig dev@shindig.apache.org,
Date: 01/23/2012 12:51 PM
Subject
of the
moduleId rather than the siteId. The moduleId is baked in the token and
not something one could spoof with firebug.
From: daviesd davi...@oclc.org
To: dev@shindig.apache.org,
Date: 01/23/2012 01:34 PM
Subject:Re: getModuleId
In pref.js shindig was setting the Prefs
opinion, the siteId is a purely container piece
of information.
why do you need to get it inside the gadget?
From: daviesd davi...@oclc.org
To: dev@shindig.apache.org,
Date: 01/23/2012 02:57 PM
Subject:Re: getModuleId
I agree on everything you just stated.
So my
...@us.ibm.com wrote:
Hrmm...
I don't know if you'll be able to do this anymore until you hook up the
moduleId support.
From: daviesd davi...@oclc.org
To: dev@shindig.apache.org,
Date: 01/23/2012 03:08 PM
Subject:Re: getModuleId
Like I said... An edge case
I hate to be a pest, but does anyone have an update on this? I¹m still only
seeing 12/26 as the latest artifact. This is affecting my daily build.
Thanks,
doug
On 1/9/12 1:28 PM, daviesd davi...@oclc.org wrote:
Any ideas on this? I¹m still showing 12/26 as the last builds at
https
Thanks Paul!
On 1/10/12 6:50 PM, Paul Lindner lind...@inuus.com wrote:
JENKINS-12259 caused the build server to do bad things.
I just updated and kicked off a SNAPSHOT build. Should be available in the
next hour or so.
On Tue, Jan 10, 2012 at 3:44 PM, daviesd davi...@oclc.org wrote
Any ideas on this? I¹m still showing 12/26 as the last builds at
https://repository.apache.org/content/groups/public/org/apache/shindig/shind
ig-common/3.0.0-SNAPSHOT/
Also, ideas when we might see a beta5?
doug
On 1/6/12 9:58 AM, daviesd davi...@oclc.org wrote:
Thanks. Are snapshots
Did this change again recently? The ssl certificate error is back.
doug
On 11/7/11 1:45 PM, Ryan J Baxter rjbax...@us.ibm.com wrote:
I have been seeing SSL exceptions being thrown relating to certificates
not matching in builds from trunk recently. I have traced this back to a
httpclient
I¹ve implemented my own OAuth2Encrypter and wired it up. However, I never
see the secret being encrypted in my persistent store. I noticed
OAuth2TokenPersistence has a encryptedSecret (and encryptedMacSecret), but
they don¹t really seem to serve any purpose. When my persister¹s
I have a question about the Oauth 2.0 popup flow. I¹m looking at OAuth¹s
1.0 flow, because I¹m not seeing corresponding documentation for 2.0.
http://shindig.apache.org/shindig-1.1.x/shindig-features/jsdoc/symbols/gadge
ts.oauth.Popup.html
Anyway... 1 of my questions is... WHO closes the popup
I understand that OAuth2Cache provides a mechanism for implementing a cache
that the OAuth2Store uses to limit requests to the OAuth2Persister.
However, if my OAuth2Persister implementation uses JPA or some other
persistence model that already has caching built-in, the OAuth2Cache is
redundant and
without knowing all the variables in your production
environment. I can say that from my personal experience (deploying shindig
into a clustered environment) it was necessary to implement more robust
caching of the OAuth2Accessor.
On Tue, Dec 13, 2011 at 10:30 AM, daviesd davi...@oclc.org
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 leeg...@gmail.com wrote:
ah, I see, no worry. I can clean up the code style when committing it.
thanks.
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 leeg...@gmail.com wrote:
I see. Just a
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 davi...@oclc.org wrote:
I have submitted a revision to the review (3064) that implements the
OAuth2RequestParameterGenerator class. I look forward
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 leeg...@gmail.com wrote:
Thanks for the patch, Doug! It looks pretty good to me. only a
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 leeg...@gmail.com wrote:
ah, I see, no worry. I can clean up the code style when committing it.
thanks.
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
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
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 leeg...@gmail.com wrote:
I see. Just a thought, Inject an OAuth2RequestParameterGenerator here might
be helpful...It could provide a function to generate parameter based
1 - 100 of 174 matches
Mail list logo
