We Keep Coding

How to get Chrome to stop asking me whether its ok to use the camera?

I am doing some html/js/webrtc work with the webcam. Even though I am hosting files from the web server on my machine (thus 127.0.0.1), Chrome asks me whether its ok to use the camera every time I reload the page.
How can I get it to stop?

Just activate chrome://flags/#allow-insecure-localhost. This will work like https and fix a lot of development problems, including invalid ssl certificates.

use https. Chrome does not persist permissions on http and getUserMedia will stop working there soon (even though possibly not on localhost).
Alternatively, use command line flags like --use-fake-ui-for-media-stream to skip this.

Safety script to clear cache and leave website immediately

I am working on a website for a women's shelter and they want a "panic button" that automatically takes you to another site. This is pretty common, but I need it to also automatically clear the cache, so the abuser can't hit the "back" button or history to see what they were looking at before being interrupted. Any ideas?

I think that the answer is "can't be done as website functionality" unless the user installs a browser plugin. For example, here's what Mozilla Development Network (MDN) says about this:
For security reasons .... there is no way to clear the session history or to disable the back/forward navigation from unprivileged code. The closest available solution is the location.replace() method, which replaces the current item of the session history with the provided URL.
Non-privileged basically means any javascript that a website might run on the browser.
Now a "panic button" plugin / add-on would be able to do this kind of thing, but:
The user has to install it. (Simple for a moderately tech-savy person ...)
If someone looks at the browser, it will be apparent that it has been installed.
There is also the issue of people how people decide to trust a plugin like this to be properly implemented, and not contain nasty stuff.
A better idea would be to educate the user in using browser incognito mode. However that still leaves traces on the user's computer (depending on your browser, and other things), and in external network logging, etc.

Strange website redirect issue on mobile browser that's influenced by cache

I'm at a loss here.
I have a new Wordpress site at synergration.com.
If you access it on a mobile device (phone, not tablet) it will generally load fine the first time. Once you click on to another page and/or reload the home page it jumps into a redirect loop indefinitely attempting to reload the same page over and over and over...
I've weeded through the code and have been unable to find any JS redirects. I've also contacted the theme developer and they've been unable to help.
This only became an issue when I started hosting on WP Engine. They use some advanced caching that seems to be the culprit here as when I test the mobile site on their staging server (where no cacheing exists) it loads fine.
I contacted WPEngine about it and this was their reply:
This is being caused by our caching systems that run on our platform.
It looks like the theme is handling an internal redirect that detects
the user agent (desktop or mobile) and redirects the visitor to the
appropriate site based on that information. However, the redirect is
getting stuck in cache, causing the mobile version to load in an
infinite loop. Unfortunately, we don’t have an easy solution for this.
If this were only one part of the site, we could just exempt that part
of the site from caching, but because it covers the whole site,
exempting from caching isn’t an option. Our staging area is exempt
from all caching, which is why it’s working normally there. (The old
host was most-likely using a non-cached environment, which is why you
didn’t see this issue there). I would contact the theme developer and
ask them if they’ve ever come across this issue before. There’s a good
chance they have, and they might have a clever solution as a
work-around. You might have the option of disabling the mobile
routing, which would solve the redirect issue, though mobile devices
would load the full version of the site rather than the slimmed-down
mobile version.
As noted above, the theme developer didn't have any solution and I'm back at square one so I figured I'd reach out to stack to see if ya'll had any ideas.

I have two sites on WP Engine with redirect. They are identical gensis child themes and redirect plugins. I have one setup with a DNS redirect to a cname record for a "M.sitename.com" URL and the other redirecting to the mobile site that is having the same issue you noted above. I haven't had an issue with the site that points to the cname record. I am about the change the other site to the cname configuration to see if it makes a difference. I have no ideal why this works, but thought you might find this of value.

It works absolutely fine in my mobile's Opera Mini browser. To answer your question, an alternative way is to just create a mobile subdomain, like m.yourdomain.com. Make this decision public and let mobile users know in advance that that is the site for mobile users. A specific mobile site is loads better than visiting the page and then being redirected. It also saves time.
While developing the mobile site, keep in mind, to use minimal JavaScript. The reason being, that older mobile versions may not support JavaScript and if JavaScript is essential then it becomes a big problem.
Speaking about the theme, if it is getting stuck and developer has no idea, so the best option, FOR NOW, is change the template. Let the developer inspect on his very code. You can by that time use another template, that'll keep the site up running well whether it is on Mobile or anything. Because, small errors can divert lot of traffic from your site. I, to be frank, have no idea about what caching problems WP is having, and I don't expect anyone here to be knowing that, so it really depends on time. Till then, as I said, do try to use some other template for the time-being.
All the best.

I faced similar issue recently. It took good amount of time but I finally figured it out.
To prevent redirect from caching, you have to use 302 redirect. Moreover, you have initialize this redirect in "template_redirect" action of wordpress. If you do it in like "init", it'll be cache too.

WebSocket on IE10 giving a SecurityError

I am currently developing a website under IE10 (on Windows 8), using WebSockets in JavaScript. It runs fine under Firefox 18 and Chrome 25, but on IE10 I get a SecurityError when I establish the connection.
What I am doing seems pretty straghtforward :
websocket = new WebSocket('wss://hello.dev.mydomain.net');
But IE doesn't like it :
SCRIPT5022: SecurityError
The script is on "https://test.dev.mydomain.net" (not the real address obviously).
What bothers me is that if I just double-click the file on my local computer (e.g. file://...) it just works. Even worse: if I use fiddler to monitor HTTP traffic... it also works. Whereas there seems to be no connection at all without fiddler, as detailed in the API's specs. (See below.)
Judging by websocket spec, the exception should also appear on Chrome/Firefox... but it does not. So I doubt it has anything related to HTTP/HTTPS. In any case, I am using a wsS socket on a httpS page... Moreover: when I replace the wss address by another valid server found on an online example, it works.
I don't know if this is relevant, but the IP from test.dev.mydomain.net is 10.14.x.x where hello.dev.mydomain.net is 194.247.x.x. I don't know if it could trigger some kind of security on IE only...
One more thing: I have a certificate for *.dev.mydomain.net, IE does not seems to have problems with it. The script originally resides on a server called my.name.dev.mydomain.net, but since I am accessing it from another URL (I got a redirect since we first thought it could have been some kind of Same Origin Policy issue), I don't see how it could matter. At least I hope it does not...
Any idea is welcomed.
EDIT: adding the sites to the trusted zone does not work either.

It looks like IE throws a SecurityError if you're trying to open a websocket on a local (intranet) domain. To overcome this, you may disable IE's automatic algorithm for recognizing local sites. This can be done in Tools > Internet Options > Security > Local Intranet > Sites.
Uncheck all checkboxes (or only a particular one, if you know how exactly your domain did end up in intranet ones).
Note that IE uses (among other things) its proxy settings to determine local sites: if your domain is listed as excluded from proxying in proxy settings, then it will probably be treated as intranet one. This is why WebSockets work if you enable Fiddler: it modifies IE proxy settings and thus the list of intranet sites changes.

I had this problem in Windows7/IE11 after applying a security patch. For Windows10/Edge is the same story.
As this is a local websocket (ws://localhost) you have to add ws:\\localhost\ to Internet Explorer configurations (Tools > Internet Options > Security > Local Intranet > Sites > Advanced).
In Windows 10/Microsoft Edge you will find this configuration in Control Panel > Internet Options.
UPDATE
The address of your webapp (https://test.dev.mydomain.net) must be added to the local intranet zone too. Note that in the image the webapp address should be added.

Well, my question wasn't that successful, so I'll post the "workaround" I found.
I got another address for the website, in 194.247.. too. This, magically, solved it. Guess IE doesn't like mixing local and external stuff and watches the IP.
Anyways, I hope this may come in handy to anyone who's got the same issue.
If you have a solution to solve the "real" issue by configuring IE, let me know :)
Cheers,

Browsers has a websocket limitation. For example Internet Explorer has default limit of websocket connections set to 6 per host header name. the same limitation is set for WinForms WebBrowser component.
The solution is to add values under key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WEBSOCKET_MAXCONNECTIONSPERSERVER in registry. Just add DWORD value with executable name , for example iexplore.exe (or your application executable name if you use Web browser component) and set value from range 2..128
Second option how to solve SecurityException is to create multiple subdomains.

The client hostname/IP Address should be same as server IP/Hostname thats listening to otherwise you would get the above error.
1) Make sure whether server hostname configured to listen at IP/localhost etc andif not explicitly specify the hostname ast server
2) use the same hostname in the client. THis will solve the issue. It worked for me...

I encountered the error (although it did not say the SCRIPT5022 part, rather it just reports "ScriptError"). I got around the issue by clicking on "Trusted Sites" and then adding the machine hosting the remote websocket. Note, to add to trusted sites,
I had to supply the address without the "ws://" part (like just mymahcine.mydomain.com)
I had to uncheck the box that says "Require server verification https:// " option.
After I was done adding the domain, I re-checked the box "Require server verification (https://). I would recommend everyone to do the same. Unchecking the box is only a workaround to add sites that don't begin with https (rather ws:// in my case)

I had the same issue at one of my customer's environment.
It turned out that they had a proxy configuration that did not allow the connection to the WebSocket endpoint directly and did not support the WebSocket protocol.
The temporary solution was to disable using the proxy and everything started working. The long term solution is to edit the proxy's configuration (.pac file) to exclude the address of the WebSocket endpoint.
To disable the proxy, go to: Internet Explorer Options > Connections tab > LAN settings button > un-check Automatically detect settings.
Hope this helps someone.

In addition to making sure that the internet zone is not localhost (as in above answers), ensure that if https is used, then wss should be used.
This is not an issue in other browsers, but IE is abit more finicky.

Chrome doesn't delete session cookies

I'm trying to set session cookie in javascript like this:
document.cookie = 'name=alex; path=/'
But Chrome doesn't delete it even if I quit browser and launch it again.
I checked in Firefox and Opera and both work as intended - they delete session cookie on browser exit.
Is Chrome just ignoring expiration rules?
I checked in multiple OSes and found out that session cookie gets removed on Chrome in Windows XP and Ubuntu, but NOT in Mac OSX Lion.

This can be caused by having Chrome set to Continue where you left off.
Further reading
Bug report: Chrome is not deleting temporary cookies – i.e. not logging me out automatically when I close all browser Windows
Issue 128513 in Chromium: Session Cookies not cleared when Chrome processes closed
Issue 128567: Session only cookies don't delete

I just had the same problem with a cookie which was set to expire on "Browsing session end".
Unfortunately it did not so I played a bit with the settings of the browser.
Turned out that the feature that remembers the opened tabs when the browser is closed was the root of the problem. (The feature is named "On startup" - "Continue where I left off". At least on the current version of Chrome).
This also happens with Opera and Firefox.

I just had this issue.
I noticed that even after I closed my browser I had many Chrome processes running. Turns out these were each from my Chrome extension.
Under advanced settings I unchecked 'Continue running background apps when Google Chrome is closed' and my session cookies started working as they should.
Still a pain in the rear for all of us developers that have been coding expecting that session cookies would get cleared when the user is done browsing.

I had to both, unchecked, under advanced settings of Chrome :
'Continue running background apps when Google Chrome is closed'
"Continue where I left off", "On startup"

This maybe because Chrome is still running in background after you close the browser. Try to disable this feature by doing following:
Open chrome://settings/
Click "Show advanced settings ..."
Navigate down to System section and disable "Continue running background apps when Google Chrome is closed".
This will force Chrome to close completely and then it will delete session cookies.
However, I think Chrome should check and delete previous session cookies at it starting instead of closing.

A simple alternative is to use the new sessionStorage object. Per the comments, if you have 'continue where I left off' checked, sessionStorage will persist between restarts.

This issue is caused because you are using Continue where I left off and Continue running background apps when Google Chrome is closed feature of chrome (currently my version is 96).
Please consider setting those off (to test functionality).

I had the same problem with "document.cookie" in Windows 8.1, the only way that Chrome deletes the cookie was shutting it from task manager (not a really fancy way), so I decided to manage the cookies from the backend or use something like "js-cookie".

Have you tried to Remove hangouts extension in Google Chrome? because it forces chrome to keep running even you close all the windows.
I was also facing the problem but it resolved now.

Go to chrome://settings/content/cookies?search=cookies
Enable Clear cookies and site data when you quit Chrome.
Worked for me

If you set the domain for the php session cookie, browsers seem to hold on to it for 30 seconds or so. It doesn't seem to matter if you close the tab or browser window.
So if you are managing sessions using something like the following it may be causing the cookie to hang in the browser for longer than expected.
ini_set("session.cookie_domain", 'www.domain.com');
The only way I've found to get rid of the hanging cookie is to remove the line of code that sets the session cookie's domain. Also watch out for session_set_cookie_params() function. Dot prefixing the domain seems to have no bearing on the issue either.
This might be a php bug as php sends a session cookie (i.e. PHPSESSID=b855ed53d007a42a1d0d798d958e42c9) in the header after the session has been destroyed. Or it might be a server propagation issue but I don't thinks so since my test were on a private servers.

I just had this problem of Chrome storing a Session ID but I do not like the idea of disabling the option to continue where I left off. I looked at the cookies for the website and found a Session ID cookie for the login page. Deleting that did not correct my problem. I search for the domain and found there was another Session ID cookie on the domain. Deleting both Session ID cookies manually fixed the problem and I did not close and reopen the browser which could have restored the cookies.

The solution would be to use sessionStorage, FYI: https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage

Google chrome has a problem if you set and unset cookie improper way. This is php code. Thought this will give you idea.
Set cookie
setcookie('userLoggedIn', 1, 0, PATH);
Wrong way and will not work (notice PATH is missing)
setcookie('userLoggedIn', 0, time()-3600);
Correct way fixes issue on google chrome
setcookie('userLoggedIn', 0, time()-3600, PATH);