I have http connection code that does the typical
InternetOpen -> InternetConnect -> HttpOpenRequest -> HttpSendRequest using wininet,
which worked just fine on all the prior versions of windows , but win server r2 x64 what is happening is that everything else works just fine but the cookies aren't being accepted and returned on subsequent calls( I love wireshark) ( causing things to fail). So I've been starting at the various flags and options available to the 4 different calls, as well as InternetSetOption and InternetSetPerSiteCookieDecision. And I just haven't seemed to find a way to make 2008 server accept the cookies yet. The only catch is that I'm using a straight ip (say 192.0.0.1(not real ip) )and not something like www.foo.com.
http://msdn.microsoft.com/en-us/library/aa918417.aspx
please check: "Privacy settings" and "Per site cookie handling"
Related
I built a web service and connected it to Windows Federated Search successfully.
Windows Search displays the results just fine when the URL returned by the web service for each result has an URI scheme of http or https but the results are blocked otherwise.
For example, URLs like "file:///C:/Users/Public/Pictures/Sample%20Pictures/Chrysanthemum.jpg", "mailto:someone#example.com", "onenote://note/", etc., all fail. I am particularly interested in opening items with custom URI schemes.
Internet security settings blocking search results with file scheme
Internet security settings blocking search results with mailto scheme
I spent several hours reading about Protected Mode, doing changes to the security zones, changing "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults", "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy", "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ProtocolExecute", running explorer.exe elevated (to check the integrity level was the problem) and even disabling Protected Mode and UAC but the result is the same so I wonder if this way of extending Windows Search was designed to support non-HTTP schemes.
I am using Windows 7 Professional Service Pack 1 64-bit and Internet Explorer 11.
"I wonder if this way of extending Windows Search was designed to
support non-HTTP schemes."
My guess is "No" it wasn't, and that the lockdown there is present for security reasons. You could probably return a HTTPS URL to a web server that itself redirects to the target protocol or attempts to invoke it.
I am forced to use a visual-svn-server that is located in our windows domain. The problem is that it is super slow to use with windows client. Weird thing is that the same repository is very fast with linux client. The difference is like 3sec vs 90sec. I know somebody should fix the server, rather than me trying to fix the client, but i have no change of doing that.
So, to debug the problem I did some package capture with wireshark and it seems like windows, when doing 'svn up' (on up to date repository) does quite much ldap-negotiations before actually talking again with the actual svn-server. This takes time. Linux svn client when doing 'svn up' is not doing any ldap calls. The problem is not on my machine, but on all my colleagues windows clients too.
I tried forcing the svn client to 'basic' auth with configuration option http-auth-types (http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html), but it didnt help. I figured that would be basic, no ldap, http-basic-auth. I am able to confirm that the setting is included, since setting it to 'digest' says that authentication method is not available. But even that takes about 60s, so my guess is that its doing the ldap-wacko stuff before trying to do the authentication.
The subversion client i am using is 1.8 serie from tortoise svn official build. I did try also slicksvn client and it did have the same problem. The svn versions shows ra_serf is handling the https requests and my repository is visual-svn server located at https://my_server_intra_dns_name/
When opening the address with browser, its again fast as it should, so problem should not be with dns or similar.
I am linux guy, so i am bit lost with windows, but does anybody have an idea wtf is going on here?
---- edit ----
I had also linux as guest operating system on the windows host, and inside that linux doing svn up was about 3s, compare that to native windows 'svn.exe up' that took over minute !
If a Windows machine has a limited connectivity to the Internet, then you may notice the delay when running Subversion client command's against a remote repository over HTTPS.
Using a traffic analyzer you can notice, that the delay happens when Windows attempts to access ctldl.windowsupdate.com and gets a timeout. Windows attempts to access ctldl.windowsupdate.com to check Certificate Trust List (i.e. Certificate Revocation List). With limited Internet connectivity, Windows may be unable to access it thus resulting in these delays.
If it's not your case, then I suggest contacting VisualSVN's support team for investigation.
In my case it was due ot Windows proxy settings - that you set in IE (I use TortoiseSVN client, and Visual SVN Server was set to use basic authentication).
After I've set up IE proxy settings accordinlgy (automatic for me, but for you it might be something different) initial delay was gone.
It helped even though the svn server is on local LAN and I have checked with Wireshark if the traffic goes over proxy. In Tortoise I have proxy disabled. Why it helped with my issue - no idea.
The initial delay I had was 11-13 seconds. Now next to none.
And I am not using ssh client.
Go to http(s) location of your SVN server using your browsers: IE, Fireofx, whatever, and if the response is quick then it is very possible that is an svn client problem, or due to some similar settings (similar to your browser settings).
For instance IE was slow (IE was set up for local connection only previously), Firefox (with proper proxy settings) was OK - and SVN server IS local (sounds like some sort of network/firewall/routing issue to me, but proxy settings helped me).
Migrated an applicatoin from Window Server 2003 to Window Server 2008 x64. We have a simple VBS script that goes outside the domain and grabs a XML document using a post request. The script works perfect on Windows Server 2003, however on the new server, we keep getting a status code of 407 (proxy authentication failed). I did verify that I could pull in a file without setting any proxy information from the intranet. Was there any change to the proxy credential methods in Server 2008?
Code Simplified:
Dim o
Set o = CreateObject("Msxml2.ServerXMLHTTP.6.0")
o.open "POST", "https://somesite.com", false
o.setProxy 2, "myproxy:8080", ""
o.setProxyCredentials "user", "pass"
o.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
o.send "loginId=USER&password=1234"
While o.readyState <> 4
o.waitForResponse 1000
Wend
Wscript.echo o.status
It does seem the proxy is being contacted, because without it I get server name or address could not be resolved, however the proxy user/password are not being validated correctly, yet work on Window Server 2003.
Edit 20140303: It's been months and I still haven't figured this out. As we look to retire our Windows 2003 machines it's become increasingly important that I figure out what is going wrong.
I noticed if I changed my send data to incorrect UID/PWD I get a response back from the page (the incorrect login page). I don't understand why this works flawlessly on Server 2003 but seems impossible on Server 2008 R2.
If I open up IE on the same box, and use the same proxy information and access the same site with the same UID/PWD it also works. I did this to make sure there wasn't some sort of IP based block where the proxy or site UID/PWD only worked from the old machine.
I have an old laptop running WinXPpro and both IE8 and CoolNovo which can download an applet just fine from our Win2008 Server R2 SP1 x64 IIS 7.5.7600.16385. I have a new laptop (same hardware) with a x64 Windows7 and IE9 and CoolNovo which can't download the applet (.jar file) from the same server. I can download this .jar file directly as a url and I can download and run the applet over the internet from the .jar product provider on both laptops just fine. So it has something to do with my new laptop. If we add anonymous authentication to the web server, our app works on both too.
Using fiddler, I can see the NTLM authentication conversation on both laptops. On the old one, it works just fine:
A 401 with the WWW-Authenticat Header is present: Negotiate and one for NTLM
Then a 401 (challenge - NTLM type 2),
Followed by a 200 with the client sending the NTLM type 3 header
On the new laptop, I get the first two 401s, but no 200. It simply tries again with the 401s 2 more times.
Any ideas why the new Windows7 laptop would not be sending a 200 NTLM type3 response to the server or what the issue here might be?
Old Laptop: jre6: 1.6.0_30 checked as the user java runtime env. No System java runtime versions checked.
new Laptop: jre6: 1.6.0_31 checked as the user AND system java runtime env.
TVMIA.
I've encountered the same issue and after looking in server security log a have found two strange record just after each unsuccessful logon:
1. 4624 - successful logon. and just after that:
2. 4634 - successful logoff
Very strange... I've googled for these event codes and found this thread:
SCCM reporting not working on W2K8 R2 64-bit
And the solution to this problem is:
1. Open the IIS Manager and go to your site
2. Double click Authentication under IIS
3. Click on Windows Authentication and then choose "Providers..." under Actions
4. Add NTLM if it isn't there and move it to the top.
5. Click OK
It worked for me!
I am just curious - did anyone got Fiddler to work with Windows Phone 7 emulator (RTW build)? When I try working with Fiddler, I am getting a WebException when working with HttpWebRequest insances - NotFound, to be specific. WireShark works fine.
The problem I see here is that Fiddler acts as a proxy and the WP7 application I am using doesn't go through a proxy to pass the request, while WireShark works differently - it doesn't directly pass traffic through it.
There was a similar question here but in my case I would like to override the proxy settings so that the WP7 application will connect to http:/127.0.0.1:8888 as the proxy address. Since WP7 tools are based on Silverlight, is it possible to direct a HttpWebRequest to a proxy first?
EDIT: On this page (Fiddler documentation) it is stated that XDE (Windows Phone 7 emulator) should automatically pick up system proxy settings, but for some reason it seems like it doesn't.
As a temporary workaround for this, you can set Fiddler as a reverse proxy. The process is described here. I used the second option by creating a rule.
NOTE: You have to set the initial host (in the if statement) to the Fiddler proxy location (since the WP7 emulator can see the proxy address). The second URL is the address you want to redirect to.
It will now capture traffic from Windows Phone 7 emulator, although it will still skip some things (like downloaded images), so use this method for testing purposes only.
Here's the very simple solution that worked for me: Link