I need to fix in an hour a bug on vue frontend related to Safaei autofill. I can't even reproduce it as Safari blocks autofill with localhost and http because of fake security reasons.
How can I enable it? I need reproduce it on Safari no other browsers work, if I don't push fix in an hour I am fired...
Related
I am looking for a way to fill basic authorization popup in Safari 13 in automated session. I want to log in to website which require such login. Solution can be even manual. Is there any way to do that?
List of solution which I tried:
Fill form manually. Issue: Safari 13 blocks any interaction with automated browser. As far as I know there is no way to do it and then continue with automated session.
Use selenium to fill the form. Issue: Safari does not support such feature.
Use http://login:password#site.com. Issue: Safari 13 does not support such feature.
Add authorization header using proxy. Issue: Some sites does not work the same with proxy. I tried browsermob-proxy and mitmproxy but site did not works the same as without proxy.
Add authorization header using proxy and then refresh page without proxy. Issue: Header is not saved in browser. Authorization is required after refresh.
Use ApplyScript or other to fill the form. Issue: Safari 13 blocks any interaction with automated browser.
Safari extension with authorization header. Issue: as far as I know safari extension does not support any headers modification.
Use Keychain access. Issue: It can not be used in automated session.
Based on a few GitHub issues, I'm not sure if this is possible to achieve given all of the workarounds you have already tried.
This issue is detailing the Safari basic auth issue, closed as out-of-scope for Selenium:
https://github.com/SeleniumHQ/selenium/issues/5610
Which a Selenium developer then links to a still-open, larger-scope issue, in the WebDriver spec repository:
https://github.com/w3c/webdriver/issues/385
It seems like the basic auth support you are looking to achieve needs to be implemented by W3C contributors, not by Selenium developers.
All of the solutions you have mentioned trying seem to be the only available workarounds out there, and without a supported Selenium solution or fully-functioning workaround, this issue may not be solvable.
I created a Vaadin (8.2.0) web app in Netbeans and uploaded it on a Glassfish (4.1) server. I can access the app's home page in Edge and Firefox, however in Chrome I get this message:
Cookies disabled
This application requires cookies to function. Please
enable cookies in your browser and click here or press ESC to try
again.
I double checked my chrome settings and know that cookies are allowed. I even added the server specifically in the allowed list.
What do think is missing?
As Artur Signell mentioned in the comments, the solution was to simply clear all the cached cookies in the Chrome web browser. After that, the app just worked fine and I didn't get that error.
I was having the same problem. I noticed that switching to HTTPS lead to these errors not occurring. The same site would throw this error when I accessed it via HTTP, but if I went to the site via HTTPS, then the problem did not occur.
I'm working in a highly secured environment. I can only use IE11 by company's policy. I'm trying to implement test automation on my project.
I'm using Selenium and IEDriver.
Currently I'm trying to implement basic scenario by just opening application page.
When I'm trying to do it via IEDriver, the page is not getting opened and the message "This page cannot be displayed" is shown.
But when I open the page manually by just typing in the url to the address bar everything works fine.
I guess it has something to do with the cookies that are coming with the request I'm making manually. Seems like those cookies contain some signature.
Can someone advise me how can I track the problem to resolve it?
Thanks.
Be sure top follow the required configuration section on this site: https://github.com/SeleniumHQ/selenium/wiki/InternetExplorerDriver
I had some issues with IE acting the same way until following this setup.
So the issue was fixed by setting proxy.
Seems like there was a change in security rules recently.
While debugging why my extension doesn't work in Safari (but does for other browsers), noticed that I can send an arbitrary made up HTTP header with XmlHttpRequest in a Safari toolbar extension. But try to do same with header named "Cookie" with same content as before, it doesn't get sent.
So does Safari restrict sending back cookies with requests or you need to follow an alternate process to do so? Seems kind of lame since this blocks functionality of apps that require session state persistence for example. If there's an alternate process, Apple made it harder to maintain session state in extensions (extra work in adapting a web app or other browser extension).
I tested using Safari 5.1.7 on Mac OS X 10.7.5 with Charles proxy.
Just figured I should post the solution that worked for me, that I commented in my own question earlier, for easier viewing by others with similar problem:
Turns out for Safari extension, what works for me is to set the browser to not block any cookies and website data. So users would have to do that to use the extension. No code changes needed. But that's not cool though.
The particular step is Safari > Preferences > Privacy > Cookies and website data: Always allow (at least under Safari 10 on Mac OS Yosemite). Although one could try "Allow from websites I visit" to see if that more restrictive option will work or not.
My implementation of Facebook Connect (just a simple login button, fb:login-button) works perfectly on Firefox and IE.
But the same button is not showing up in Safari/Chrome (Webkit).
Here's what's ironic. In my debugging effort, I saved the page (that contains fb:login-button) up as a static page and then load it in Safari. And the button shows up, everything works!
The exact same page (with the exact same HTML source) rendered by my PHP has no way for bringing up the button.
I'm trying hard to support Webkit here but I'm close to giving up. Can anybody help?
I found one more way this can occur (the blame-myself-for-being-stupid way); it's probably not common, but in the event is saves anyone else the hassle, here it is:
This symptom can also be caused by various security tools blocking facebook resources.
In my case, I'd installed Facebook Disconnect ages ago in Chrome as a plugin and forgotten all about it being installed. I also had a second installation of Chrome that was seemingly identical (but did not have Facebook Disconnect). The first would properly load the fb:login-button, and the other would not; took me ages before I looked at the plugins, because Facebook Disconnect didn't have an icon and so its presence was pretty easy for me to miss.
Here's what you'll see if some sort of security plugin is preventing facebook resources from loading. Just look at the html that renders in the browser using developer tools.
In a normal chrome session you'll end up with something like this:
<fb:login-button><a class="fb_button fb_button_medium"><span class="fb_button_text">Your text here</span></a></fb:login-button>
But in the version with facebook's resources disabled you'll end up with this:
<fb:login-button>Your text here</fb:login-button>
Like I said, pretty obvious in retrospect.
Had the same problem but it was not related to anything like a plugin or malformed content. It seems if you enable country filtering on your facebook page it has an issue with the like button, this should be fairly obvious. Facebook gets your location from your profile and not your IP address.
Make sure to disable country locking if you plan on using the social plugins.
This can be due to having ClickToFlash installed. Either disable it, or check "Automatically load invisible Flash views" in the ClickToFlash settings.
What we found out is that Safari (and maybe some older versions of Chrome or other WebKIT browsers) have a problem with Facebook's code using the innerHTML JS function if your page arrives with an XHTML response header (application/xhtml+xml).
Using text/html solves the issue.
In case of JSF2, which we use, the implementing the fix was as simple as wrapping the FB button like this:
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:fb="http://www.facebook.com/2008/fbml"
xmlns:f="http://java.sun.com/jsf/core">
...
<f:view contentType="text/html">
<fb:login-button>Login using Facebook</fb:login-button>
</f:view>
Facebook bug report here:
http://bugs.developers.facebook.net/show_bug.cgi?id=5545
I had this problem with the Facebook button not showing at all and it took me forever to figure out what it was. Luckily after days of hair pulling I will now share the answer with everyone. In my situation I simply didn't have xfbml enabled. In my FB.init I had it set to false:
FB.init({
appId : 'app_id', // App ID
status : true, // check login status
cookie : true, // enable cookies to allow the server to access the session
xfbml : false, // parse XFBML
oauth : true // enable OAuth 2.0
});
I changed this to "true" (xfbml) and the login buttons works great now! :P Good luck!
This happened when I had the wrong domain in callback_url in config/facebooker.yml. Apparently it uses that to load the js files.
I had the same problem but I resolved it by making sure the URL in my app settings was exactly the same as the one for my site (i.e. it didn't work when I accessed my site without the www.).
I have tried every suggested solution here and it didn't work for me. But now I finally found the solution.
Facebook requires now a secured (https) for Canvas (Secure Canvas URL). The unsecured one will be deprecated soon.
Here is the main difference, Chrome doesn't like https connections with invalid certifications. On a localhost, it is very likely you have stunnel installed to allow https connection for the localhost. Firefox is ok with the self created SSL certificate and allows you to add an exception when trying to access that site. Chrome doesn't allow it out of the box.
When I load my app in Chrome the page is blank and I dont see any login button.
Click F12 and click the Netwrok tab in Chrome:
You see that the post request to your localhost is cancelled. DOUBLE Click on it.
Now you would see that chrome is blocking the localhost because of the certificate:
click on proceed anyway.
Now to back to your other tab and reload the page:
Chrome works now like Firefox and shows the login button.