As far as I can tell, there's no way for a server to tell whether it's being accessed through the Chrome Webdriver or by an actual user in front of Chrome. Is this correct?
Without specific checks on the server side I doubt that it can be detected.
However, it can be put in place. One way that I'm thinking of is checking the browser preferences.
Let's take for instance the new Selenium driver used for Firefox versions 48+, the Marionette-based geckodriver. Mozilla took ownership of the driver server and citing from the Github project page:
Proxy for using W3C WebDriver-compatible clients to interact with
Gecko-based browsers.
This program provides the HTTP API described by the WebDriver protocol
to communicate with Gecko browsers, such as Firefox. It translates
calls into the Marionette automation protocol by acting as a proxy
between the local- and remote ends.
To achieve this, Mozilla implemented some WebDriver extensions built in into the browser itself.
If you go to about:config in Firefox and search for webdriver you will see some preferences that, when the browser is started by the Selenium driver they appear as user set. So this is one way of checking it.
Another one, somehow related to the first one is the Firefox profile that Selenium WebDriver creates when starts the browser that has a kind of distinguishable name. One note although, this is only using the default Selenium settings. If you, as a user create a Firefox profile that afterwards get imported in the Selenium WebDriver before initialization, there won't be any more difference, except the first point mentioned. The user preference settings.
And in same manner, this applies to all the Selenium browser drivers, so it would be applicable to Chrome to some extent too. However, I'm sorry that I can't be more specific like in Firefox's case.
Related
I need to develop some sort of browser plugin/extension to track search string on some search engine web site, ex: google.com, bing.com.
From the research, for chrome extension, I saw somebody suggest content js is the way to go. Is it true? Is there a cross-browser approach?
You can use Content.JS or any other JS library you like for developing an extension but with only JS library you cannot develop an extension.
There is a specific way for each browser. It contains at least 4 files.
(1) Manifest file (2) HTML file (3) JS file (4) CSS file
You also need to refer browsers object model.
You can refer links below may help you to get more information.
(1) Creating a Microsoft Edge extension
(2) Getting Started Tutorial to create an extension for Chrome
(3) Your first extension for FireFox
To support cross browser functionality, You can try to port your chrome extension to Firefox or MS Edge. To get more information on porting an extension, you can refer links below.
(1) Porting an extension from Chrome to Microsoft Edge
(2) Porting a Google Chrome extension
Note:- You also need to refer policy of each browser to access browsing data of users. It can be possible that all browser has some difference in their policies.
When performing some actions, chrome sometimes requires the user's permission. How can I accept these popups with puppeteer (In my case "Download multiple files")?
I'm afraid that this is currently not-supported and doesn't appear to be in the near future. According to this ticket, it's apparently not an easy task that's going to be taken on soon.
You might look into using xvbf on "headful" Chrome as opposed to using headless as that appears to be the flag that causes Chrome to not use user-settings.
We have a web application that runs within a VPN. It has a self signed cert on it and is accessed through the server's IP address.
Part of the functionality of this app are some legacy Java apps (that no longer run in Chrome). Our initial work around for our Chrome users was to run Shell In A Box within an iframe of the web app to run those. All was good until the latest version of Chrome, v45.
What we’re seeing is that appears to be blocking the iframed content (maybe because of the self-signed cert?). If we grab the ShellinABox URL and drop it in a new tab, it works as it used to in the iframe. If we go back to the iframe, it now works. If we close Chrome and open it back up, it still works.
I should also note that we tried the canary builds as well. It's up to v47.x and we still see the same behavior there. We were reading through some of the Chrome group/bug lists and saw some reports that were similar but the "fixes" supposedly going through canary still didn't resolve it.
So, it appears that an exception is being logged somewhere. Does anyone have an explanation for this behavior and is there a way to set this exception without jumping through those hoops?
It turned out it was due to a permissions issue with ShellInABox that didn't reveal itself until v45 of Chrome, for some odd reason.
NPAPI plugins are not supported on Microsoft's new browser Edge.
Google Chrome developed Chrome Native Messaging in order to interact with an executable installed on the computer provided its link on the registry (for Windows OS).
Firefox seems to want to support Chrome extensions in the future, and we can assume the browser will eventually support Chrome Native Messaging as well.
Internet Explorer will continue to support NPAPI until 2020 (from what I heard).
For Edge, no solution has yet been developed (or is there one?)
I'm willing to work with URL handlers (myapplication://mydata) in order to compensate for this lack. Is there a better approach so far?
https://msdn.microsoft.com/en-us/library/aa767914%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
My intent is to communicate through an HSM installed on the computer, and use the Crypto API interface, or a PKCS#11 driver in order to sign data and send back the result to the browser. With a chrome native messaging extension, it actually works well. With a URL Handler, I will be able to send data to the executable, but I won't get the result, so I will have to think to post the result to a web specific URL, but this can result in a security hole to my perspective.
Thanks in advance,
EDIT : 2017-01-14 : The following link shows the progress of the adaptation of the Microsoft Edge Extension API :
https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/extensions/api-support/extension-api-roadmap/
EDIT: as Beckyang posted recently, there is a link where you can vote for the feature to be developed in priority, here :
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/13612338-native-messaging
After reading some recent news:
https://github.com/david-sabata/web-scrobbler/issues/678
http://www.theverge.com/2015/7/30/9072271/microsoft-windows-10-updates
http://news.softpedia.com/news/microsoft-wants-google-chrome-extensions-to-work-on-edge-with-zero-work-to-do-488282.shtml
It seems like the adaptation of the initial Chrome extension will be possible as soon as Microsoft has implemented a "Chrome-Extension-like" API. So, eventually, It won't be necessary to develop something completely new.
The Native APIs are supported in Windows 10 Insider Preview Build 15002.
Native messaging in Microsoft Edge.
I am trying to use MSAA (on Win7) to get the addressbar in chrome browser and replace it with a different url. When chrome is launched normally (as the loggedon user), I am able to find the addressbar using the IAccessible interface by traversing through the UI tree of the window classes owned by the process.
However, if I launch chrome as a different user (by using RunAs in windows), I see window with name, "chrome legacy window" when going through the classes owned by the "RunAs" process. The window hierarchy and the content within is vastly different from what I see if I scan the process that is running as the logged on user.
Although I can see (window classnames) Chrome_WidgetWin_0 & Chrome_WidgetWin_1 in both the browser instances, only the one running as the current user is giving access to the address bar.
Any idea on what is happening when chrome is launched as a different user? Is there any workaround or should I be looking at a different technology?
As Penn has noted this may have something to do with the PDF view which has caused peculiar problems in the strangest of places.
Looking at the bug tracker here it looks like sporadic behaviour with PDFs and the "legacy window" has been introduced in a recent build so perhaps try rolling back to an earlier version of Chrome.
Also I presume you are using chrome://accessibility with
Global accessibility mode: on
Show internal accessibility tree instead of native: on
or starting chrome with the flag --force-renderer-accessibility it seems to be a prerequisite for other automation programs like autoit as seen here.
If you can't get this method working I'd recommend trying the autoit script there.
Here is an autoit code example that shows grabbing the address bar and using it for general navigation, upon other things!
I have found that if a PDF file is open in the chrome viewer (in some versions of chrome) the window you referred to appears. Please confirm what URL is being used when you open chrome.
I have also read that a password request prompt can cause the same window to open. The PDF window only appears if the window is launched by certain processes/users