I'm developing my first Facebook app using custom Open Graph actions and objects, and I'm trying to avoid needing to deploy after each code-change (in this case, to my automatically setup heroku-account).
The problem started while I was getting set up to test the publishing of my first custom action. I was trying to set up everything in terms of the dev-version of my facebook-app, except for my "object" page, which, as I understand it, needs to be publicly accessible (to scrape the OG meta-tags).
I made a test-page for my custom object, copied the auto-generated set of OG meta-tags into it (citing the dev-version of my app_id, but with the public URL of the prod-version of my app for og:url) Then, I used the facebook "lint" tool on that test-page, and it, I guess not surprisingly, complained about that public domain being invalid for the relevant app (the dev-version of my facebook app).
Object Base Domain Not Allowed: Object at URL
'http://foo.herokuapp.com/testEventPage.php' of type 'foo:product' is
invalid because the domain 'foo.herokuapp.com' is not allowed
for the specified application id '(the app_id)'.
Then, I learned about using Tunnlr to port-forward from a public site to my local env and proceeded to get that set up.
I'm using MAMP with a virtual host config as follows:
<VirtualHost *:8888>
DocumentRoot "(the relevant docroot)"
ServerName foo.local
SetEnv FACEBOOK_APP_ID (my dev FB app-id)
SetEnv FACEBOOK_SECRET (my dev FB secret)
</VirtualHost>
And I'm using tunnlr, with the cmdln for it pointing to port 8888.
Using the public URL provided by Tunnlr, I am successful in accessing my local pages, but, when I try to use the "Login" button on the page that came with the example PHP-code from Facebook, the login-dialog pops up but immediately disappears, though when accessing it directly locally it works fine.
Could this be cookie-related? Something to do with port-forwarding and cookies?
Is there a better way to develop Facebook apps, in particular ones involving custom Open Graph actions and objects?
EDIT: like the doctor said, if it hurts when you move your arm like that, don't move your arm like that! In other words, access the Tunnlr-URL via the Facebook-Canvas URL, which POSTs the embedding page's current login to your own page; and, as a user (optionally a test-user), don't use the example-code's login-button; instead use the embedding page's login-feature. So, I've answered my own question.
Related
Experience cloud vistor id is used. App, web are using same adobe launch library. When I login into app url change and mid changes and then if I navigate from app to web responsive page mid is changed and I am not seeing any cross-domain pathing report from app to web ?
anything do I need to do with s.cookiedomainperiod or anything to make this work?
The Experience Cloud Visitor ID is not automatically carried over from the native mobile app to a (mobile) web page. The long story short is native apps don't really store data locally in the same way as web browsers, so there's no automatic ability to use the same local storage mechanism/source between the two.
In order to do this, you must add some code to the mobile app to append the mid value to the target URL, e.g. :
Android
String urlString = "http://www.example.com/index.php";
String urlStringWithVisitorData = Visitor.appendToURL(urlString);
Intent browserIntent = new Intent(Intent.ACTION_VIEW, Uri.parse(urlStringWithVisitorData));
startActivity(browserIntent);
iOS
NSURL *url = [NSURL URLWithString:#”http://www.example.com/index.php"];
NSURL *urlWithVisitorData = [ADBMobile visitorAppendToURL:url];
[[UIApplication sharedApplication] openURL:urlWithVisitorData];
If implemented properly, you should now see a adobe_mc= parameter appended to the target URL. Then on page view of the target page, if you have the Adobe Analytics javascript and Experience Cloud Visitor ID libraries implemented, they will automatically look for and use that value instead of generate a new value (should not require any config / coding on this end).
Update:
#Ramaiyavraghvendra you made a comment:
Hi #Crayon, mny thanks for your profound answer. I am sorry that i
missed to inform that this app is not native one but this is a SPA
app. so the implementation of entire app is also done through launch.
Could you pl help in this case then.
I'm not entirely sure I understand your issue. If you are NOT moving from a native mobile app to web page, and your mobile app is really a web based SPA that outputs Launch as regular javascript code throughout the entire app, then you shouldn't have to do anything; the Experience Cloud ID service should carry over the id from page to page.
So it sounds to me like perhaps your Experience Cloud Visitor ID and/or Adobe Analytics collection server settings are not configured correctly. the cookie domain period variables may be an issue, if logging in involves moving from say www.mysite.com to www.mysite.co.uk or similar, but shouldn't be a problem if the TLD has the same # of periods.
Or, the trackingServer and trackingServerSecure variables may not be configured properly. In practice, I usually do not set trackingServerSecure at all. These variables get kind of confusing and IMO buggy in different scenarios vs. what you are using, so I tend to use the "secure" value in the trackingServer field and leave the trackingServerSecure blank, and then Experience Cloud Visitor ID and Adobe Analytics will just use the secure version 100% of the time.
Or..it could be a number of other config variables not properly set. It's hard to say if any of this is off, without access to the app and Launch container.
Also you may want to check the response headers for your logged in pages. It may be that they are configured to reject certain existing non-https cookies or something else that effectively causes the existing cookies to be unreadable and make the Experience Cloud ID service generate a new ID and cookies.
Or.. maybe your app kind of is a native mobile app but using an http wrapper to pull in web pages, so it is basically a web browser but it is effectively like moving from one web browser to another (e.g. starting on www.site.com/pageA on Chrome, and then copy/pasting that URL over to Internet Explorer to view). So effectively, different cookie jar.
Launch (or DTM) + Experience Cloud ID (Javascript methods)
In cases such as the last 2 paragraphs, you have to decorate your target links the same as my original answer, but using the Launch + Experience Cloud ID Service javascript syntax:
_satellite.getVisitorId().appendVisitorIDsTo('[your url here]');
You write some code to get the target URL of the link. Then run it through this code to return the url with the parameters added to them, and then you update your link with the new URL.
Super generic example that just updates all links on the page. In practice, you should only do this for relevant link(s) the visitor is redirected to.
var urls = document.querySelectorAll('a');
for (var i = 0, l = urls.length; i < l; i++) {
if (urls[i].href) {
urls[i].href = _satellite.getVisitorId().appendVisitorIDsTo(urls[i].href);
}
}
hellojs twitter error
When i run the twitter demo from demo folder and clicked on twitter button it give me following error
url is undefind in hello.js file on this line if(url.indexOf(x)>-1){
how to fix this error
thanks
When running the demo page in question
http://adodson.com/hello.js/demos/twitter.html
You'll see...
hello.init({
'twitter' : TWITTER_CLIENT_ID
},
{
redirect_uri:'../redirect.html',
oauth_proxy: OAUTH_PROXY_URL
});
The setup includes an OAUTH_PROXY_URL variable. This tells HelloJS the location of the server-side shim in order for this to work with OAuth1 authorisation providers like Twitter (unlike OAuth2 providers which can share authentication tokens purely client-side)
If running this from a local domain like //localhost this will have been an undefined value.
You'll need to do two things to get the demo working.
Define the oauth_proxy option in the demo code. See http://auth-server.herokuapps.com for setting one up. OR remove it entirely and by default it will use the above service - you'll need to register third party apps there (recommended).
Change your development environment in your host file to something other than //localhost, that way you can register OAuth2 providers which are domain sensitive and often wont let you use localhost when registering your apps callback URI. If you change your development environment to be local.knarly.com with hello.js project as a subfolder - then you can skip step 1 as the oauth_proxy will be defined correctly.
I'm trying to use a new dropbox datastore API with my chrome extension. If used as specified in tutoria, auth will fail with error 400:
Invalid redirect_uri: "chrome-extension://anzbpdekhbhcbekwmfazaophjcaabshl/chrome_oauth_receiver.html". It must exactly match one of the redirect URIs you've pre-configured for your app (including the path)
If i add this URL to my app profile at dropbox website, all works fine. But "anzbpdekhbhcbekwmfazaophjcaabshl" is a computer-unique value, it will be different for each extension installation for each user. Is it possible to somehow fix this or dropbox datastore API is intended to be used on static websites where redirect url is known?
Update 1
Extension ID is random for manual/non-public extension installation.
Update 2
I have found a way to make extension ID persistent: just pack it, generate a public key fro private .pem key and set this key's base-64 encoded value as 'key' in manifest.
Moving my comment to an answer (and see updates to the question for details):
I thought that the extension ID (the part right after chrome-extension://) was not user- or computer-specific and remained the same everywhere the Chrome extension is installed.
I'm successfully using the Datastore API from a Firefox extension. The trick is to attach the dropbox scripts to an actual webpage, not a local page. I have a blank page hosted on my server, and the extension opens that page and attached the necessary scripts. From there it redirects the user to the Dropbox authentication page.
Once the user has authenticated I open the same page in a "headless" tab using the page-worker API. (I don't know if Chrome extensions have the equivalent functionality)
The redirect URL has to be https so you'll need to get an SSL certificate for it to work.
I understand that it's possible to use oembed to get embed code for private files, but I'm running into "403 forbidden" when I try it.
http://soundcloud.com/albert-albala-1/audio-recording-on-monday/s-VzgUg
is accessible in a browser, but
curl -iL http://soundcloud.com/oembed?url=http%3A//soundcloud.com/albert-albala-1/audio-recording-on-monday/s-VzgUg&format=json&auto_play=false
yields a HTTP/1.1 403 Forbidden error. The same call with a public sound works fine:
curl -iL http://soundcloud.com/oembed?url=http%3A//soundcloud.com/osmconcerts/rosemarie-landryv2&format=json&auto_play=false
Related question: Rendering SoundCloud widget for a private track using PHP API, although that one uses PHP. I'm trying to get this to work on the command line.
It's possible to embed private tracks using a secret token if the track's settings allow embedding.
Embedding is allowed by default, but if you're receiving a 403 with a valid secret token, you've probably disallowed public embedding for the track.
You can enable this through the web UI on your track's edit page under Settings -> Advanced -> Widget Settings -> Click to enable -> For everybody:
Just had this problem myself, and the track/sound settings have changed layout/structure since pje's answer from 30/09/2013.
Currently, under Permissions, you need to make sure that 'Display Embed code' is turned on - despite the fact that you may not want this to happen! Doing so should mean a 200 status code is returned along with the embed metadata.
Essentially what this is doing is allowing the track to be publicly embedded on other sites (despite the track being private in terms of not being listed on the main account page).
I'm trying to debug my gwt 2.0 apllication that runs inside facebook iframe.
When i use 'http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997' as "Canvas Callback URL" my app doesn't loading, but when i compile it and use 'http://127.0.0.1:8888' it works perfectly.
There is a cross site scripting issue with using the GWT debugger within the facebook iframe.
I logged this as issue #4468
http://code.google.com/p/google-web-toolkit/issues/detail?id=4468
Within that ticket, I specified the workaround is to edit the hosted.html file thusly:
hosted.html
gwtOnLoad = function(errFn, modName, modBase){
....
var topWin = window.top;
var url = topWin.location.href;
...
Workaround if you have one:
var topWin = window;
var url = topWin.location.href;
I have a similar issue for deployment mode. Basically I want my GWT to be managed from a single entry point deployment and be able to run it as widget on 3'rd party websites, without them have to download my application into their host, only using the selector script as reference to my GWT app.
There is a problem doing that due to SOP limitation of current bootstrap process that uses an "iframe" to load the compiled script asynchronously.
I created a workaround procedure for that, let GWT app be installed using 'script' instead of 'iframe'. This makes my GWT available for 3'rd party websites, and let me maintain a single entry point of deployment.
The following article describe my workaround procedure:
Make GWT Widget Avialble For 3'rd party websites
127.0.0.1 is a reserved IP address that always resolves to localhost. So when you enter that as a Facebook canvas URL, Facebook tries to access it's own servers. A request never comes to your computer, which is where the application is actually hosted. Of course, when you access it at 127.0.0.1, it works fine, because your localhost is your own machine.
You need to figure out your external IP address, and enter that as the Canvas Callback URL. You can check your router settings, or go to something like http://www.whatismyip.com/. Once you have it, try accessing your application using it directly instead of 127.0.0.1. You might have to change your router or firewall to allow port 8888 through. Once you have it working, enter it as your Canvas Callback URL in your Facebook application settings.