-
There's a MySpace-side to your App; it is, I'm assuming, the source of the Consumer Key and Secret your C# app is using to access data. That MySpace-side App must be installed on a user's profile for the Key/Secret pair to work in accessing their data. Installing the App gives the App the required permission to get past the ...
-
Scoot's right about that -- you can't ask for information from an arbitrary user using an Id -- that user must either be the OWNER, VIEWER, or one of their Friends (if they are a friend, you can retrieve the friend data, then pull out the specific user with the (friendData).getUserById(uid) function).
Otherwise, nope, you can't ...
-
Well, the way PostTo was implemented is kind of interesting in that regard. I'm going to go at a complete tangent at this point, so feel free, who-ever is reading this, to ignore.
As far as messaging and bulletins, instead of them coming from the App or the App's Profile (since the App itself is a MySpace user, and can send messages, ...
-
It's not a widely known or publicized fact, but the reason why external CSS is banned is because it can contain scripts, and, obviously, MySpace doesn't want that. Most browsers are set or can be set to block scripts run from CSS files (since pretty much the only reason to have scripts in CSS files is to hide them because they're doing ...
-
gadgets.io.makeRequest is 0.7 OpenSocial, container.get().makeRequest is old, deprecated, 0.6 OpenSocial.
Otherwise, I believe they are the same (which means the the old 0.6 code is slightly broken since under the old specs, it's return was slightly different). But use gadgets.io.makeRequest, as 0.6 might not be around much longer, and I ...
-
Instead of using an HTML Form's action attribute, you'd use javascript and make use of the gadgets.io.makeRequest function -- unlike form action, this function is asychronuous (AJAX) to POST or GET querystring your form's fields, so the browser doesn't actually navigate anywhere, and no redirection is necessary.
It's a bit ...
-
Using MakeRequest is asynchronuous; it comes from App, and never leaves your App (there is no redirect at all), the browser doesn't change addresses at all, so I'm unsure where your problem is...
-
I know that they're working on extending the PostTo (messages, bulletins, etc.) functionality to the external RESTful API, but I also think they're being cautious about it, given the abuse already done with client-side Javascript already. Just to note.
-
...Nope, that doesn't seem right at all. Unless they changed things (which I know some developers wanted), but that's a rather serious threat to viewer privacy if any ol' App can snag personal data without installation (i.e. permission).
This only happens intermittenly (I missed that the first time)? That tells me it's an error ...
-
As per OpenSocial specs, only VIEWER can be updated -- to update OWNER, you'd update VIEWER data when OWNER and VIEWER are the same user. You also don't have to go through the extra step of retrieving the UserId to do a data update (I assume you're doing that because updates to opensocial.[..].OWNER don't work?), just use the ...