shindig-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Wyllie <justinwyl...@hotmail.co.uk>
Subject RE: Persistence of userPrefs
Date Mon, 08 Nov 2010 17:45:46 GMT





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: rothenpieler@itm.uni-luebeck.de
> To: users@shindig.apache.org
> 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/dev@shindig.apache.org/msg01938.html

 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message