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.
Related
I've built an angular app using #angular/pwa, that supports external logins like Microsoft, Google, Facebook and Twiitter. When a user wants to signin using an external login, I'm using window.open to open the url hosting the Challenge.
The problem is that when calling window.open from the web app in the browser, the url is being forced to open in the PWA.
I've litterally already tried everything I can to prevent this, but without success. The last thing I've tried was to host my endpoints for my external logins on a subdomain, which worked quite well.
But now I've implemented 2FA in my web app, and for 2FA to work, the ExternalLoginSigninAsync must be called from the same domain as the call to TwoFactorAuthenticatorSignInAsync. So how can I force an url (window.open) to open in the browser instead of the PWA?
PS: Don't come up with
Exclude from navigationUrls ("navigationUrls": [ "!/web/v3/Account/connect/" ])
window.open(url, '_system')
window.open(url, '_blank')
Use ngsw-bypass (window.open(url + '?ngsw-bypass=true'))
That's all been tried, and doesn't work.
Edit
This block of code appears to determine whether the PWA should be launched or a new tab should be opened.
Call stack:
WebappLauncherActivity.shouldLaunchWebapp
WebApkValidator.canWebApkHandleUrl
WebApkValidator.resolveInfosForUrlAndOptionalPackage should return false for the urls you don't want opened in the PWA
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 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.
The title really says it all. Under some (undetermined) conditions FB.getLoginStatus() just stops working and won't invoke the callback I gave it. The only interesting clues I've found are
FB.Auth._loadState is stuck on "loading" -- whatever is supposed to make it click over to "loaded" isn't happening
slight delays like putting in alert() calls tend to make it start working
Any hints at all about even how to investigate this welcome.
This usually happens for me when I am running the page under a different domain from what has been registered in Facebook. Typically this is when I am developing locally.
If you are running locally, you'll have to set up a local web server and then modify your hosts file to point the the registered domain to 127.0.0.1 in order to test on your local machine. Don forget to remove that line from the hosts file when you want to test it on the server.
According to:
https://developers.facebook.com/bugs/240058389381072
You cannot put your application under sandbox mode, or else it won't work. Go into your app settings, advanced, and switch it. This stumped me for a couple hours until I happened upon the bug report.
I had similar problem with FB API. It turned out, that my Facebook App was misconfigured. Please make sure that this is not the case for you. My problem was that my "Site URL" param in FB application was pointing to https, but I was using http protocol for development. Any call against FB api after FB.init was not calling my callback functions. So the first thing to do should be to double check App config.
Now, if some reason you depend on FB api but you wish to have a fallback option in case it;s inoperative - workaround with timer should be ok for you. Just set up a timer and disable it if FB Api gives you proper response. If not - fallback to some custom function which will perform some additional logic.
function callFbApi() {
var timeoutHandler = setTimeout(function() { requestFailed(); }, 1000);
function requestFailed() {
// When this happens, it means that FB API was unresponsive
doSomeFallbackWork();
alert('hey, FB API does not work!');
}
FB.getLoginStatus(function(response) {
clearTimeout(timeoutHandler); // This will clear the timeout in case of proper FB call
doSomeUsualWorkAfterFbReplies();
return false;
}, true);
}
If your application is in sandbox mode, Facebook acts as if your application is invisible to anyone who is not listed as an application developer. If you're not logged in, then it would stand to reason that your app is now invisible.
The callback will only fire if you're initializing with a visible application. Otherwise the following response is returned:
<span>Application Error: There was a problem getting data for the application you requested. The application may not be valid, or there may be a temporary glitch. Please try again later. </span>
For more info please see my comment on this bug ticket:
https://developers.facebook.com/bugs/240058389381072
Maybe you are using the asynchronous call. The same thing happened when I called FB.init with window.fbAsyncInit. All I did was delay the FB.getLoginStatus with a setTimeout function
window.setTimeout(checkLogStatus, 1000);
function checkLogStatus(){
alert("check");
// fetch the status on load
FB.getLoginStatus(handleSessionResponse);
}
It seemed to work after that
On the new version of the Developer app, you have to make sure to have put the correct URL you are using to access the application in the Website field under the
Select how your app integrates with Facebook
section.
Make sure the protocol is HTTPS and not HTTP.
I had a similar problem. The site worked every time when I was opening the browser, but fails when I tried to reload.
The cause was the missing "www" on the site name on Facebook configurations. Note that putting "www" (like www.yoursite.com) works on both situations (yoursite.com or www.yoursite.com).
As others have posted, you must be accessing your site at the same URL that facebook expects. For example if facebook has a callback "example.com" but you're browser has "www.example.com", that can cause this problem.
In addition, if third-party cookies are not allowed by your browser, you may also see this problem. Or you may see the callback erroneously reporting the user is not connected.
Just posting a situation I had were calling FB.getLoginStatus got absolutely no response.
My application is designed to run in a tab, and I only entered the Page Tab URLs on the app admin page, and not the App On Facebook (i.e. Canvas) URLs. The tab loads perfectly, but any calls to the FB JS SDK provoke no response.
In Facebook App Settings, go to Client OAuth Settings, look at Valid OAuth redirect URIs
Make sure you have listed all URIs which are the domains from which Facebook SDK is being invoked. For example:
I develop at localhost:5000 and deploy to Heroku. Notice the format: http://domain.name/