Then in your web.config use an authentication section similar to the following: <authentication mode="Forms"> <forms name="myCookie" timeout="20" loginUrl="Default.aspx" defaultUrl="Default.aspx" protection="All" path="/" requireSSL="false" slidingExpiration="true" cookieless="UseDeviceProfile" domain="domain.com" enableCrossAppRedirects="true" /> </authentication> Internet Explorer will only pass cookies from one site to another if they have the domain cookie attribute set; i.e. the Fully Qualified Domain Name is required. Moreover all GET/POST must use the FQDN, as any Response.Redirect. The reason behing this is security, to make sure that a cookie is not passed to another site, thus exposing to cookies stealing.   Carlo

…take a close look at your code 😊. This comes from a case I worked on in the last couple of days: a customer reported a problem in one of his ASP.NET 2.0 pages, which is meant to perform some sort “long running” operation on the server. What puzzled me a bit (well… quite a bit, at the beginning) is the fact that after the user clicked posted the page (clicking on a submit button) and the long operation begun on the server, after about 90 seconds they noticed a new click button for the submit event was fired, thus restarting the whole “long” operation (and of course leading of all sort of problems this implies for the application’s logic). Doing some tests we found that more that the above, even if he closed the browser on the client immediately after submitting the form, after about 90 seconds they still got a second click event firing for the submit button! 😲 Of course if the browser is closed on the client, it’s hard to believe that the new click and subsequent post is coming from the user… 😏 We looked and the page source produced by the server, here is an interesting excerpt: <input type="button"…

A few weeks ago we had an interesting discussing in my team (triggered by a customer’s request for some hints on charting in ASP.NET) about the use of GDI+: here is what the documentation states on the subject (and what spurred the customer on opening a Service Request with CSS): Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions. (from http://msdn2.microsoft.com/en-us/library/system.drawing.aspx) Just to clarify: they were not experiencying any particular problem and you can go with GDI+ if that workes fine according to your requirements, but the statement above means that CSS can’t help you if you are running into troubles with it… Customer concern and question: Searching the internet, most of the samples for ASP.NET applications providing charting work with GDI+; there are even books on this topic. Why Microsoft is not supporting GDI+ in ASP.NET? If we want to build charts on our own, what design can we use which Microsoft DO support? Well… GDI+ ins’t supported from a service because those components/classes where not designed/tested to run without an interactive desktop in a…

Last week I attended an advanced ASP.NET 2.0 training with deep Ajax dive in our sub in Munich; for my convenience I flew in on Monday morning (I had to wake up at 4 a.m. to go to the airport 🤭), jumped on a S-Bahn train to the station of Lohhof and after that I had almost no idea where to go exactly because that was my first time there, but right out the station there is a nice road sign indicating “Microsoft –>”  😊, and then signed-in right on time for the first day start. It was a Develop Mentor training set up just for us CSS Engineers (well, actually the only 5 attendants are all from my virtual team 😲); the weather in Germany has been quite bad, lots of rain and icy wind (I actually got a cold with a temperature, a cough… all the stuff 🤒), all the hotels in town where full because of some kind of industrialists meeting (not exactly understood what) so I had to accept the only with some rooms available… not a good experience for my first time in Germany, but at least the training was well worth all of those troubles!…

Here’s another interesting one: we had a .aspx page with some controls on it, and one of those controls were a CheckBox; upon a postback, we were trying to set the CheckBox as readonly. What we obtained is that ASP.NET incorrectly raised a CheckChange event even though none clicked on the CheckBox and so that event was not expected to fire; it seems as if the viewstate handler incorrectly detects a change to the checked value. First of all, Internet Explorer does not include the value of disabled controls in a postback to the server; secondly, an unchecked checkbox is not included in the post back either. So the way ASP.NET detects if a CheckBox has been unchecked, is assume that if checkbox is missing in the postback then it is unchecked, otherwise checked. It also turned out that the customer was overriding the RenderChildren method for his purposes, and in that method he disabled some of the controls sent to IE after the controls have any chance to store their new state in view state. Then keeping the browser’s behavior in mind, ASP.NET believes the CheckBox was unchecked, and fired the onCheckedChange event. In summary, upon a post back here, roughly…