Forum > Networking and Web Programming
N-tier multiuser application development
bobo:
For web applications I have used both cookie sessions and URL sessions (and posted the basic examples of them in the fpweb fptemplate examples above) in different projects depending on the need.
I store the user login/pwd data in a table and assign a unique session id to the web clients after login. That session id is used throughout their communication with the web application until they log out or their session expires.
The session id is either in a cookie (cookie sessions) or embedded in every link (encrypted usually) on the response pages, so any following server calls will pass them to the server side CGI/FCGI/Apache_module back-end app therefore identifying the user that has logged in earlier.
If not web pages are used, and the communication is stateless, then you still need some kind of session id to identify the people and only give the clients data they can access.
For native client/server apps, you do not need sessions because the client application just directly can access the back-end server database (VPN or secure tunnel over tcp/ip, etc.), or calls functions there to get data back (the client is not stateless). Usually in these cases the client does the authentication at least at start.
AB
jl:
Thanks for explaining. Does session work the same for ExtJS? Note: I still haven't got the chance to work on the demos as I'm still stuck at compiling Laz with FPC 2.5.1. ;D
Chanced upon this article on session with ExtJS - http://ffzhuang.blogspot.com/2007/12/ajax-based-extjs-authentication.html
It mentions "The HTTP stack in the browser maintains the sessionid for each successive invocation to the web server that it's talking to and ONLY for that web server. As long as the browser is running, the sessionid is maintained. Once the browser goes away, the sessionid goes away with it. There are known session hijacking hacks out there, but they can be averted by providing a bit more information within the variables attached to the sessionid on the server."
This seems quite different from cookies or sessionid embedded in link.
--- Quote from: bobo on October 19, 2010, 08:14:28 am ---For web applications I have used both cookie sessions and URL sessions (and posted the basic examples of them in the fpweb fptemplate examples above) in different projects depending on the need.
I store the user login/pwd data in a table and assign a unique session id to the web clients after login. That session id is used throughout their communication with the web application until they log out or their session expires.
The session id is either in a cookie (cookie sessions) or embedded in every link (encrypted usually) on the response pages, so any following server calls will pass them to the server side CGI/FCGI/Apache_module back-end app therefore identifying the user that has logged in earlier.
--- End quote ---
bobo:
Well, I did not read the link you put there, but from the quote you provided, it is the same session cookie that fpweb has built in. Those also go away after the browser is closed, therefore closing the session on the client side due to destroying the cookie there, so no request will come to the server from then on from any client for that session id.
As for "URL sessions", those are totally handled from server side, so either a log-out action or time-out is the way to exit/destroy a session.
What I do with ExtJS is to have an additional "KeepAlive" action available on the server side that refreshes the session time-out clock on the server in case the user spends a lot of time client side actively without communicating to the server.
Every now and then, from the ExtJS client this action is called on the server, therefore refreshing the session there (ex: every time the user clicks on a grid cell but 5 minutes hasn't been passed since the last keepalive call, etc.).
AB
Navigation
[0] Message Index
[*] Previous page