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
Related
I made authorization with instagram in safari then opens my redirect-URL: “https://badyi.github.io + code “.
I need to grab redirect-URL. What is url-scheme here?
What is identifier?
What i have to put in info: URL-types?
I know about canOpenUrl method, but idk what to put in info
For example:
bundleID: 999
clientID: G0G
Secret: 666W
redirect_URL : https://badyi.github.io
Upd:
I use oauth2 to use instagram profile data in my ios app.
what I got:
1) the application opens
2) by clicking on the button, opening the safari with the authorization page
3) after logging in, redirect_url opens in safari
I expect that after 3 steps I will be transferred to my application and I will be able to handle my redirect url
Your redirect url has scheme https. It means open "in web", that's why it was handled by Safari
If you want to return to your app after auth, you need to implement your own scheme
Please check documentation about this feature
Option 1: Deeplinks
As #viktor mentioned, you need to implement your own scheme in your application, and set redirect_URL to it.
For example, if you have application named "FooBar", you can make scheme foobar, so the redirect_url can be something like:
foobar://returnFromRedirect?maybeArg=some, then, you need to parse this URL in your application and proceed it properly. Here an article about it
Option 2: Universal Links
You can add trusted domain to your application, so all links from this domain can be opened with your application. Apple documentation
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);
}
}
I have a web application which is configured as a canvas web application in facebook and also has provided a mobile url where mobile specific page is served from the web server. Application has been running for about 3 months and starting last week (I believe the issue started last week, there was no application deployment for the last 3 months ) when I access the application from my android phone , from the apps short cut in the native android facebook application , facebook throws the below error
API Error Code:196
API Error Description: Cannot redirect to desktop web canvas URL on a mobile device.
Error Message : redirect_uri is not owned by this application.
I can see that the request is coming to my web server and after I send the redirect url to the mobile, it throws the above error.
Since there was no code changes, I'm a bit confused about this new error, and googling this api error number didn't return any hits except for one japanese website where someone has mentioned about this error last week, but don't see any solutions.
The error message "cannot redirect to desktop web canvas..." seems to be sort of self explanatory but I can't figure out what is wrong , especially since the samething was working before, unless FB has changed any of their code which introduced a new issue or exposed an existing issue in my application configuration.
Lost 1 day on this, tried to read 2 Japanese (untraslated) blogs.. Then I figured it out my way!
In the app settings, do NOT enter the same url for the mobile app!
example:
normal canvas or website url:
https://www.stackoverflow.com/
(which will automatically bring you to https://www.stackoverflow.com/index.php)
mobile url: https://www.stackoverflow.com/mobile/
(which will automatically bring you to https://www.stackoverflow.com/mobile/index.php)
then make a "mobile" folder in your hosting root folder.
Now the only difference in the mobile folder will be the redirect uri.
I am using an url redirect, which is what facebook suggests.
https://developers.facebook.com/docs/reference/dialogs/oauth/
CRITICAL: make sure your redirect uri is not the canvas address but the webserver address!
wrong redirect uri: https://apps.facebook.com/mobile/yourappname/
correct redirect uri: https://yourwebsite.com/mobile/
this will make facebook think that it's an ad hoc mobile website! And everything will work as expected!
I had the same problem, and I solved it not set "redirect_uri" param, like this.
$url = $facebook->getLoginUrl(array(
'scope' => 'xxxx, xxxx, xxxx',
'display' => 'touch'
));
As you know, we can put "Canvas Page URL" value like
http://apps.facebook.com/[your app name space]
to "redirect_uri" param before, but I guess the spec of the param was changed at the middle of the last week.
I got a same error, "API Error Code:196".
Visit my page.
http://nobish.jp/facebook/app-install-api-error-code-196.html
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/
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.