Thread: [Phplib-users] session4_custom.inc
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Dennis G. <ge...@cv...> - 2003-04-08 18:42:18
|
anyone using session4_custom.inc? I see a line in the file session4.inc where it says to make sure to call the constructor from extending classes, but session4_custom DOES NOT call it with its constructor. Also, I'd like hear experiences people have had with this. |
|
From: Marko K. <M.K...@os...> - 2003-04-09 07:43:51
|
Hi Dennis, > anyone using session4_custom.inc? yep. > I see a line in the file session4.inc where it says to make sure to call the > constructor from extending classes, but session4_custom DOES NOT call it with > its constructor. as far as I know the latter doesn't rely on session4! It's self-standing, so to say. I use custom since 2 years successfully! Marko |
|
From: Maxim D. <max...@bo...> - 2003-04-09 07:56:13
|
Hello Marko, Wednesday, April 09, 2003, 11:43:21 AM, you wrote: MK> as far as I know the latter doesn't rely on session4! It's self-standing, MK> so to say. MK> I use custom since 2 years successfully! session4[_custom] was refactored about 2 years ago :) custom depends on session4 since then. -- Best regards, Maxim Derkachev |
|
From: Marko K. <M.K...@os...> - 2003-04-09 08:48:40
|
> session4[_custom] was refactored about 2 years ago :) custom depends ohhh, sorry maxim, thanks for the hint, I forget myself sometimes. I should better check what I post here... :( Of course, what I remembered was the status before you changed over to extending the session4 class. Now, of course, session_custom is a child class of session4... SORRY for my misleading comment! Marko |
|
From: Dennis G. <ge...@cv...> - 2003-04-09 15:30:38
|
Thank you, Marko. session4_custom extends the class Session which is in session4.inc, as far as I know. What do you actually use sessions for? This is is the first time I have had sessions going. Marko Kaening wrote: > Hi Dennis, > > >>anyone using session4_custom.inc? > > yep. > > >>I see a line in the file session4.inc where it says to make sure to call the >>constructor from extending classes, but session4_custom DOES NOT call it with >>its constructor. > > as far as I know the latter doesn't rely on session4! It's self-standing, > so to say. > > I use custom since 2 years successfully! > > Marko > |
|
From: Marko K. <M.K...@os...> - 2003-04-09 15:44:59
|
Hi Dennis, > Wat do you actually use sessions for? This is is the first time I have > had sessions going. actually I am not using the session_custom anymore as I noticed right now. That is because I use the user class also ported to php4 by Maxim. Since my sessions don't really need to be in a DB session4 is okay for me. They are as a matter of fact as well faster. BUT, the user class provides me with DB saved user variables! That's a great thing for storing information in user-dependent manner. Marko |
|
From: Dennis G. <ge...@cv...> - 2003-04-09 15:48:50
|
I'm on a shared server, so I want my sessions to be in a database, away from others using the filesystem. Besides identifying a logged in user, what do you use sessions for? Marko Kaening wrote: > Hi Dennis, > > >>Wat do you actually use sessions for? This is is the first time I have >>had sessions going. > > actually I am not using the session_custom anymore as I noticed right now. > That is because I use the user class also ported to php4 by Maxim. Since > my sessions don't really need to be in a DB session4 is okay for me. They > are as a matter of fact as well faster. BUT, the user class provides me > with DB saved user variables! That's a great thing for storing information > in user-dependent manner. > > Marko > |
|
From: Marko K. <M.K...@os...> - 2003-04-10 08:45:46
|
> Besides identifying a logged in user, what do you use sessions for? storing user-dependent information, like settings for appearance of menues, layouts etc. |
|
From: Dennis G. <ge...@cv...> - 2003-04-10 16:28:06
|
Doesn't that go in user variables? Marko Kaening wrote: >>Besides identifying a logged in user, what do you use sessions for? > > storing user-dependent information, like settings for appearance of > menues, layouts etc. > |
|
From: Marko K. <M.K...@os...> - 2003-04-11 11:09:30
|
> Doesn't that go in user variables? yes! Everything what is specific for users and not for a session gets stored in there! > > Marko Kaening wrote: > >>Besides identifying a logged in user, what do you use sessions for? > > > > storing user-dependent information, like settings for appearance of > > menues, layouts etc. |
|
From: Dennis G. <ge...@cv...> - 2003-04-11 15:15:19
|
that kind of goes back to my question. Because EVERY browser window gets all the same cookies, besides identity of a user, what gets stored in the cookie for a session? And how do people prevent a new browser window by the same user, in the same session, from having the exact same screen as the other ones that are open, (going to the same application at the same website, of course:-) )? Marko Kaening wrote: >>Doesn't that go in user variables? > > yes! > Everything what is specific for users and not for a session gets stored in > there! > > >>Marko Kaening wrote: >> >>>>Besides identifying a logged in user, what do you use sessions for? >>> >>>storing user-dependent information, like settings for appearance of >>>menues, layouts etc. > > |
|
From: Layne W. <la...@dr...> - 2003-04-11 15:48:09
|
Dennis Gearon wrote: > And how do people prevent a new browser window by the same user, in > the same session, from having the exact same screen as the other ones > that are open, (going to the same application at the same website, of > course:-) )? You can't prevent that. You must make sure that any information stored in session will not cause unexpected results if the user is using the same page for different tasks. For instance, in one of my first session-based sites, I stored the record currently being edited in session data - when a user tried to edit two records side by side he could easily overwrite one record with another record's data. Note: If your user is using Win IE AND she launches a new instance of IE instead of opening a new window in her current instance, she can have multiple sessions as the same logged in user. Don't count on this behaviour. Layne Weathers |
|
From: Lindsay H. <fmo...@fm...> - 2003-04-11 16:10:55
|
Thus spake Layne Weathers on Fri, Apr 11, 2003 at 10:48:09AM CDT > Dennis Gearon wrote: > >And how do people prevent a new browser window by the same user, in > >the same session, from having the exact same screen as the other ones > >that are open, (going to the same application at the same website, of > >course:-) )? > > You can't prevent that. Yes you can. Once the session has been established, the server identifies the browser instance with every page request and can, for instance, decide to serve a different page each time the same browser submits the same URL. This assumes that URL requests a dynamic page, which is why we're trying to identify sessions in the first place. > You must make sure that any information stored in session will not cause > unexpected results if the user is using the same page for different tasks. > For instance, in one of my first session-based sites, I stored the record > currently being edited in session data - when a user tried to edit two > records side by side he could easily overwrite one record with another > record's data. I use <input type=hidden ...> to identify records, and each record display has it's own "edit" button in the generated page, so there's no confusion on the server side about what's intended. -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | <http://www.fmp.com/pubkeys> http://www.fmp.com | | |
|
From: Lindsay H. <fmo...@fm...> - 2003-04-11 15:53:37
|
Thus spake Dennis Gearon on Fri, Apr 11, 2003 at 10:17:34AM CDT > that kind of goes back to my question. Because EVERY browser window gets > all the same cookies, besides identity of a user, what gets stored in the > cookie for a session? A session cookie is generally just a key into a server-side database, and the database stores whatever is appropriate on the server side. A session cookie is set to expire when the current browser instance terminates.. > And how do people prevent a new browser window by the same user, in the > same session, from having the exact same screen as the other ones that are > open, (going to the same application at the same website, of course:-) )? Once we have a session established, anything is possible. The server will know which pages have been fetched during the current session and can make decisions accordingly. The test program which is, or used to be sent out with phplib is a good example. It counts accesses for a page in the context of a session. Successive windows using the same browser instance will display the access counter incremented, but of course the server could do anything here, including limiting access to any particular page to once per session. A session cookie doesn't really identify a user. It identifies a browser instance on the client side, and as long as the browser stays up, the server will know that it's dealing with the same browser instance every time the cookie is returned to the server (e.g. on every page fetch). If the user authenticated, then the server knows that the browser instance identified by the cookie is being run by an authenticated user and can behave accordingly. If the user closes the browser, the session cookie goes away and the next time the browser program is started no cookie is returned, and the server sends a new cookie and instantiates a new session. Hope this helps. -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | <http://www.fmp.com/pubkeys> http://www.fmp.com | | |
|
From: Lindsay H. <fmo...@fm...> - 2003-04-10 18:59:19
|
Thus spake Dennis Gearon on Wed, Apr 09, 2003 at 10:51:04AM CDT > I'm on a shared server, so I want my sessions to be in a database, away > from others using the filesystem. > > Besides identifying a logged in user, what do you use sessions for? Sessions are used anytime one needs to maintain state between pages. The information assoicated with the state can be the identity of a logged in user, or it can be any information previously sent back to from the client via a form or other feedback method, or a record of pages previously viewed, etc. Sessions make up for the fact the fact that the HTTP protocol itself defines a session only in terms of service of a single page, whereas it's often more useful to consider a session as spanning all the page retrievals by a site visitor in the course of a visit. -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | <http://www.fmp.com/pubkeys> http://www.fmp.com | | |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X