Authentication on WebSite

[YuraZ]

There is a server-based TRtcHttpServer. The client is implemented as a Web site.
Using TRtcDataProvider server accepts requests from the site and returns the result. Everything works fine, but every time when the website is updated a page in the event OnCheckRequest/OnDataReceived TRtcConnection changing to a new one, it's mean that a previous client disconnected.
In my desktop application, which also connects to the Web server authentication, and subsequent interaction with the user is to analyze TRtcConnection. How to implement this behavior for a website?
Thanks in advance!

[D.Tkalcec (RTC)]

I'm sorry, but I don't understand what you are asking.

Please re-phrase the question and be more specific.

Best Regards,
Danijel Tkalcec

[YuraZ]

Ok.
I need to authenticate user (from web-site) in my web-server (TRtcHttpServer). How i can understand that authenticated user is the same user after web-page refresh? When I try to remember TRtcConnection in OnCheckRequest (TRtcDataProvider) is changing after page refresh.

[D.Tkalcec (RTC)]

You need to use Sessions. Here are FAQ topics about Sessions:
Web example using Sessions, Cookies and Form Post data (user input)
Sessions and User Management
Using Sessions in Remote Functions
What is a Session in RTC?
Is Session Management done automatically by the RTC?

Best Regards,
Danijel Tkalcec

[YuraZ]

Thanks, Danijel!
Is what i need!!!

[YuraZ]

Danijel, one more question: i dont understand when and in what cases Session will be unkept? When KeepAlive is increased? Does it mean, if user dont request to web-server time more than Session.KeepAlive, then session is terminated?

[D.Tkalcec (RTC)]

Correct. You use the KeepAlive parameter to define how long a session should stay alive without the user contacting the Server. If the user does not send a request to the Server and you do not use the "FindSession" method to lock the user Session, the Session will eventually expire and be deleted from the Server. If you want to allow users to stay away from the Server for a long time, then you should use a large KeepAlive value.

When using the TRtcDataProvider component, or when using the TRtcServerModule component with AutoSessions=False, the Session Timeout period is refreshed every time you use the "FindSession" method on the Server. When using the TRtcServerModule component with AutoSessions=True, the user Session Timeout will also be refreshed (counter set back to zero) every time a remote function is sent to the Server.

Best Regards,
Danijel Tkalcec

[YuraZ]

Thanks, Danijel!
I'd tested this behavior. I set KeepAlive = 10 (10 seconds), but FindSession is returning true even if i wait 20 seconds after last request. Can you describe me this behavior?

[D.Tkalcec (RTC)]

The purpose of the Session Keep Alive value is to ensure that a Session will NOT be deleted if it is NOT being accessed for some time. The Keep Alive value is the MINIMUM time you need the Session to stay alive. It is NOT the maximum value. The maximum time a Session could stay alive without being closed manually, depends on the number of currently active Sessions and the number of users working with Sessions. The more users are working with Sessions, the more likely it is for a timed-out Session to be closed automatically.

If you want to test how Keep Alive value affects Sessions, you have to work with at least 2 Users at the same time.

Also, if you want to log the user out manually, I recommend using Session data to define if the Session is still actively used. This should be done independently of the fact if the Session has expired or not. For example, you could set the "login" Session value to TRUE after you create a new user session and log the user in ...

Session.asBoolean['login']:=TRUE;

... and when you want to log the user out (manually), you can set the "login" Session value to FALSE before calling "Session.Close" ...

Session.asBoolean['login']:=FALSE;
Session.Close;

The "login" name is just an example. You can use any name you want for Sesion variables and use any number of variables you need. You could also have multiple access levels stored inside Session variables. Session variables are your Server-side storage for the Client associated with a specific Session ID.

Best Regards,
Danijel Tkalcec

[YuraZ]

Thanks, Danijel.
But I still dont understand what is KeepAlive for? I need somehow to know is client connected or not. And i thought that KeepAlive is solve my problem.

[D.Tkalcec (RTC)]

You need to know that a single user could close a connection and open a new connection hundreds of times while working with the Server, without having to manually log in and out every time. On the other hand, hundreds of different users could be sending requests to your Server trough a single physical connection when they are going through the same HTTP/S Proxy. This is why you should forget about "physical connections" for user identification when working with HTTP/S and use Sessions. When working with Sessions, a user is uniquely indentified by the Session ID which he has received from the Server.

To make sure that Sessions will NOT expire on the Server when the user is idle, you will use Keep Alive values for Sessions. Keep Alive values are there to ensure that a user Session will be KEPT ALIVE on the Server, even if the user does NOT contact the Server for up to "Keep Alive" seconds. This does NOT mean that a Session will automatically be closed if a user does not contact the Server during that period. It only means that a Session will stay alive AT LEAST that long, even if the Server is NOT contacted. There is no other purpose for the Keep Alive value.

Session management is handled automatically, but this management requires CPU time. To minimize CPU requirements of Session management, Timed-out Sessions will ONLY expire if there have been at least 2 Sessions created on the Server, and the user of the non-expiring Session has just finished working with its Session. Then, all the other Sessions will be checked for their expiration time and expired Sessions will be closed. But if only one user was working with Sessions on your Server and that user has opened only one Session, then that Session is very unlikely to expire automatically, because that single Session will be refreshed every time it is being accessed by that single user and there are no other users to check Session expiration in-between.

This is why you can NOT test Session expiration with a single user. You need at least 2 users working with the Server. Then, the Session of the less active user will expire (after the "Keep Alive" time-out) when the more active user contacts the Server and unlocks its Session. But you should not have to worry about this detail, unless you plan to write a Server which would be there to serve only 1 user (client).

Best Regards,
Danijel Tkalcec