Web OTP API information provided by https://web.dev/web-otp is good. But demo provided in https://web-otp.glitch.me/ is working as of now with Version 86.0.4240.111 (Official Build) (64-bit).
The main reason I could see is that navigation credentials event for OTP is not getting triggered, and I don't understand why this is happening.
Is it problem with codebase of https://web-otp.glitch.me/ OR chrome mentioned version has any problem?
Steps to reproduce -
Open https://web-otp.glitch.me/ at your mobile browser.
As webpage says, get #web-otp.glitch.me #12345 as text message to your mobile, from unknown number . And you should receive a dialog message, asking you whether you want your browser to input this OTP.
Try changing the host name, incorrect host name may stop the Promise from getting resolved, i.e., navigator.credentials.get
Make sure your last line of text message should be like this:
#<HOSTNAME_OF_WEBSITE> #<OTP>
After some experimenting it only seemed to work if the last line with text before the last line (with the # and #) ended in numbers.
Really weird.
So its like:
OTP code: <OTP>
Ignore this: 1111
#<HOSTNAME_OF_WEBSITE> #<OTP>
Related
Is it possible to getting verification sms code from browser(javascript) application ( autoincrement || auto filling)?
There are article that on ios 12 safari appeared the function auto filling sms verification code (2fa). But i can't find description(html5 or javascript) how does this work?
UPD
it's work well in safari:
<input type="tel" id="single-factor-code-text-field" autocomplete="one-time-code">
I was find apple documentation for this feature
https://developer.apple.com/documentation/security/password_autofill/enabling_password_autofill_on_an_html_input_element
I did not try it yet. But i thing it works only with secret key from clipboard. When you you tap to sms with code, ios suggest you copy code to clipboard.
It seems that the iOS autofill for 2FA is a bit of a mystery. Apple haven't documented a particular way to ensure this works. I had a search around to try to see if there was a specific HTML attribute you could use to ensure the device tries to fill in with the code, but I couldn't find anything.
As far as I can tell, Safari runs some heuristics on your page and on incoming SMS messages and if a code is found in the SMS and the page appears to have an input for a code then it offers the autofill. If you are looking to ensure this works on your site, I recommend inspecting the HTML of another site that you have seen it work on and use similar names for the input field.
QUESTION:
What do I have to do to make webView.loadUrl(javaScript) work in API 18 or lower (in comparison to API 19 or higher)?
DESCRIPTION OF PROBLEM:
I am using WebView to make a chat.
First I load the HTML like so: webView.loadUrl(url);
Then I use loadUrl again to send in the chat message like so: webView.loadUrl(javaScript);
This works perfectly fine in API >=19 but does not work in API <=18.
Chat messages do still get received from other devices but the other devices do not get a single message from the device with API 18 or lower. The exact same code is used.
I've searched a lot and will continue to search. If you have the answer, any idea that I could test or could redirect me to relevant information please do share. Thank you in advance.
EDIT:
The JavaScript tag in the string is set to lower case (with the same problem): webView.loadUrl("javascript:" + javaScriptFunction);
SOLUTION
I found the problem which was that the (encoded) message parameter sent in the JavaScript function had a line break [ \n ] in it. Removing that using the split function msg.split("\n"); made it work.
I can't be sure this is what's causing your problem, but try using
webView.loadUrl("javascript:" + theJavaScriptCode);
with lowercase "javascript:".
API 19+ doesn't care about the case of the JavaScript protocol in loadUrl (though you can use evaluateJavascript() instead anyway in API 19+), but API 18 and down doesn't recognize it unless it's written in lower case.
My app at http://beta.billboard.fm is producing errors in my normal browsing session after playing a single song.
If i reload the page in incognito, the app works fully. I only recently starting experiencing these issues. I have completed cleared all of the cache and it works again, but only temporarily before throwing the same errors.
Additionally I have disable all browser extensions.
But, no matter what I do I can't get this error from being thrown by the Youtube API:
Unable to post message to http://www.youtube.com. Recipient has origin https://www.youtube.com
It looks like there is a mismatch in the security protocols. I tried changing them to https or just removing "http:" all together on my side. But it did not resolve the issue.
Any one have an idea what is happening here?
It is quite clear to me at this point that this is a major bug in Google/YouTube's API. They have written some bad code somewhere. This bug is not a consistent thing. This is well documented by the fact that everybody's code works just fine for an extended period of time, and then they discover that all of a sudden their sites stop working properly. Additionally, all of my websites that had this problem last week are now working without a glitch - again, without me altering code.
So while it sucks to say this - the onus is on Google & YouTube to fix this and provide APIs that actually work as advertised... It doesn't look to me like there's anything we can do about it on our own :(
I am having the same problem - I also tried changing my links to http: to https: and vice-versa with no luck. I found this tread on Google Groups, but so far there has been no response. https://code.google.com/p/gdata-issues/issues/detail?id=4697
Clearing my cache allowed the player to work for a few videos, but after 3 or 4, the same error pops back up.
UPDATE 2 - Dec. 24, 2013: This solution has not actually fixed the problem at all:
After following a thread that poulified referred me to in his answer, a user in the forum posted the following solution which seems to be doing the trick for me (UPDATE: Still experiencing issues on random page loads :/):
Hi all,
It is working for replacing http:// with https://
example: http://jsfiddle.net/8tkgW/29/
Please make sure the following tips
load iframe api https://www.youtube.com/player_api
load iframe src path: https://www.youtube.com/embed/0GN2kpBoFs4?rel=0
If load player via new YT.Player, you must check the iframe src path:
setTimeout(function(){
var url = $('#iframe_youtube').prop('src');
if (url.match('^http://') {
$('#iframe_youtube').prop('src', url.replace(/^http:\/\//i, 'https://'));
}
}, 500);
Please refer my github project:
https://github.com/appleboy/js-video-player/blob/master/js/jsplayer.js#L120
MS CRM 2011 on premise.
No problems if accessed via internal address: crm:5555
Go to crm.ourcompany.co.uk:5555 in IE and load account page and the ribbon is totally grey. (Not disabled - every pixel is the colour grey.)
In Chrome and Firefox the ribbon is loaded fine.
Browser console in IE, Chrome and FF all say access errors.
I can see they are trying to access crm:5555.
IE says:
SCRIPT5: Access is denied.
PageLoader.js, line 1 character 1226
The second line above is presented as a link. Clicking it shows me this: http://pastebin.com/bBadk9HS
The full path is http://crm.ourcompany.co.uk:5555/_static/_common/scripts/PageLoader.js?ver=-1056260279
P.S. IE is "Browser Mode: IE10 Document Mode: IE9 standards".
After Long investigation I have found out the reason for same issue like this.
We had previous rollup activity feed solution.
After importing the new version of Activity feeds this hectic issue was sorted out.
Activity feed new solution is available with rollup up package.it can be found by exacting the rollup package. Previously this was available in Microsoft Dynamic market place.
It turns out that the problem is an address lookup plugin on the Account form.
This is trying to access http://crm:1999, which is a 404, and http://crm:5555, which isn't allowed.
Solutions are to fix the server on http://crm:1999 and set up proper managed internal and external URLs so it'll know whether http://crm:5555 or http://crm.ourcompany.co.uk:5555 or remove the plugin.
Just spent about 5 hours sorting out this issue, so I thought sharing how I overcame it would be helpful to someone and save them some time (it seems to be a pretty recent fix - 9 hours ago at the time of posting this question - which I found here).
I am using jQuery version 1.10.1.
Overview
I am building a Facebook tab application. It is a competition entry form where the visitor will enter some information and upload a photo that they took on a recent holiday. I have the form working in all browsers before being embedded into Facebook.
The form is submitted using $.post(). The PHP script that jQuery points to in this process is on the same domain as the form itself.
Before you can submit the form, you must upload a file. The file upload process is built like so:
There is a <div> which acts as a button. Within this div, there is an <input type="file" /> field with its opacity set to 0.
When the invisible file input is clicked, the user selects a file.
When the file is selected, a .change() event is triggered and the <div> will display the text 'Click again to upload'. I did this rather than having the file upload immediately because during my research, I learned that Internet Explorer doesn't like you submitting a form within a .change() handler attached to a file input.
When you click the div again, the form is submitted via .submit(). The form targets a hidden iframe. The file beings uploading, and on completion the iframe triggers a .load() event.
The handler for the load event uses .contents().find("div").html() to get some stringified JSON that I have sent back in the PHP script that manages the file upload. The JSON contains the status of the file upload, and the URL to the processed image if it was successful.
Problem
The application works fine in all browsers except for Internet Explorer when it is embedded into Facebook. Internet Explorer gave the following in the console:
SCRIPT5: Access is denied.
SCRIPT5009: '$' is undefined.
I've researched the second error first and came across all the stuff that I expected to come across and already checked, such as:
The path to the script is wrong.
There may be a htaccess file blocking access to the file.
The script hasn't loaded correctly, clear cache etc and try again.
The possibility that I was trying to use a script that required jQuery before it was loaded.
I have double checked all of these and confirmed they are not the case.
I then moved onto the 'Access is denied' error and all the material I am coming across points to an issue regarding cross-domain requests using AJAX. There are also some articles that mention file uploading specifically, but nothing that was 100% relevant to me in this case.
Question
Why am I getting these errors in Internet Explorer when I try to use jQuery in an page that is embedded into Facebook? I got them even when I removed every other script on the page (except for jQuery), so I assume it is triggered by the presence of the hidden iframe that I have on the page to deal with image uploads.
First, I removed every other script on the page, at which point I only received the following error (obviously because I wasn't trying to make use of $ anymore):
SCRIPT5: Access is denied.
After trying about a dozen things (and combinations of those) that I found around the internet, I decided to use the non-minified version of jQuery so that I could more accurately determine the line that was causing my issue. After uploading that and taking another look in the console, I was pointed to line 1513, which looked like this:
if ( parent && parent.frameElement ) {
Above this line was a comment which made note of the issue that I was experiencing:
// IE will throw "permission denied" error when accessing "document" variable, see jQuery #13936
I Googled jQuery #13936 and came across this page, which suggested that I swap out the above line with:
if ( parent && parent.attachEvent && parent !== parent.top ) {
After making this change, I was glad to find the issue resolved and my form working as expected. I double checked the other browsers again and can confirm that they still work as expected as well.
Solved
This is a legit jQuery 1.10.1 bug: http://bugs.jquery.com/ticket/13980 .
Using jQuery 1.10.0, or 1.10.2 the error no longer occurs.