> WRT the first question, wouldn't the 3rd party site need a signature in > order to trust the owner/viewer info?
Hi John: Agreed on your point above. I'm mainly thinking from a container implementers' point of view - mainly in terms of security. Assuming that if I'm implementing a container/proxy, what should the proxy do when it sees opensocial_* params for an UNSIGNED makeRequest() call? Should it just pass them along to the 3rd party site? I'm mainly thinking of a case where in a malicious user forges a signed request by passing (false) signed parameters in an unsigned request It's pretty clear in the case of SIGNED requests that the proxy is supposed to strip out the opensocial_* and oauth_* params before the signing operation. Thanks Chak On 3/7/08 10:33 AM, "John Panzer" <[EMAIL PROTECTED]> wrote: > The intent is that the container only provides signatures for opensocial_* > things it can vouch for. A container can't vouch for an arbitrary parameter > sent from gadget JS, so that sounds like a bug. > > WRT the first question, wouldn't the 3rd party site need a signature in > order to trust the owner/viewer info? > > On Fri, Mar 7, 2008 at 10:16 AM, Chak Nanga <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> Need some clarification on what opensocial_* params, if any, the >> container/proxy is supposed to append to the outgoing URL in response to >> makeRequest(UNSIGNED) calls? If it does not append the owner/viewer id >> params to the outgoing UNSIGNED request, how does the 3rd party site know >> the owner/viewer info if it needs to fetch user specific data? >> >> It¹s fairly clear that the proxy is supposed to add >> opensocial_owner/viewer/app_id params and oauth_* params. >> >> Also, I noticed that the current proxy code does not remove opensocial_* >> and >> oauth_* if they are present in the incoming makeRequest() calls. I can >> file >> a JIRA issue, if this is indeed a bug. >> >> Thanks >> Chak >> >>
