I just posted this to the gfc mailing list, but since it relates to my earlier post on google friend connect authentication, I'll recap here;
At the moment it's not possible to use a makreRequest call back to your server with the id and general data for the current vieweing gfc user, through Google's servers using SIGNED authentication. What that would mean is that googles servers guarantees that the data is correct and stamps it in a way, since they recently authenticated the user themselves.
Google _is_ prioritizing this, so we'll probably see a new release of the GFC API's that allows for this quite soon.
But what if you want to get the friend connect user id of the viewer anyway?
Although, having thought about this a bit, a weaker kind of security can be had if you just decide to trust the scripts running in the page.
1) You store your own custom xml file describing your own opensocial gadget on your server
2) You store the page containing the gadget on your own server.
3) When the page is loaded, it first load GFC from google's servers
4) The it tells GFC to load your custom opensocial gadget _through_ googles servers, acting as a proxy.
5) You could in essence generate the xml file containing the widget in a server-side template (ugh!) which contains a unique session cookie you keep track of on the server
6) When the widget snarfs viewer info et,c, and send it back to your server again, through googles server, using makeRequest, it also passes on the magic cookie
7) Then you might be reasonably certain that you haven't been fooled around with.
However, anything coming from the client should be treated with great scepticism, even if cookie is correct, the data collected might have been tempered with, resulting that you associate an action with the wrong user id. Still, I think this is a reasonably safe solution.
Cheers,
PS
At the moment it's not possible to use a makreRequest call back to your server with the id and general data for the current vieweing gfc user, through Google's servers using SIGNED authentication. What that would mean is that googles servers guarantees that the data is correct and stamps it in a way, since they recently authenticated the user themselves.
Google _is_ prioritizing this, so we'll probably see a new release of the GFC API's that allows for this quite soon.
But what if you want to get the friend connect user id of the viewer anyway?
Although, having thought about this a bit, a weaker kind of security can be had if you just decide to trust the scripts running in the page.
1) You store your own custom xml file describing your own opensocial gadget on your server
2) You store the page containing the gadget on your own server.
3) When the page is loaded, it first load GFC from google's servers
4) The it tells GFC to load your custom opensocial gadget _through_ googles servers, acting as a proxy.
5) You could in essence generate the xml file containing the widget in a server-side template (ugh!) which contains a unique session cookie you keep track of on the server
6) When the widget snarfs viewer info et,c, and send it back to your server again, through googles server, using makeRequest, it also passes on the magic cookie
7) Then you might be reasonably certain that you haven't been fooled around with.
However, anything coming from the client should be treated with great scepticism, even if cookie is correct, the data collected might have been tempered with, resulting that you associate an action with the wrong user id. Still, I think this is a reasonably safe solution.
Cheers,
PS
Comments