My site is running on SSL. On one of the pages I am calling an external javascript required for integration of Birt iHub into our application. The iHub application is running separately on of o our servers and javascript also resided in same application. Now when I try to acces the javascript without SSL it is blocked as my site is running on SSL. So I also put the iHub app on SSL so tha my website communcate with javascript over SSL. Now it works fine for both Chrome, Firefox and IE but in case of Safari it worked for few days then suddely an SSL error shows up. I have delete the SSL certificates from cache and the access the site again and IT worked again but afeter some days same issue occurs. AndI have to delte it again to make it work.
Can anyone tell me whay this is happening and what could be done to avoid this
Related
I use p5.js in my school project and it does not work in Google Chrome(also Microsoft Edge, idk about Opera), with JavaScript activated, but only when its on hosting. When I got it on Localhost it works just fine. In Mozilla it works in both situations. Iam confused.
http://klauzury2c2021.8u.cz/
you can find all of the code on the site
It looks like you are are hitting this issue with the p5.Sound library that prevents it from working correctly when loaded over http. Since you're hosting your site on a public server the best solution would be to enable HTTPS for your server and have HTTP requests redirect to the HTTPS url. However if you are unable to do this you can make this work with an AudioWorklet polyfill. Just add the following line to the head of your html file:
<script src="https://unpkg.com/#free-side/audioworklet-polyfill/dist/audioworklet-polyfill.js" type="text/javascript"></script>
Updated ↑ Old Answer ↓
I originally misread your question and though you were specifically struggling with testing on localhost. Here are instructions for cases where you are testing with a local server:
Apparently people have had success working around the issue using a tool called ngrok. Which allows you to expose a local service via a public HTTPS endpoint. So if you're running a local HTTP server on port 3000 you would open a terminal and run ngrok http 3000 (having followed the basic installation and setup steps for ngrok). Nrok will assign you a public URL, which it will display in a message to the terminal like this:
Forwarding https://<UNIQUE_ID_HERE>.ngrok.io -> http://localhost:3000
Then instead of accessing your sketch page via http://localhost:3000/ you can access it via https://<UNIQUE_ID_HERE>.ngrok.io/ and that should work around this p5.sound issue.
I have some troubles to start my WebApp with Chrome (not always).
My webApp is a simple Javascript App and it's loaded using HTTPs. The server providing the WebApp resources is using a self signed certificate that is not trusted by Chrome (same for Firefox...).
When a user starts for the first time the WebApp (or after cleaning the Chrome's cache) using an URL like https://mywebapp:8443/ui the user gets a message that the website is not trusted (ERR_CERT_AUTHORITY_INVALID) but the user can continue (it's the expected behavior).
Next, there's the issue: Chrome starts loading my webApp by getting the index.html and then the .css but it's unable to get the .js that contains the Javascript code of my webApp.
In the Chrome Development tool, I can see the response of the HTTPs request to get the .js file is "Failed to load response data".
I don't understand why there's this error with Chrome (it never happens with Firefox).
Next, if I reload the page in Chrome, the WebApp is successfully loaded and displayed.
I can reproduce this issue when I'm cleaning the cache in Chrome. If I'm not cleaning the cache the WebApp continues to work even after a Chrome restart.
Can it be due to the self signed certificates? What can be the reason of this issue during the first start? Why it happens only with Chrome?
Thanks for your help,
I guess it's due to using a self signed certificate,the newest Chrome Brower don't allowd trust self signed certificate,so your own certificate is not trust by chrome!
You can into chrome://net-internals/#hsts in brower address blank,then delete 'localhost' in HSTS list.
I was wrong, the issue was also appearing in Firefox.
I have found the root cause, it was due to the backend that uses a Kong cluster between the WebApp running in the web browser and the tomcat server that is located behind Kong.
An important things is that I'm also working in a DC/OS environment and between the WebApp and the Kong there's a marathon-LB !
Ok, the issue is the marathon-LB is dispatching the requests from the WebBrowser to one of the Kong from the cluster. Each Kong has its own self-signed certificate and as a consequence, the web browser gets responses from the same IP# signed with different certificates (since each request is managed by a different Kong).
When I configure the Kong cluster with only one instance everything work well because it's always the same Kong that is responding and all requests are signed with the same certificate.
The solution is to configure the marathon-LB with a certificate and then only this one will be forwarded to the WebBrowser instead of the Kong certificate.
I am trying to run tests against my vagrant box with lives at 192.168.0.100. In my hosts file I have 192.168.0.100 lc.mysite.com and the site loads fine and works normally at that url with chrome.
However, when I try and run my tests against it, the url fails and never loads anything. Remote urls work fine but the local ones are just failing.
How can I get casperjs to respect my hosts file? Or is it something else?
If you are using a self-signed SSL certificate (e.g. on your development box), set phantomjs option
--ignore-ssl-errors=true
From the documentation:
--ignore-ssl-errors Ignores SSL errors (expired/self-signed certificate errors): 'true' or 'false' (default)
Turns out it was due to the url being ssl and it kept failing. Using this answer solved my issue.
CasperJS/PhantomJS failing SSL handshakes on some sites even with --ssl-protocol=any
I am working on an Adobe Air product that fetches data from the web using air.URLRequest, from both HTTP and HTTPS sites. It is working absolutely fine on most computers, but there are a few people for which it is stalling when it has to fetch from HTTPS sites.
The error returned is just this: ERROR #2032 Stream Error. Doesn't say much.
I asked the people who had the problem to install Fiddler so that i can debug it and activate HTTPS decryption, but there is no way to debug because it works when Fiddler is open.
The application is built using JavaScript, HTML and CSS and the PC's with the problems are using either Windows Vista or Windows 7. I am also using Windows 7 but it's working fine for me.
Any idea how i could fix this very weird issue ?
Thanks!
Alex
I'm trying to create a web page that can connect to a client-local WebSocket server. The idea is to use the JavaScript client running in the browser as kind of a proxy to enable communication between the remote web server and the locally installed client application which implements the WebSocket service.
So basially, what I'd do is load a web page from https://example.com which includes some JavaScript that opens a new WebSocket to ws://localhost:1234/context.
This works fine as long as the web page is accessed via http. As soon as https is used, however, Firefox and Internet Explorer refuse to connect and the WebSocket constructor throws an exception (SecurityError, code 18).
Now, I already found advice from Mozilla stating that https sites should only use secure (wss://) WebSockets and plain http sites should only use plain WebSockets (link). But I don't really see the security issue when connecting to localhost from within an https context. Besides, this works like a charm for Chrome, Opera and Safari.
So the actual question is: Is there any way to work around this issue? Like introducing a non-https context inside the web page or something similar to get all browsers to connect to ws://localhost from within a https-delivered web page?
Thanks a lot in advance! I'm not exactly a web developer so this kind of browser-specific behaviour isn't really in my fields of expertise :)
You have to accept the cert first.
You can do this by simply going to https://localhost:1234/context, in your case. Once that's done, you can use the wss URL in your question.