I understand how you might not want to use Session variables, since Session variables are only available to users who have cookies enabled.
The only resolution I can think of is to have a separate logged_in table with maybe 2 fields, then query that table each time to see if the user is logged in.
The table would consist of 2 fields, username, time_logged_in. You could query this table on every page that needs to be protected. I know that this will incur additional overhead, but this might be one of the more secure ways to incorporate this. Then, when the user logs out, you can just delete that row from the database. Also, in your include file you can compare the current time with the time_logged_in, to automatically force a user logout. The best way of implementing this would definitely be by using a stored procedure to return either a true or a false.
If you are using Access, then you can just pass in the SQL like normal, but you might need to make two or three connection calls to authenticate. If you are really interested in this method, and you are using access, see if you can get the MSDE. It's like an add-on for access, making it akin to a lite version of SQL Server. You can download it at
If security isn't a big issue, then you should just pass around querystring and form variables, then in your include do a Request("formvariable"

. By calling Request this way, it will check both the QueryString and the Form collection, making it so you don't have to worry about where it's coming from. The downside to this is that by storing the data in either of the Request collections, all someone needs to do is hit the back button to compromise your security.
One last option that I just thought of is by creating a disassociated (or custom) recordset at the Application level. Add the fields username and logged in, then filter the recordset (much like in my database example) looking for the username. It would be extremely similar to the database example as above, but it would be stored in an Application variable. The benefit of this is that it reduces the workload on the DB Server, and also one less connection to the DB Server is needed. The downside is that if you are expecing a lot of users, that Application recordset could get real big real quick, consuming more of your web server memory and resources. If you need more information on custom recordsets, check out this link:
there are probably better ways to do this, but this is all that I could think of. I would be very interested to hear what the other members opinions are on the best way to implement this.
good luck