So far, OS X 10.8.2's Social.Framework works great:
NSURL *requestURL = [NSURL URLWithString:#"https://graph.facebook.com/me/friends"];
SLRequest *fbRequest = [SLRequest requestForServiceType:SLServiceTypeFacebook requestMethod:SLRequestMethodGET URL:requestURL parameters:params];
This properly delivers the list of friends of the me() object. Fine!
However, once I try to make use of Field Expansion, as follows, the request fails with the error:
An active access token must be used to query information about the current user:
[NSURL URLWithString:#".../friends?fields=cover,picture"];
This is surely reasoned by the fact, that the access_token will be appended internally in the Social.framework using st. similar to "?access_token=%#", which will fail in conjunction with the previous ?fields= usage by myself.
So I wonder whether this is actually a bug of the framework, or whether I'm using it wrongly? I'd really be thankful for any helpful information.
After contacting Apple directly, this is clearly the answer:
Add the field expansion tags using the GET parameter variable, instead of adding them to the actual URL:
SLRequest *fbRequest = [SLRequest requestForServiceType:SLServiceTypeFacebook
requestMethod:SLRequestMethodGET
URL:requestURL
parameters:#{#"fields":#"cover,picture"}];
Which is obvious, but I didn't think of that :). I'll let this thread as it is if someone might stumble upon the same problem in future!
Related
The error message is "make sure this cross-domain message is being sent to the intended domain".
This check rule from RSPEC-2819
Authors should not use the wildcard keyword ( *) in the targetOrigin argument in messages that contain any confidential information, as otherwise there is no way to guarantee that the message is only delivered to the recipient to which it was intended.
I assume it demands * cannot be used as targetOrigin, But It still shows warning when I use intended domain as targetOrigin like below:
Please somebody can tell me how to pass this check,
Any help would be appreciated
This rule detects only if a method postMessage is invoked on an object with a name containing window in it. Source code: PostMessageCheck.java. To bypass it, just assign your contentWindow object into different one, like this:
var content = this.elem.contentWindow;
content.postMessage('your message', window.location.origin);
Have faced similar issue in sonarQube. Below fix worked. Just get rid of using window object using directly.
Actual code:
window.parent.postMessage("data", parenturl);
Fix:
var content=window;
content.parent.postMessage("data",parenturl);
I have read quite a few posts and sources now but couldn't find a definite answer.
I'm getting kSecTrustResultRecoverableTrustFailure on my SecTrustEvaluate() call and I would like to figure out why this is so (i.e. I want to figure out where exactly the trust chain validation fails and why). on OSX there seem to be some related function called SecTrustGetResult, but this is deprecated now even on OSX
How can I figure out where the validation fails? i'm fine with using private API's as I'm using this only during debugging to understand what exactly is going on inside.
thanks
Just use SecTrustCopyProperties() after calling SecTrustEvaluate():
SecTrustRef trust = ...;
SecTrustResultType trustResult = kSecTrustResultOtherError;
OSStatus status = SecTrustEvaluate(trust, &trustResult);
if (trustResult == kSecTrustResultRecoverableTrustFailure) {
NSArray * trustProperties = (__bridge_transfer id)
SecTrustCopyProperties(certTrust);
}
trustProperties is an array of dictionaries, one dictionary per cert in the cert chain evaluated. Every dictionary has an entry title, containing the name of the cert and if the cert didn't evaluate, it also contains an entry error containing the error. E.g. if the problem was that the cert has expired, the value of error will be CSSMERR_TP_CERT_EXPIRED.
For some reason that I don't understand, on my development machine can't call to function of a cfc component from a cfajaxproxy.
In my cfm document:
<cfajaxproxy cfc="#Application.CfcPath#.empleado"
jsclassname="ccEmpleado">
This works, and also I can instantiate an object to get all the functions of that cfc component:
var cfcEmpleado = new ccEmpleado();
But, when I try to call a function of that object:
var nb_Empleado = cfcEmpleado.RSEmpeladoNombreBIND(1,1);
Debug complains:
Error: The ID_EMPRESA parameter to the RSEmpeladoNombreBIND function is required but was not passed in.
I got this from Network tab on Chrome and figured out that something is generating an invalid parameter:
http://127.0.0.1/vpa/componentes/empleado.cfc?method=RSEmpeladoNombreBIND&_cf_ajaxproxytoken=[object%20Object]&returnFormat=json&_cf_nodebug=true&_cf_nocache=true&_cf_clientid=41C92098C98042112AE2B3AAF523F289&_cf_rc=0
As you can see, there's a parameter [object%20Object], that is messing around my request, and that's why it fails. I don't why is happening this. Other people has tested this, and it works, but in mine doesn't.
I have Coldfusion 9, Apache, Windows 8. Is is some configuration issue on Coldfusion, or a bug?
I can't tell if this is your error or not, but it might be. This was a problem that we had for awhile. You should consider using explicit names to avoid any confusion. Add the "js" in there.
<cfajaxproxy cfc="cfcEmpleado" jsclassname="proxyEmpleado">
var jsEmpleado = new proxyEmpleado();
I will try to find a link to an article about this very thing.
I'm using the URL::to call to embed a link in an outgoing mail message. What I get when I do this is something like: "baseroot/public/index.php/xxx/yyy".
And yet when I do the same call, for example, within a route call, I get "baseroute/xxx/yyy".
Any idea?
The source of URL::to resides at
http://laravel.com/api/source-class-Illuminate.Routing.UrlGenerator.html#76-98
(linked to from http://laravel.com/api/class-Illuminate.Routing.UrlGenerator.html).
I suggest you add debug printing to your copy and see what values $this->getScheme() and $this->getRootPath() yield. These must be the source of the discrepancy, apparently caused by different this objects.
I had a very similar problem with URL::to('user/123') returning an incorrect value when visiting the homepage vs. another page. After some investigation, in my case it was a matter of case-sensitivity (!) in the request's url. I hope it's somehow related to your mysterious case.
More about my case: URL:to('user/123') gave me different results whether I visited http://localhost/MyApp/public/someurl or http://localhost/Myapp/public/someurl. In the former it gave the correct result http://localhost/MyApp/public/user/123, while the latter gave the wrong result of http://localhost/user/123.
.
From here, less important notes from my investigation, for future Laravel archaeologists. I hope I'm not talking all nonsense. I am new to Laravel, using a local Laravel 4 installation + WAMP on a Windows machine.
UrlGenerator's to() method uses $root = $this->getRootUrl($scheme);. The latter uses $this->request->root();, where request is \Symfony\Component\HttpFoundation\Request.
Request::root() indeed defaults to a wrong value e.g. http://localhost when visiting someurl with the incorrect case.
The culprit is Symfony\Component\HttpFoundation\Request (in vendor\symfony\http-foundation\Symfony\Component\HttpFoundation\Request.php). Its getBaseUrl() calls prepareBaseUrl(), and there the actual logic of comparing the requestUri with the baseUrl is finally performed.
For the few archaeologists still following, in my case the $baseUrl was /MyApp/public/index.php while the $requestUri was /Myapp/public/someurl, which sadly led the code to not satisfy this conditional:
if ($baseUrl && false !== $prefix = $this->getUrlencodedPrefix($requestUri, dirname($baseUrl))) {
return rtrim($prefix, '/');
}
I am trying to implement a custom web resource using jquery/ajax and odata. I ran into trouble and eventually found that when I call:
var serverUrl = context.getServerUrl();
The code throws exceptions.
However, when I change serverUrl to the literal url, it works. I then found forum posts that said I should verify my .aspx page manually by going to https://[org url]//WebResources/ClientGlobalContext.js.aspx to verify that it is working. When I did that I received a warning page:
The XML page cannot be displayed
Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.
--------------------------------------------------------------------------------
Invalid at the top level of the document. Error processing resource 'https://[org url]//WebResources/Clien...
document.write('<script type="text/javascript" src="'+'\x26\x2347\x3b_common\x26\x2347\x3bglobal.ashx\x26\x2363\x3bver\x2...
What the heck does that mean?
Hard to tell outside of context (pun not intended) of your code, but why aren't you doing this?
var serverUrl = Xrm.Page.context.getServerUrl();
(Presumably, because you have defined your own context var?)
Also, this method is deprecated as of Rollup 12, see here: http://msdn.microsoft.com/en-us/library/d7d0b052-abca-4f81-9b86-0b9dc5e62a66. You can now use getClientUrl instead.
I now it is late but hope this will be useful for other people who will face this problem.
Until nowadays even with R15 there are two available ClientGlobalContext.js.aspx
https://[org url]/WebResources/ClientGlobalContext.js.aspx (the bad one)
https://[org url]/[organization name]/[publication id]/WebResources/ClientGlobalContext.js.aspx (The good one)
I don't know why exist 1. but it causes many issues like:
It could not be published or hold information (Your case #Steve).
In a deployment with multiple organizations, seems it saves info only for the last organization deployed causing that methods under Xrm.Page.context. will return info from a fixed organization. Actually each method that underground uses these constants included in ClientGlobalContext.js.aspx: USER_GUID, ORG_LANGUAGE_CODE, ORG_UNIQUE_NAME, SERVER_URL, USER_LANGUAGE_CODE, USER_ROLES, CRM2007_WEBSERVICE_NS, CRM2007_CORETYPES_NS, AUTHENTICATION_TYPE, CURRENT_THEME_TYPE, CURRENT_WEB_THEME, IS_OUTLOOK_CLIENT, IS_OUTLOOK_LAPTOP_CLIENT, IS_OUTLOOK_14_CLIENT, IS_ONLINE, LOCID_UNRECOGNIZE_DOTC, EDIT_PRELOAD, WEB_SERVER_HOST, WEB_SERVER_PORT, IS_PATHBASEDURLS, LOCID_UNRECOGNIZE_DOTC, EDIT_PRELOAD, WEB_RESOURCE_ORG_VERSION_NUMBER, YAMMER_IS_INSTALLED, YAMMER_IS_CONFIGURED_FOR_ORG, YAMMER_APP_ID, YAMMER_NETWORK_NAME, YAMMER_GROUP_ID, YAMMER_TOKEN_EXPIRED, YAMMER_IS_CONFIGURED_FOR_USER, YAMMER_HAS_CONFIGURE_PRIVILEGE, YAMMER_POST_METHOD. For instance method Xrm.Page.context.getUserId() is implemented as return window.USER_GUID;
To be sure that your URL is the correct just follow the link posted by #Chris