No Cookie for you…

Like all new features they were great ideas but then got twisted. Take the web browser cookie. Provide an easy way to store crumbs of information on a client’s web browser, no fuss, no muss. Until the bad people took advantage of this feature and learned how to steal the data for their own needs. Most security folks now recommend clearing your cookies when you close your web browser. For the programmer, it’s frustrating. How do we keep track of a user’s session if we can’t store a token on the client’s PC

In past versions of Profiler we solved this using a cookie-less session. Basically the session ID (unique number) is stored in each form the user processes. That same session ID is stored as a file on the web server for easy tracking.

So why bring this all up In keeping with the development philosophy of do more with less, we have enhanced this functionality. Previously, when any screen was loaded that tied in some way to Active Directory data, one or more LDAP calls had to be made to gather the data that is presented to the user. This drew concern from directory administrators who thought Profiler might over tax their domain controller. We did some testing and found that was not the case, Active Directory is designed for this kind of load and works well under such a load.

However we still wanted to optimize the code to be less of a burden.

Leveraging the local session data turned out to be the solution. Now when a user edits an object, the entire object is read once and stored in the session data on the web server. In a nutshell the object is cached on the web server so the user can edit the object as much as desired without having to make LDAP calls on each web page change. This should drastically improve Profiler’s overall performance, cut down own network traffic and reduce our interaction with the domain controllers.

Doing more with less.