tags:

views:

251

answers:

1

I have a classic ASP site I'm maintaining and recently we wanted to do special rendering actions if the visitor was coming from one specific set of websites. So in the page where those visitors have to come through to get to our site, I put a simple line setting a session variable:

<!-- #include virtual="/clsdbAccess.cs"-->
<%
    set db = new dbAccess
%>
<html>
    <head>
      ...
          <script language="javascript" type="text/javascript">
           ...            
           </script>
    </head>

    <body>
    <%
    Session("CAME_FROM_NEWSPAPER") = "your local newspaper"  
    ...
    %>
      ... html stuff ...
    </body>
 </html>

Then, in all the following pages, whenever I need to put up nav links, menus, etc., that we don't want to show to those visitors, I test for if that session variable is "" or not, then render accordingly.

My problem is that it seems to work great for me in development, then I get it out into Production and it works great sometimes, and other times it doesn't work at all. Sometimes the session variable gets set, sometimes it doesn't. Everything else works great. But our client is seeing inconsistent results on pages rendered to their visitors and this is a problem. I've tried logging on from different PC's and I confirm that I get different, and unpredictable, results. The problem is I can't reproduce it at will, and I can't troubleshoot/trace Production.

For now I've solved this by just creating duplicate pages with the special rendering, and making sure those visitors go there. But this is a hack and will eventually be difficult to maintain.

Is there something special or inconsistent about session variables in Classic ASP? Is there a better way to approach the problem? TIA.

Update I have discovered that the first time you visit the site through that page, the session variable does NOT get set. The menus and everything (that are supposed to not appear in those cases) show up the first time through. Then, if you go back and refresh the login page, go through it again to the very same page, this time it works, and thereafter. Then I went and deleted out all my caching, cookies, etc. and hit the login page again, got to my page: Bam, menus (i.e. no session variable) again. I created a page, "sessionvars.asp" where I display the contents of that var and sure enough, it's blank. At least now that I can reproduce the problem at will, I should be able to duplicate it on Dev and track it down.

+1  A: 

I see a couple scenarios where this could happen:

The first basically echoes @RobV's comment, but the gist is ASP sessions rely on on cookies stored on the browser client. So if the user comes from a client that has cookies turned off you won't be able to retrieve any session variables for that client.

Another scenario is that some user sessions might be timing out. For example, lets say the user goes to the page that sets the session variable (and your session timeout is, say, 10 minutes). Then they go out and get a coffee or get caught up in a conversation. Then the user clicks on a link from your page 30 minutes later, and by that time the session is abandoned. You could try upping the session timeout and seeing if that improves the situation.

One workaround would be -- instead of the session approach -- to check the the client's referring url (HTTP_REFERRER), and see if it is one the url's you consider to be the "local newspaper". This is arguably more work (and some browsers hide the referrer anyway), but might yield better results. Heck, you could try a combination of both approaches: session and referrer.

NobodyMan
The cookies thing is a real issue, as many people turn off cookies, don't they? If so, then I either can't control this issue or I've got to come up with another way to persist the flag, perhaps through a hidden field (there's no Viewstate in classic, right?). The REFERRER idea might be worth looking into, too.
Mike at KBS
@Mike: There is a big difference between persistent cookies and volatile cookies (aka session cookies). Many people do block persistent cookies but only the most paranoid block session cookies. If this was a cookie blocking issue it would never work it wouldn't sometimes work.
AnthonyWJones