I am using webcam.js for getting a photo clicked of a customer for profile creation on my cloud based retail store software.
It used to work fine in earlier versions of chrome and is still working fine on firefox. But now latest version of chrome and even other browsers like Opera have started throwing errors on invoking webcam - only https versions are allowed to use webcam.
Its a personal use software and i don't want to spend extra on a SSL certificate. Is there some option where in we can add exception for a http site to use webcam
Current Code:
function loadCamera(){
Webcam.attach( '#my_camera' );
Webcam.set({
width: 200,
height: 200,
dest_width: 200,
dest_height: 200,
force_flash : true
});
}
You could check out letsencrypt or certbot (basically the same). They issue SSL certificates for free and the setup is very straightforward and easy.
Link:
https://letsencrypt.org/
Related
I am currently using the FLASK developer HTTP server, and I am trying to build a local service (run on localhost) that serves files for a remote visualization website.
Here is the code for the python side
#app.route('/task/<path:path>', methods=['GET', 'HEAD', 'POST', 'PUT', 'DELETE', 'CONNECT', 'OPTIONS', 'TRACE', 'PATCH'])
def static_file1(path):
p = "./task/" + path
return flask.send_file(p, conditional=True)
For safari, it just works like a charm.
As this screenshot indicates, flask development http server can serve files partially.
However, it didn't work for firefox for one request but not for the other.
And here are the headers for the first failed request
Successful request header
So I do believe the CORS header (Access-Control-Allow-Origin) is set correctly, otherwise the second request would fail.
Then what did I do incorrectly?
Second part:
It also doesn't work in Chrome, both requests failed, but I found the article below explaining new security features:
https://developer.chrome.com/blog/private-network-access-preflight/#:~:text=%23%20What%20is%20Private%20Network%20Access,to%20make%20private%20network%20requests.
But even with "Access-Control-Allow-Private-Network" set to "true" (See screenshot above), both requests still failed in chrome. And error msg:
Access to XMLHttpRequest at 'http://localhost:10981/task/a5c8616777d000499ff0cd5dbb02c957/datahub.json' from origin 'https://somepublic.website' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `local`.
Any suggestion would be helpful!
Thanks!
Update 1:
After enabling ad-hoc SSL context (unsigned certificate) on the flask side, and using https on both localhost and "the public website", and changing the "#allow-insecure-localhost" flag in chrome to true, it works in chrome now. But still doesn't in firefox.
If you check the specification you will see that it is a "Draft Community Group Report" and
This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
The contribute list is made up entirely of people working for Google.
I can't find any mention of it in Firefox's bug tracker.
It looks like this is a highly experimental specification, which Firefox simple doesn't implement.
There doesn't appear to be any way to persuade Firefox to provide access from a secure, public Oritin to an insecure private origin.
Today we updated the last version of google chrome browser (Version 102.0.5005.61). We have an aplication that runs into a vpn. And since then we start getting this errors on the console:
As you can see we get a timed out error on the preflight and then the xhr request fails.
We noticed that on this version of chorme they add the new header: Access-Control-Request-Private-Network. An that is what I see on the preflight headers:
Serching on what could be wrong, since this is happening only when we update the chrome version and in other browsers the site works perfectly; Ive found this:
https://developer.chrome.com/blog/private-network-access-preflight/
On the article is explained what to do and how to handle this.
And show kind of what is happening to me:
If your request would have triggered a regular CORS preflight without
Private Network Access rules, then two preflights may appear in the
network panel, with the first one always appearing to have failed.
This is a known bug, and you can safely ignore it.
Based on that I added the new header support on my API that is made on JAVA with spring boot.
response.setHeader("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT, OPTIONS");
response.setHeader("Access-Control-Allow-Headers", "content-type");
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Max-Age", "180");
response.setHeader("Access-Control-Allow-Private-Network", "true");
response.setHeader("Access-Control-Expose-Headers", "Content-Disposition");
As you can see just added the header and return 200 for the option request
if ("OPTIONS".equals(request.getMethod())) {
response.setStatus(HttpServletResponse.SC_OK);
return;
}
The site is running, meaning it get served and is loaded on chrome browser but all the API calls from the site get that error. (See screen shoots avobe).
But still after that have the same issues. Any one had the same issue and was able to solve?
Any help will be appreciated!
Thanks!
EDIT:
We just add the headers on the preflight response:
Access-Control-Request-Private-Network: true
Access-Control-Allow-Private-Network: true
Then we go to the google flags configuration and disable this:
Now Im not sure why google thinks that my requests are insecure.
This issue is coming for Private and Public combination, like our web is deployed as CloudFront Public URL and backend is Private api hosting, so we are also facing this issue, currently only disabling "Send Private Network Access preflights" property of chrome is working (its only enough).
We have tried setting "preflight request will carry a new header, Access-Control-Request-Private-Network: true, and the response to it must carry a corresponding header, Access-Control-Allow-Private-Network: true" but no luck till now.
Our another web application on which FE/BE both are private hosting is working fine.
I've been investigating the implementation of CTAP2 protocol with Google Chrome (protocol between Fido Authenticator and Fido Client (e.g. Chrome)), which should be supported in Chrome since version 69.
So I dumped the chrome request to the authenticator in two cases:
1. U2F (CTAP1) with yubico demo website.
Here everything goes as expected and chrome follows the CTAP1 protocol.
2. FIDO2/Webauthn (CTAP2) with webauthn.org
And the browser has a strange behaviour:
It starts by following the CTAP2 protocol by sending a AuthenticatorGetInfoRequest
The Authenticator replies with AuthenticatorGetInfoResponse
But then Chrome switches to the CTAP1 protocol by sending a Registration Request Message (U2F_REGISTER)
Is it a problem with Chrome implementation: CTAP2 is not enabled entirely yet (it seems to be implemented in Chromium sources)?
Or is the problem coming from the authenticator: sending a response that makes Chrome switch to CTAP1?
Or something else entirely?
In AuthenticatorGetInfoRequest, the authenticator must respond with a string list of the supported versions among "U2F_V2" and "FIDO_2_0". Note also in case of NFC or CCID, a "FIDO_2_0" (CTAP2) only authenticator shall anwser directly "FIDO_2_0" on the SELECT command. I don't know about HID and BLE.
So maybe your authenticator is listing "U2F_V2" in the protocol versions list in AuthenticatorGetInfoRequest.
I also imagine the Chrome code base about this was moving fast and can be partial or not strict. To my tests in early 2020, the Chrome CTAP capabilities seem now stable and compliant.
I am experimenting with azure mobile services and have implemented the authentication example here. This works on most devices ( iOs, IE9 and chrome on desktop, IE10 Surface RT, android ) but on a WP8 device ( a Nokia 920, to be precise ) it returns
"Cannot reach window opener. It may be on a different Internet Explorer zone"
after attempting to return from the authenication providers pop-up. This is mentioned briefly in the link above, but only wrt to connecting to the service from localhost. This is not the case here and other devices work fine. It does not seem to be a problem with any particular authentication provider - all ( facebook, google, twitter, windows connect ) return the same message. And as these other devices work, it seems unlikely that the service is mis-configured, but there could very well be something subtle that I'm missing.
The way I got the authentication to work is not to use Facebook JavaScript SDK, but another flow, described here https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/#step2
For handling the response when I get the redirect back from Facebook, I used the following code:
function handleLoginResponse() {
var frag = $.deparam.fragment();
if (frag.hasOwnProperty("access_token")) {
client.login("facebook", { access_token: frag.access_token }).then(
function () {
// do your thing when logged in
}, function (error) {
alert(error);
});
}
}
This code makes use of jQuery BBQ plugin, found here http://benalman.com/projects/jquery-bbq-plugin/.
This way I can get Facebook auth to work on WP8 and I'm able to pass the access token to Mobile Services login.
A slight problem is that now the access token sticks in my site URL, which I think is a problem if the user decides to share the URL, for example. I think I can get around this by e.g. putting the info in a cookie (or local storage) and then redirecting to the plain URL of my site.
I came across this code change in Chromium. It says Chromium now supports both handshake versions, which the code seems to confirm. I mean the second version at Wikipedia (draft-ietf-hybi-thewebsocketprotocol-06).
However, when I connect to my server, the only thing I obtain is the old version, i.e. including these headers:
Sec-WebSocket-Key1: 4 #1 46546xW%0l 1 5
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
but not the new version which would be a request containing:
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
What am I missing here? I downloaded the latest nightly build and it has been included more than two weeks ago, so that cannot be the cause I guess.
How can I make a WebSocket send the new handshake version?
The code link you posted is for the server-side of the handshake (there is a few places this will likely be used in Chrome such as remote debugging and as a proxy for extensions).
If you really want use the new HyBi-07 protocol version you can try using this branch of web-socket-js that I made. Once Chrome switch to the new protocol, web-socket-js will switch by default also. In order to make web-socket-js work in a browser that already has WebSockets support you will need make some minor tweaks to it to use a different object name instead of WebSocket.
I expect Chrome/WebKit will add the new protocol before long. Note that the API changes to add binary support have only recent been decided so Chrome the new protocol may be added before the API fully supports the new functionality enabled by the protocol.
The only browser I know of that implements the 07 protocol is this build of FF4:
http://www.ducksong.com/misc/websockets-builds/ws-07/