Cookies and compact privacy settings for IE

[MarkH]

I’m having trouble with cookies and privacy settings.  I have a web server running IIS on port 80 serving various static pages.  Some of those pages link to a net talk web server app running on port 88 on the same machine.  Ever since version 4.29, IE has issues accepting cookies with the default (medium) settings.  Firefox and other browsers work fine.  Unfortunately most of my traffic uses IE and is computer illiterate.  So, how do I convince IE my site’s cookies are safe?   I have a privacy policy in the Web\W3D folder and IE finds that ok.  I’ve tried various ways off passing a compact policy as part of a header or within a cookie but can’t seem to get it right.  Does anyone have an example or know how to handle this?

[Bruce]

Hi Mark,

There are a portion of users who have cookies completely disabled in their browser - but they have a universally poor web-browsing experience, so your app won't be any different. At it's heart, in theory, NetTalk can be made to work without cookies, but it's very difficult to do without introducing bugs. So for all practical purposes cookies are "required".

Now when you embed one site _inside_ another site, and the one "inside" wants to use cookies, then things get exciting. The browser gets peeved with this (typically because it's a technique used mostly by marketeers to track viewing patterns.)

So rather than try and convince IE (which, if you could do this, would make the IE feature redundant in the first place) which you probably won't manage, it might be better to "merge" your site with the static one.

The first, and easiest approach -especially with an existing site which is all-static, is to simply move all the static pages to the NetTalk server, and let the whole thing get served on port 80. The only reasons not to do it this way are;
a) port 80 is shared with other sites and
b) the main site is hosted at one ISP (maybe on Linux) and you're providing the dynamic stuff at a separate venue.

The sharing issue will go away with NetTalk 5 - it has the functionality to serve multiple domains on the same IP/Port connection. The hosting issue opens the door to moving the host - ie hosting the site on a dedicated Windows server (or shared computer via a Windows Virtual Machine). There are plenty of ISP's now offering dedicated, or shared Windows servers at very reasonable prices.

Assuming neither of these options is possible, there are a couple things that _might_ help.
a) when you "include" your site inside the "main" site, keep the domain name the same. For example if the IIS and NetTalk server are on the same machine then embed the link as
http://www.mysite.com:88 and not http://64.12.3.23:88

b) run your bit on port 80, using the same domain name, but different sub-domain. For example;
http://dynamic.mysite.com
And then "bind" IIS to one IP address, and the NetTalk web server to another.

Cheers
Bruce

[MarkH]

Thanks Bruce, your response is clear but I still have a couple of questions.

First, I stopped the IIS service on the web server and changed the NetTalk app to run on port 80 but IE still had the cookie problem.  It would only work if I manually told it to allow cookies from the web server’s IP address.  Based on what you indicated, I would’ve expected this to work?  I got our domain name through Go Daddy and they are using their name servers to point to our in-house web server.  There may be some masking or forwarding there that’s screwing things up but it seems fairly straight forward.

Second, old versions of the app compiled using 4.26 or 27(?) and earlier work fine in our current configuration.  I would expect that those early versions would have the problem if it’s strictly a site within a site issue.

Lastly, I couldn’t get the http://www.mysite.com:88 idea to work.  My links on the static pages are on the order of your http://64.12.3.23:88 example.  The second part of that says to try it using a sub-domain.  Is there anything within NetTalk that needs changing to try that (similar to changing the port#) or is it all an external server setting?

Thanks
Mark

[Bruce]

Hi Mark,

Do you still have the 4.26/4.27 version of the site? Because nothing about cookies has changed in a long, long time.
So I suspect the change is in the browser, not the server. It's _possible_ that earlier versions were more forgiving of cookies not being enabled - but you're getting a physical warning so I would expect it to be the same.

Perhaps the server is in a different "zone" in IE now? or IE has changed? the Zone can be seen in the status bar at the bottom.

I don't think the DNS server is material - and given that you are running your program "as the domain" (ie no more one-site-embedded in another) I don't think any of the other suggestions of mine are material.

Have you tried accessing the site from elsewhere? (specifically can you give us a link so we can try from here?)

Cheers
Bruce

[MarkH]

Hi Bruce,

This appears to be one of those “sometimes things aren’t what they seem” problems.  I started to wonder if my problem was strictly a cookie issue when your suggestion to combine the two sites using NetTalk under port 80 failed.  While driving down the road (where I do my best coding!), I had more doubts.  The port 80 solution should’ve worked and others weren’t reporting related problems.  Then I saw your reply stating you hadn’t updated the cookie routines since before I started having problems.  That made me re-examine things.

I first noticed this problem about a month after installing 4.27 when I attempted to install some changes on the web server.  I recall the 4.27 update trashing my template registry.  I fixed the registry and reinstalled the update but have had this problem ever since.

Today, I compiled your example #1 and put that on the web server temporarily.  It worked fine and IE exchanged cookies.  So, it wasn’t a “site in a site” problem and if a cookie problem it was something within my app.  I spent some time copying my app into a new app.  I’m not done but testing shows the initial browses that were failing now working.  So, the likely problem is that I opened my app with the registry trashed and that somehow screwed something up.  I appreciate your response.  It put things on the right track.

If possible a warning or error routine to your updates so that the registry doesn’t get trashed would be nice.  I also seem to recall Mark Goldberg or someone mentioning a routine that threw up a message.  I’ll have to look into it.

Thanks again,

Mark