Help with implementation ideas

[vasah20]

Hey all
I've got a question for everyone, and I was hoping I could get some opinions on how you would implement this.

I'm looking to implement password/login type functionality to my site, but I want to try and do this without using Sessions.

What I've done so far is create the following table

End_user_loggedin
- EU_pk (User's id)
- tempPass (random 9 digit number)
- timeLogged (DateTime field, default Now())

I know that I could just tack onto every querystring and form the tempPass & EU_pk fields and process it whenever I need to, but I also want to be able to log the user out after 15 minutes of inactivity.

The main problem is that I am using Access for this database, so that severely limits my options.

Any ideas?

thanks in advance.
leo

 

[link9]

Well, my idea would be a sort of "passive" kind of login system, where timeLogged would be refreshed on each activity, and checked on every page -- if it has been less than fifteen minutes since the last activity, then refresh the time again, and do what you need to do --

If it has been more than 15 minutes, then they get redirected to the login page --

So the user is not really actively logged in (because to run a timer that would actively log them out on however many users were on the site would be -- woooooweeeee) -- but since the time of last activity is recorded, you check that each time to decide what to do -- and if you want to see how many users are currently logged in, then run a view-like query on the table where the information is stored...

And actually, you would probably do well to create another table that would keep track of the logging information so that you could insert and delete the entries as people log in and out -- then probably run a clean up routine on the table periodically (possibly a scheduled ASP page that would clean it out every hour or so) to get rid of any extra records that people left by letting their "session" expire rather than actually logging out (which would delete that particular record)

yes?


Paul Prewett

 

[vasah20]

Paul, I was thinking about implementing it in that exact same way, the only drawback is that I didn't want to introduce unnecessary traffic on Access. Then again, if the site gets to the point where Access has too many users, then I will happily upgrade to SQL Server

Because of this, I'm playing with the idea of using the FSO to generate a file each time a user gets logged in, then doing a .FileExists("filename&quot to see if the user is logged in, and to change the file so that the time modified changes as well. Then I would run a scheduled ASP page to compare the .DateLastAccessed and delete the ones that exceed a certain time frame. I know that the FSO is native to Windows, and I know that this will reduce the strain on Access, but is this a feasible solution? I really can't judge the runtime on this, since I don't have a lot of experience with the FSO. Ideas on this?

sidenote:
The table that I listed is actually the table where the users will get added and deleted as needed. That's why the tempPass is a totally random, db generated number. This way, the only way someone could be authenticated is by having the correct values for each pair. In that table, the only thing that my script is inserting is the EU_Pk... everything else is Access generated.

Anyways - thanks for the input
Leo

 

[link9]

Yea, I don't have too much experience with the FSO either -- I use it locally here on our intranet, but with a very light load -- so I don't know how much good information I could give about it.

It sounds like a feasible implementation. The only drawback I see there would be that you could possibly run into conflicts creating the files because of a lack of record locking, that you could implement in a database type situation -- to make sure that two users didn't request information at the same time (the .fileExists()), and then create two text files -- the second overwriting the first.

But... if you are implementing with Access, then you probably aren't too terribly concerned with a large amount of users hitting the site at the same time -- and like you said, if you do run into that problem, then it's time to upgrade.

Speaking of upgrading, have you considered MySQL?? I assume that the decision to go with Access is because of cost, and MySQL is said to scale well (although I haven't used it) -- might be a viable alternative that wouldn't cause the problems that I have found to be pretty much unavoidable in a Web/MS Access environment.

I'll think about this some more and post back if I have any brainstorms. It's an interesting question --


Paul Prewett