I have some code that runs in a Windows service and sets some proxy settings on a per-user basis. Specifically it sets:
HKU[user sid]\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL
HKU[user sid]\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\EnableAutoProxyResultCache
HKU[user sid]\Software\Policies\Microsoft\Internet Explorer\Control Panel\Connection Settings
For "locked down" users it sets:
AutoConfigURL=http://127.0.0.1:8888/wpad.dat
EnableAutoProxyResultCache=0
Connection Settings=1
For "unlocked" users it sets:
AutoConfigURL (deletes this key)
Connection Settings (deletes this key)
Everything works great on Windows XP, in IE, FireFox, and Chrome. As soon as I restart any of those browsers, the new settings are used (uses the proxy or doesn't).
On Windows 7, everything works great in FireFox and IE, but not Chrome. Chrome doesn't start using the new settings until one of the following happen:
I run inetcpl.cpl and click the OK button (don't need to change anything, but do need to click OK, not just Cancel)
I log-off and back on the Windows user account
I run IE (just running IE and closing it)
I'm looking for a programatic way to reset this cache, whatever cache it is.
What I've tried but hasn't worked:
Almost every "netsh" command option I can think of.
InternetSetOption() (see MSDN) with the proxy settings changed and refresh flags (using NULL as the hInternet handle)
Deleted the values under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\
Has anyone seen this caching issue and found a way to clear it? If not, what info should I be looking for in general. Is this a WinHTTP cache, TCP, IP, WinInet? Even though it is only showing up in Google Chrome, I don't think it is an actual Chrome cache, I think it is at the OS level.
I know I should probably be using InternetSetOption instead of updating the registry directly, but that doesn't work from a service, and I've found some anti-virus programs that are causing issues with any desktop app level code (but they don't mind if my service updates things). Not to mention that some of the settings above require admin/elevation to modify, even though all under HKCU.
Appears to be a testing error, or an anomaly, calling this after setting the registry values does appear to work:
InternetSetOption(NULL,INTERNET_OPTION_SETTINGS_CHANGED,NULL,0);
InternetSetOption(NULL,INTERNET_OPTION_REFRESH,NULL,0);
Related
I've noticed that the Firefox profile database "places.sqlite" is accessed constantly by PID 4 (System). Even if I do nothing and just lean back.
My first assumption was that it had something to do with the session store but it would contine writing even when I disabled the automatic session save via about:config, also it's PID 4, not Firefox.
I would like to learn what kind of revelations my computer keeps having that are worth the write cycles.
Is it a CIA-level data exfiltration operation?
Because if that's normal - it's certainly where I would hide my activity.
I could also imagine the "Virus & Threat protection" having something to do with it but I've disabled that as well (temporarily and for the screenshot).
How do I find out what it is?
I initially installed the Microsoft Visual Studio Express 2013 for Web on my desktop. My desktop runs Windows 8.1 with internet explorer 11. It ran fine until the license expired after the first 30 days. I tried to sign in to renew the license, however after clicking the 'sign in' button I get an error dialog. The dialog states 'Browser is security restricted or javaScript is disabled. I have no other option but to close and exit Visual Studio.
I went to the online forums for Microsoft. There were discussions and suggestions on how to fix the error. I tried lowering the settings for the security tab in internet explorer. I have validated the option for scripting is enabled. I have also added https://*.visualstudio.com to the trusted sites tab. Other users on the forum have tried the same suggestions and have not succeeded in signing into the visual studio application.
I had exactly the same problem, here is what I did:
a) Go in IE, click on settings wheel then Internet Options and Security tab.
b) Click on Custom level button (make sure you select Internet zone).
c) In Security Settings window, under Scripting I set Enabled for Active scripting.
After that Sign In should work. Even though Chrome is default browser, it seems that VS uses IE for sign in process.
Hope this helps!
There is another issue people are running into that is a bug with the login dialog. The login dialog is using a Web Browser control to login the user. By default it loads up "about:blank" as the URI. It then proceeds to try to execute some JavaScript (just ";") to verify it has permissions to do so. On some machines this is problematic because "about:blank" has been mapped to zone 0, or the Local Machine zone. When the JavaScript is executed MSHTML will check the zone of the URI and then the policy for executing scripts. By default the Local Machine zone is locked down, and all script executions result in a Query policy. What this means is if you're running in immersion mode (aka in Internet Explorer) you will get a message box asking if you want to execute the script. However, the Web Browser control used by VS 2013's "Sign In" dialog doesn't run MSHTML code in immersion mode, so the Query policy effectively equates to a Disallow policy. The bug here is someone in VS assumed "about:blank" resolves to the Internet zone, and when it resolves to the Local Computer zone you get this behavior.
The workaround is to remove "about:blank" zone mapping. Point regedit to this key:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains]
Remove the "blank" key.
Alternatively you can change the Local Machine Lockdown policy for executing scripts. The reg key for that is:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones\0]
Set the "1400" DWORD value to 0.
There are many sites you need to list in your Trusted Sites. Following the trace of what the stupid, stupid login script does:
https://.visualstudio.com
https://app.vssps.visualstudio.com
https://.accesscontrol.windows.net
https://auth.gfx.ms
https://login.live.com
Only then was I able to log on to my FREE software.
Hi this is Albert from Microsoft. Just want to let you all know that this issue has been fixed in the upcoming Update 2 for Visual Studio 2013. Thanks for your patience while we figured this one out :)
Same problem "Browser is security restricted or JavaScript is disabled" here but the solution from #jic didn't work for me..
If you can and it is convenient for you this is a solution which worked for me:
I have created a new user/profile on my PC and for this user it was just working fine.
Before this action I have tried to make an user account which had this problem as:
Power user - didn't work
Administrator - didn't work as well
So the last solution in my case was a brand new user on the PC..
Here's what worked for me.
Open Control Panel, Internet Options.
First, I clicked the Security tab and turned security the security for the Internet zone to its minimum.
Next, click the Privacy tab, then click Advanced. Choose "Accept" for both types of cookies.
Of course you can change these all back after extending your VS trial.
you must change secure settings of iexplore for admin account. If logon by other account, you must start iexplore under admin account or logon under admin account, because you will get license after admin account.
Click on Start --> Run --> type cmd and click on OK.
Command Prompt will be opened. Then enter this command.
ipconfig /flushdns
and press Enter.
Now try to access https://app.vssps.visualstudio.com/Profile/View
It worked for me...
As I can not add a comment yet to the answer of CBGraham, I've to add this note over here:
The solution described from CBGraham worked for me (Thanks Graham). I had to add an additional link:
https://account.live.com
Then I opened the IE and tried to login to a Microsoft site. I left the IE window open and just clicked once again on the VS to login. Then it worked for me. Even with strong restrictions on the IE settings. While I'm surprised why someone should set down his security settings, just to register VS.
I am working on an ASP.NET MVC3 webapplication.
I have a button "Download" that downloads a file from the server.
<input type="button" onclick="window.location.href='#Url.Action("DownloadFile", "Home")';" value="Download"/>
In the HomeController I call the Action "DownloadFile" that returns the file
return File(fileToReturn, Path.GetFileName(fileToReturn));
This is working normally on all browsers.
however some people report that the download does not work on Internet Explorer 6.
I installed IE6 and tested the website on it and it was working normally.
So this is my question:
What may have cause the download to not work for certain IE6 but work on others?
First I thought it was a security option in IE. But then I tested on my IE6 for different security option, When I cannot download due to security reason I get a message Your current security settings does not allow this file to be downloaded But they are not getting this (the file just does not download without anything happening)
What may be causing this? I am unable to reproduce it in order to fix it.
Thanks a lot for any help
I had a similar problem once and managed to fix it by following these steps:
In Internet Explorer, click Tools, and then click Internet Options.
Click the Security tab.
There are four security zones listed: Internet, Local intranet, Trusted sites, Restricted sites. Click the zone your website is in (when you navigate to your site, the current zone is displayed in the status bar at the bottom of IE's window).
Under Security level for this zone, click Custom Level.
Under Downloads, under Automatic prompting for file downloads, click Enable, and then click OK two times.
You say you've checked that it isn't browser security settings, but it might be security settings on their network, not just the browser.
If their network firewall is configured to prevent certain types of files from being downloaded, then there may be nothing you can do to get around that, short of changing the file type you're sending. (or talking very nicely to their network operator).
Given the security risks involved in running IE6 these days, I imagine most companies still using IE6 would have pretty paranoid network security settings, so this is quite a likely explanation.
Due to the recently added "feature" in IE8 where new windows are automatically associated with a single session, some of our code is behaving erratically.
This is because a separate app would launch a new IE window when it was activated, and once the user was finished, close the window. This worked fine in IE7 because the session information in the windows stayed separate. However in IE8, since the session is shared among IE windows, we find that the "pop up" app would corrupt the session on the first app.
I have read about the nomerge switch, so that is a workaround, but I was wondering if there was a way of working the solution into the "CreateObject" of vbscript; i.e:
Dim ieWin As Object
Set ieWin = CreateObject("InternetExplorer.Application")
Is there a way of sending parameters when calling the CreateObject function?
No, there's no way to use COM to create an IE instance that specifies this behavior (or any of the others, e.g. InPrivate, No Add-ons, etc). The only thing you can do is create an automation instance that defaults to MediumIL using the CLSID provided for that purpose. http://blogs.msdn.com/b/ieinternals/archive/2011/08/03/internet-explorer-automation-protected-mode-lcie-default-integrity-level-medium.aspx
If you have control over the web application you are loading with your IE window you can set it's session to "cookieless" (http://msdn.microsoft.com/en-us/library/aa479314.aspx) which will avoid the issues you're having with multiple instances.
The solution we ended up going with, although it's more a work around than anything else - was assigning a new url to the popped up window.
Previously, it worked as follows:
Call centre agents would be using our internal app for other duties
e.g. "http://internalsite/somepage.faces" on a day to day basis.
When they got a phone call, a third party app would fire up
"http://internalsite/customerdetails.faces". This caused the issues mentioned above.
The solution we went with:
We assigned "http://internalsite/customerdetails.faces" it's own url e.g."http://customerdetailminisite/customer.faces".
This way the call center agent could keep their main window open for other stuff and still be able to handle calls when they came in.
I recently reinstalled XP and then SP3 and I'm currently getting an error whenever I try and copy something from a network share.
Title: Internet Explorer
Message: This page has an unspecified potential security flaw.
Would you like to continue?
I believe it's related to KB921398 (MS06-045) and I'm currently uninstalling SP3, but does anyone know if there is another way to disable this specific update? It does not appear in Add & Remove Programs.
There's a temporary fix by adding any network ip masks to the trusted intranet zones in Internet Explorer's Security settings, but it's no fix :(
There's a temporary fix by adding any network ip masks to the trusted intranet zones
That's the real fix. The error message occurs when you are trying to copy files out of the Internet Zone. And it is indeed risky if you really are dragging files out of a public-internet network share, so the message isn't really wrong (just vague and misleading).
To avoid the error popping up in your intranet — and because it's the right thing to do anyway — you need to make sure Windows sees the intranet as being in the Local intranet Zone.
Go to Control Panel -> Internet Options-> Security -> Local intranet -> Sites. If “Automatically detect intanet network” is ticked, untick it as obviously the automatic detection isn't working. Turn on the top two; if you're sure that you will never be accessing network shares outside the intranet (eg. because a firewall prevents it), you can tick “Include all network paths”.
If this doesn't work add the folder path as a trusted Local Intranet site.
This is the correct fix, because of the tie in between IE and Windows Explorer. What i have found is a neat trick because all of our servers export their windows shares on a common subnet. add this one line to Intranet Setting "File://192.168.0.*" (change for your correct subnet).