Setting Up a Login and Timed Session
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Setting Up a Login and Timed Session
I am beginning to learn Revolution to develop Internet-aware thick client solutions. I would like to know what suggestions best/practices you have for setting up a timed user session. That is, after a user logs into an Revolution-based app, her username/password is checked against a database, and she has permission, she is allowed to use the app for a 30 minute session. In my experimentation with Transcript/Revolution, I have created a substack that sends a message back to the main stack after a given amount of time (send "notificationSessionEnded" to stack "TheMasterStack" in 1800 seconds). Is this the best way to proceed, or are there better alternatives?
-
- VIP Livecode Opensource Backer
- Posts: 1236
- Joined: Sat Apr 08, 2006 1:10 pm
- Location: Zurich
- Contact:
The Problem with "send in time" is, that it's not very precise. For example if someone grabs the window (with the titlebar) and holds it, no messages get sent. so technically one could continue to look at the current card. Of course, as soon as one lets go, the message gets sent.
You could get a more precise timeout if you'd poll the seconds, parse it and calculate an ending time. But i guess you don't need that precise control over time, and if someone meddles with the system time, you're out of control with this approach.
You could get a more precise timeout if you'd poll the seconds, parse it and calculate an ending time. But i guess you don't need that precise control over time, and if someone meddles with the system time, you're out of control with this approach.
Various teststacks and stuff:
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
Setting Up a Login and Timed Session
I think using send in time should work well.
One thing to remember is to cancel the message if the user logs off before then (unless he or she is quitting the app). You can save the result, which is the ID of the message and issue a cancel if it is still pending.
One thing to remember is to cancel the message if the user logs off before then (unless he or she is quitting the app). You can save the result, which is the ID of the message and issue a cancel if it is still pending.
Peter Evensen
[url]http://www.PetersRoadtoHealth.com[/url]
[url]http://www.PetersRoadtoHealth.com[/url]