Oh, and the security token you mention is an 'anonymous' security token. Thus it's probably not going to play well with the AppData service.
On Mon, Nov 8, 2010 at 3:50 PM, Paul Lindner <[email protected]> wrote: > I'm really happy to see this work. Layering userprefs on top of AppData is > something that I've wanted to see for a long time. > > > On Mon, Nov 8, 2010 at 9:45 AM, Justin Wyllie > <[email protected]>wrote: > >> >> >> >> >> >> Hi Peter >> As a quick response.. >> As I understand you have shindig.DefaultUserPrefStore.prototype.savePrefs >> which is called. >> Assuming you get the name/value pair out of some params in that function >> as I understand you you now plan to use the appData service to save the >> prefs. Therefore you would need to call this service from within savePrefs. >> I guess you could do this either by the Rest api or the JSON-RPC one: >> The notes for the Rest one: At this url >> http://wiki.opensocial.org/index.php?title=Developer's_Guide_REST there >> is a section 'Creating AppData items'. I guess you can skip the bit about >> the discovery document since you already know the url. >> Or by JSON-RPC. I think you can include the necessary libraries in your >> container page in the line that looks like this: >> http://justin.sociallearndevig.open.ac.uk/gadgets/js/core:rpc.js?c=0&debug=1&nocache=1. >> I'm not sure but I think if you add gadgets (as in core:gadgets:rpc:) to >> this you could then construct an appData request in the same way you would >> in a gadget. >> Which one are you using? >> As far as malformed tokens go - whichever way you are doing the request if >> you have a flag 'allow_anonymous_token' => false, set in the config then it >> needs to be authenticated. >> In our case we have not yet set up oAuth. If you stick a valid security >> token on either the end of the JSON-RPC request or the Rest request that >> worked for us. You should be able to get the token in your >> shindig.DefaultUserPrefStore.prototype.savePrefs as there seems to be. >> magically, an element f which gives you a handle for the iframe of the >> gadget from which you can get a security token - or just borrow one for >> testing. >> I don't know if this adds anything to what you've done >> regards >> Justin >> >> >> >> >> > Date: Mon, 8 Nov 2010 17:05:50 +0100 >> > From: [email protected] >> > To: [email protected] >> > Subject: Persistence of userPrefs >> > >> > Hi all, >> > >> > After getting my UserPref-Dialog to work (see other thread), I'm now >> > trying to get the Persistence of my UserPref, using the AppDataService >> > as proposed e.g. in [1]. I have successfully set up my AppDataService by >> > implementing the AppDataService interface and binding it to the >> > AppDataService.class in my AbstractModule. >> > My intention is to use the AppDataService to e.g. set the >> > UserPreferences upon clicking the "save" Button in the rendered >> > Gadget-Preference-Panel. I understand that I need to implement my own >> > UserPrefStore (in shindig-container.js) and the Function >> > "shindig.DefaultUserPrefStore.prototype.savePrefs" is indeed called. >> > However I'm currently missing the connection to my AppDataServce in the >> > backend. I tried using the "osapi.appdata.update()" function as proposed >> > in [1] but sadly my AppDataService isn't called. >> > >> > I'm getting an error message related a "malformed security token" (is >> > this a good "sign"?): >> > >> > > 08.11.2010 17:02:33 >> org.apache.shindig.auth.AuthenticationServletFilter doFilter >> > > INFO: Malformed security token -1:-1:*::*:0:default >> > > org.apache.shindig.auth.SecurityTokenException: Malformed security >> token >> > > at >> org.apache.shindig.auth.BasicSecurityTokenCodec.createToken(BasicSecurityTokenCodec.java:82) >> > > at >> org.apache.shindig.auth.DefaultSecurityTokenCodec.createToken(DefaultSecurityTokenCodec.java:68) >> > > at >> org.apache.shindig.auth.UrlParameterAuthenticationHandler.getSecurityTokenFromRequest(UrlParameterAuthen >> > > ticationHandler.java:56) >> > > at >> org.apache.shindig.auth.AuthenticationServletFilter.doFilter(AuthenticationServletFilter.java:84) >> > > at >> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) >> > > at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) >> > > at >> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >> > > at >> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) >> > > at >> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) >> > > at >> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440) >> > > at >> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) >> > > at >> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) >> > > at >> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) >> > > at org.mortbay.jetty.Server.handle(Server.java:326) >> > > at >> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) >> > > at >> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943) >> > > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) >> > > at >> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) >> > > at >> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) >> > > at >> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) >> > > at >> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) >> > >> > So does this mean I am on the right way and just need to correct >> > something regarding the security token or am I confusing some key >> > concept of shindig in this aspect? >> > >> > -Peter >> > >> > [1] http://www.mail-archive.com/[email protected]/msg01938.html >> >> >> > > > > -- > Paul Lindner -- [email protected] -- linkedin.com/in/plindner > -- Paul Lindner -- [email protected] -- linkedin.com/in/plindner
