Related
I'm trying to interface a website, and one of the ways you can log on there is by using a Facebook login (it opens a pop-up, you can enter username/password or simply confirm if you're already logged on, you know the drill...).
Well, I'm trying to interface it with Puppeteer, and the strange thing is that I don't get the page. I mean, I'm working in non-headless mode so I can SEE the popup, it just looks like Puppeteer can't see it...
A lot of pages said to try something like this:
const newPagePromise = new Promise(x => browser.once('targetcreated', target => x(target.page())));
await page.click('<some selector>');
const popup = await newPagePromise;
But this doesn't give me a "popup" I can use (popup: null). I also tried to make it wait for 10s, but no luck then either...
When looking at all_pages: let all_pages = await browser.pages();, this array has 1 page. My original page... No Facebook popup. (But it is displayed on my screen!)
What am I missing here? How can I get this information in my automation process?
BTW: the Facebook popup also has 'Chrome is being controlled by automated test software.'. So I would assume I can reach this information somehow.
Thanks for any assistance!
browser is used to connect with Chromium, it is only called at the beggining. The same way you interact with the main page using const page = await browser.newPage(),
you have to use that same variable once the popup emerges as well, on the other hand,'targetcreated' is not the event you are looking for but 'popup'. Have in mind that page provides methods to interact with tabs, therefore, updating the code:
const newPagePromise = new Promise(event => page.once('popup', event));
This can be found in puppeteer documentation:
https://github.com/puppeteer/puppeteer/blob/v5.2.1/docs/api.md#event-popup
How to pass parameters(envelope,PF and r ID) within iframe while returning URL in embedded docusigning? If I enter the POWERFORM link on browser I'm returning URL with the parameters (envelope,PF and r ID) but if I run code within iframe I'm unable to get the parameters. Please do assist me about this issue.
You are opening Powerform inside an IFrame, so the scope of the opened URL is inside the IFrame only and DocuSign cannot do anything to redirect the browser to come out of the IFrame. You have write a code on your end to capture the redirect URL and break the flow out of IFrame, you can find a similar query here. Normally DocuSign does not recommend using IFrame for Signing, also to capture the data like envelopeId, r Id etc, it is better to configure DocuSign Connect with a listener on your side. Using url redirect is a fragile solution as user might close the browser (or browser hangs/network issue) and you might lose the data. Whereas with DS Connect, DocuSign will publish the event to your listener and you will be able to capture all the required data in your listener.
<script>
function myFunction()
{
var x = document.getElementById("form1").action;
document.getElementById("demo").innerHTML = x;
}
</script>
This thing works for displaying the parameters.
window.parent.window.location.href = 'Parent URL' works to break out of an iframe and load the parent page.
Issue Context:
I am using meteor js for a mobile app.
I have hooked it up with google analytics calls and basically I am using two type of calls:
Screen views
Events
Screen views are just fine, but I'm facing an issue with the events.
When I go to Behavior -> Events -> Screens, in the google analytics dashboard, I can see the URL of every page that has triggered an event under the Screen Name column. My problem is that the page URLs for my login page look something like this:
meteor.local/login?username=*******&password=+++++++&rememberMe=on
Where ******* is an actual username and +++++++ is the corresponding password!
Reason:
Since I have to share this analytics account with multiple people, I do not want this information to be available over here.
Clues:
CLUE 1:
I used to do GET http calls, but I have changed them all to POST and it still has not fixed the issue as I expected it not to pass plain parameters through URL anymore.
CLUE 2:
I've noticed that the default google analytics js framework is working with http and not https. I was wondering if it is calling the analytics server with a GET as well. If so, is there anyway to change that?
CLUE 3:
Here is how I am initiating the GA instance:
(function (i, s, o, g, r, a, m) {
i['GoogleAnalyticsObject'] = r;
i[r] = i[r] || function () {
(i[r].q = i[r].q || []).push(arguments)
}, i[r].l = 1 * new Date();
a = s.createElement(o),
m = s.getElementsByTagName(o)[0];
a.async = 1;
a.src = g;
m.parentNode.insertBefore(a, m)
})(window, document, 'script', '//www.google-analytics.com/analytics.js', 'ga');
ga('create', googleKey, 'auto');
CLUE 4:
I have also noticed that these URLs are getting captured very occasionally. E.g. in the pas 12,500 unique events (about 30,000 total events) it has captured just 9 URLs with the username and password. The remaining 12,491 events have
meteor.local/login
OR
meteor.local/--
OR
localhost/--
as the Screen Name.
CLUE 5:
I have also put 4 "search and replace" global filters on the analytics account to search for this string
meteor.local/.*
and replace it with this one
meteor.local/concealedURI
This does not seem to be working either.
I have added this filter on 4 different fields (Since I still really don't know where the URLs are coming from):
Host Name
Page Title
Referral
Request URI
CLUE 6:
This is how I am calling the GA instance to send the event:
ga('send', 'event', 'button', 'click', eventName);
Okay. So, I had to run a lot of experiments and try out different things to solve this issue.
After trying all the things that I have described in the question, I finally found a way to address this problem.
The main cause of this problem was that I was using a google analytics account set to track an App, to capture the data from an app that was built with meteor js (which basically utilizes cordova).
Using meteor means that my app's screens are actually web pages rendered as a mobile app. It seems like meteor uses URLs to navigate through these screens.
On the other hand, google analytics looks at (and captures) the screen name of an app's page, when an event is triggered from that page. In native apps this screen name will be something similar to "About us", "Contact Us", "Home", etc.
Now since a meteor app is not the same, the screen name returned by meteor is actually the URL of the page that has triggered the event.
This does not have anything to do with the http calls (Whether or not they are GET or POST), because it is the local URL used by meteor for navigating that is being passed down to google analytics and not any http calls.
Solutions
1.
If I had the google analytics account set as a web page tracker, I could have access to "Exclude URL Query Parameters" field and I could potentially exclude username and password as was suggested by #Mike and #PhilipPryde in the comments.
However, I needed to use google analytics set as an app tracker. So, this did not work for me.
Failed
2.
I did put a filter on the whole view in the google analytics and searched for meteor.local/.* and replaced that with hiddenURL. The filters on
Host Name
Page Title
Referral
Request URI
did not work.
But when I put the same filter on
Screen Label
field, it worked.
However, this only looked at the screen names returned by screen view hits and not the event. Thus, this did not actually solve my issue either.
Failed
Finally, I had to do this:
There is a method call on GA instance that lets you set different options up. I ended up using this:
ga('set', 'screenName', 'hiddenURL');
This changed the screen name to "hiddenURL". So, I used this before every event and it worked for me.
My code for sending events to google analytics looked like this:
ga('set', 'screenName', 'hiddenURL');
ga('send', 'event', 'button', 'click', eventName);
PS:
This changes the screen name that was showing up in real-time reports of google analytics to "hiddenURL", whenever someone triggered an event. But, it changes back to a screen name as soon as they go to another page. So, it would not also mess with any of your screen view data either, since it is not being captured as a screen view.
Of course that is because, I pass the screen name to my GA instance every time I send a screen view. So it looks like this:
sendScreenViewToGA = function (screenName) {
ga('send', 'screenview', {
'appName': 'Something',
'screenName': screenName,
'appVersion': x.x
});
}
If I had used the screen name, that is being set on the environment tight now, I would have ended up with all my screen names in analytics set to "hiddenURL".
I really hope this post will help others with same issues and save them some time.
I am trying to create an html object dynamically with the necessary header information depending on the query string in the link I provide to Facebook. I am hoping that Facebook open graph will call this html link as I provided. However it seems that query string info are not getting passed to my server. Do anyone know how to make this work or what is the more appropriate way to do this. BTW, I am writing my code in Node.js.
To get more info about Facebook open graph api, look here, https://developers.facebook.com/docs/beta/opengraph/actions/.
For example, the link I am trying to pass to Facebook is, "http://xxx-url.com/getFacebookObject?objectId=&description=first dynamic post", so I sent a request with the link as, "https://graph.facebook.com/me/app-name:action-name?object=http://xxx-url.com/getFacebookObject?objectId=&description=first dynamic post". However, when I check the log on the server, I don't see anything in the query string.
Instead of using the query string, you can embed the data in the URL:
http://some-domain.com/getFacebookObject/id/description
Then, depending on what node.js packages you're using, extract the data from the request:
// expess.js style
app.get("/getFacebookObject/:id/:description", function(req, res) {
var id = req.params.id,
desc = req.params.description;
// your code...
});
(See http://expressjs.com/guide.html.)
Sorry, Facebook will strip off all query string information from the URL when they launch your site in the iframe. If it was a page tab app, then you could add it to the app_data query string parameters which in turn gets passed to your iframe's page tab app via the app_data part of the signed_request parameter.
How do you track outbound links for your web site, since the request is logged on the destination server, not yours?
You can add a quick JQuery script to the page that will track external links and can either redirect them to a file on your server that will track the link and then forward to it, or add an ajax request that will submit on click for external links, and track them that way.
See:
http://www.prodevtips.com/2008/08/19/tracking-clicks-with-jquery-and-google-analytics/
https://web.archive.org/web/20090214024330/http://www.justskins.com/development/how-to-track-clicks-on-outgoing-links/132
Method #1: target="_blank", onclick and Google Analytics Events
Format your outgoing links with the following attributes:
outgoing
Define a javascript tracking function (requires google analytics to be loaded already):
function trackOutgoing(el) {
ga('send', 'event', {eventCategory: 'outbound',
eventAction: 'send',
eventLabel: el.getAttribute('href'),
eventValue: 1});
};
Pros:
Does NOT interfere with normal link behavior
Does NOT require redirecting to another url
Cons:
The onclick is not guaranteed to execute (user or browser could terminate the main window)
Method #2: Redirecting with Javascript and Google Analytics Callbacks
Format your outgoing links with the following attributes:
outgoing
Define a javascript tracking function (requires google analytics to be loaded already):
function trackOutgoingAndRedirect(el) {
var url = el.getAttribute('href');
ga('send', 'event', {eventCategory: 'outbound',
eventAction: 'send',
eventLabel: url,
eventValue: 1,
hitCallback: function() { document.location = url; }});
}
Pros:
Does not require target="_blank"
Higher chance of your event being registered with Google Analytics (compared to Method #1)
Cons:
Overrides the default behavior of links with return false;
Cannot open outgoing links in a new window
Method #3: Using a Redirect URL
Format your outgoing links with the following attributes:
outgoing
On your site you will need to implement a redirect script which is beyond the scope of this answer.
Your redirect script would most likely track the outgoing link and then redirect to the provided url.
Pros:
No Javascript required
Does NOT require Google Analytics
Does NOT interfere with the normal link behavior
Cons:
Harder to trigger Google Analytics Events
Links do not link to their original URL. Which may have negative SEO implications.
Add an onclick or onmousedown handler to the anchor tag. You can see many sites doing this, such as Google.
I don't like the redirect as described by Eric Tuttleman, as you unfortunately lose the 'search engine friendliness' of the link.
I handle this on a site I own by adding an onClick to my outgoing links, which fires a function which sends the link URL and a timestamp to my database. I then wrote a backend which retrieves the data, and lets me view it by such categories as 'Most clicked / 24h', 'Most clicked / 1w' etc.
I hope this helps.
On one system I've worked on, we ended up storing redirects in a database table and creating a redirect page that takes an id as an input. On our content pages, we link to the redirect page with an unique id from this table. Once the redirect page looks up the url via the id from the table, it then sends the client a redirect response, sending them to the ending page.
This does give us logging of external links, and as an added bonus, it makes mass changes to external urls a bit easier in some cases.
Some newer options that work without any hacks as explained in https://css-tricks.com/send-an-http-request-on-page-exit/ are Fetch with the keepalive-flag or navigator.sendBeacon.
keepalive is not yet (Aug. 2022) supported by Firefox (Can I Use), but navigator.sendBeacon works in all modern browsers (Can I Use).
// normal fetch, not guaranteed to work
someLink.addEventListener('click', function(event){
fetch('http://www.testing.local/?origin=classic-fetch');
});
// fetch + keep alive (not working in Firefox as of 103, Aug. 2022)
someLink.addEventListener('click', function(event){
fetch('http://www.testing.local/?origin=fetch-keep-alive', {
keepalive: true
});
});
// navigator.sendBeacon (all modern browsers)
someLink.addEventListener('click', function(event){
navigator.sendBeacon('http://www.testing.local/?origin=beacon');
});