Gents

How do you handle user session timeouts and re-authentication in your apps? My server times out a user session after X amount of time. The session are stored in the database and will be cleared if there are no requests for that time. Every request to the server has to contain the Session ID variable that I generate and return to the app during initial logon process.

I was thinking of having the logon form pop up if my server returned a specific http response. Now lets say a user does not use the app for some time and the session on the server has expired. He then tries to load or commit som data and the server triggers a session timeout error message. In the Load error and the OnCommitError error function I can catch this and trigger the login form again. However, I do not want the user to loose the last data he input or having him to close a form and open it again to load data. I would like to retry those requests that ended up in NumPendingRequest queue. Here is my problem. The request that end up in the request queue has the old Session ID and will forever fail from this point of time and making other requests ending up in the queue. The only way is to clear the request queue by calling the CancelPendingRequests after the user re login. However, the last data the user might have worked on is then gone.

How do you guys handle this?

Thanks

Eivind

Eivind wrote:

<< The request that end up in the request queue has the old Session ID >>

How do you pass session id to the server? If you will keep it in TDatabase.Params and update it on commit error, this should solve your problem, I guess.

I use the params on the dataset for load operations and params for the TDatabase for commit operations to submit the Session ID. However, once a load or commit request fails, those and consequent request all end up in the Pending request queue. It can be a single request or multiple requests in the queue. How can I access all the requests in the Pending request queue to update the Session ID with the new one?

Eivind,

<< How do you handle user session timeouts and re-authentication in your apps? My server times out a user session after X amount of time. The session are stored in the database and will be cleared if there are no requests for that time. Every request to the server has to contain the Session ID variable that I generate and return to the app during initial logon process.  >>

Here's how it works in EWB 3, so you can do something similar:

1) Don't return the session ID to the application.  Instead, set it as an HTTP-only cookie that expires in X minutes or hours.  This is assumed to occur after an explicit authentication request from the client application.

2) Every time that the session ID shows back up in your server-side code as part of a request, be sure to refresh the expiration time.  If a request comes in without the session ID cookie set, or if the session ID is no longer valid, then return a 403 - forbidden response and reset any authentication information.

3) When the front end detects such an error during a dataset request, the TDataset.OnLoadError event (or OnCommitError if committing a transaction) will get triggered.  The tricky part here is that EWB *doesn't* return the status code, rather just the error message.  So, you're going to need to do some searching in the error text for "forbidden", etc., depending upon what's getting sent from the server.  In the OnLoadError event handler, you're going to need to use a TServerRequest to issue an authentication request to your server-side code so that you can re-authenticate the application and get a new session ID.  In the OnComplete event handler for that TServerRequest instance (yes, there's some callback chaining taking place here), you will need to call this method to retry the database operations that failed, due to the session expiration:

https://www.elevatesoft.com/manual?action=viewmethod&id=ewb2&comp=TDatabase&method=RetryPendingRequests

Of course, this is all handled transparently in EWB 3, even down to the authentication and automatic retries on the client side.  But, I know that you're using IIS or something similar, so that won't be as much of an option.  However, you *will* be able to take advantage of the functionality on the client side, provided that you make your server-side code adhere to a similar architecture.  The primary requirement for "fitting into" the new authentication architecture will be to simply define endpoints that look like this:

https://www.elevatesoft.com/<resource>?method=authenticate
https://www.elevatesoft.com/<resource>?method=deauthenticate

where <resource> is, by default, called "authentication", but can be configured to be anything that you wish.

Also, the authenticate method requires that you return some other basic information (user's full name and their effective roles/privileges), but that will be completely documented in the final release and I might just make this optional through a property setting with the new TServerSession client component that handles all of this.

Tim Young
Elevate Software
www.elevatesoft.com

Excellent Tim!

Changing to using cookies solved that problem.

The more you talk about EWB 3.0, the more we hope Christmas comes early this year

Eivind

Eivind,

<< The more you talk about EWB 3.0, the more we hope Christmas comes early this year >>

For you and me both...it's going to save me *huge* amounts of time on support and make my life much easier around Elevate Software, also.  It's just much better to have security "best practices" baked into the web server itself - it allows the developer to concentrate more on the application.

Tim Young
Elevate Software
www.elevatesoft.com