Re: Apache::Session
On Sunday 24 February 2002 02:43 am, Christoph Lange wrote:
The session hash is serialized/deserialized in its entirety using the
Storable module.
Does this mean, that - after tying the session hash - it is of no
importance (concerning the amount of time needed) whether I do
%everything_from_session_hash = %session_hash; # or
$everything_from_session_hash{element1} = $session_hash{element1};
I actually thought that the second way saves time since only one value of
the hash (however big this may be) is extracted from the database.
There is no difference. Behind the scenes, the entire hash is serialized into
a single scalar and stored in a single database field. In order to retrieve
any part of the session, the scalar must be read from the database and
de-serialized. The serialize/de-serialize steps are performed when you
tie/un-tie the hash.
I found it helpful to take apart the various Apache::Session modules and see
what makes them tick.
--
Milo Hyson
CyberLife Labs, LLC
Apache::Session
Hi,
I guess that thisis going to be another
"what-a-bloody-beginner"-question
but I hope somebody will be in a good mood and help
me out.
I am using Apache::Session with Postgresql.
Unfortunately I had never worked with a huge
amount of data
before I started to program something like
a(little) webapplication. I happily
packed everything in the"session"(s-table)
that might be of any use. It hit me hard that it takes a veeey long time to get all the stuff
out of the
"session"(s-table) each time the client sends
another request. So I became a little more
particular about what to store.
My question referrs to how the extraction
ofdata from the "session"(s-table)works. Ok, I have tied a %session
and now need
to get
$session{this}-{is}-{an}-{example}. Will the session module always
fetch the entire $session{this} or is there a way to get
exactly the reference I want?
Thanks in advance, Chris
Re: Apache::Session
On Saturday 23 February 2002 03:03 pm, Christoph Lange wrote:
Hi,
I guess that this is going to be another what-a-bloody-beginner-question
but I hope somebody will be in a good mood and help me out.
I am using Apache::Session with Postgresql. Unfortunately I had never
worked with a huge amount of data before I started to program something
like a (little) web application. I happily packed everything in the
session(s-table) that might be of any use. It hit me hard that it takes a
veeey long time to get all the stuff out of the session(s-table) each
time the client sends another request. So I became a little more particular
about what to store. My question referrs to how the extraction of data from
the session(s-table) works. Ok, I have tied a %session and now need to
get $session{this}-{is}-{an}-{example}. Will the session module always
fetch the entire $session{this} or is there a way to get exactly the
reference I want?
The session hash is serialized/deserialized in its entirety using the
Storable module. If you have a large structure it's going to get the whole
thing each time. Personally, I try to never store anything other than object
IDs in the session. Not only does this reduce the session size but it helps
to prevent synchronization problems.
--
Milo Hyson
CyberLife Labs, LLC
Re: [OT-ish] Session refresh philosophy
You've addressed the issue of someone submitting a form with altered fields to attack the server, and pointed out some more advantages, but I don't think you've addressed the issue of protecting the hidden cleartext data from others on the client side. True. But to tackle these concerns, SSL looks like a better approach to me. If the client doesn't do any math/crypto/secret stuff at all, an attacker that is on the same subnet can both spy on secrets (egress passwords or private data, ingress session IDs or cookies) and take over sessions (just by changing IPs - no need to even hijack TCP connections since they are short-lived in HTTP) - and then there is nothing that the victim could do that the attacker cannot. The point is, secrets pass over the wire in the clear at a moment or another, so encrypting them for all transfers but the first one only earns a marginal amount of security. This is not to say I don't enjoy using the various state storage mechanisms described in the thread. They are highly useful but I think that the encryption part of them only addresses problems on the server side and are useless under certain forms of site design. -- Dominique QUATRAVAUX Ingénieur développeur sénior 01 44 42 00 35 IDEALX
Re: [OT-ish] Session refresh philosophy
David Harris [EMAIL PROTECTED] on Feb 19, 2002: The encoded information is [...] split into reasonable length hidden fields. Why not put everything in one field? Are there restrictions? Does it make a difference when using POST? Hans
RE: [OT-ish] Session refresh philosophy
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. Sounds a lot like CGI::SecureState. Have you ever looked at it? I just installed and played with CGI::SecureState (using the example in the POD) and it is totally different than my module. When I used CGI::SecureState it gave the client a non-versioning (more on that later) key and stored the state information in the filesystem. My module doesn't need to store any information in a database or in the filesystem. The entire state is given to the client in hidden form fields, and is passed back to the server on the next request. In addition, CGI::SecureState does not tie the state information to the *page*. With my module (or any method that stores the *data* in a hidden form field, not just a non-versioning key), state information is tied to the page. Let me explain: Imagine a multi-step order process where the user works through pages A, B, C, and D, (which contain forms) then uses the back button to go back to page B, changes the form values, and submits the form. With CGI::SecureState, page C will receive the state information stored by page D (that was intended for use by page E, we presume), instead of the state originally stored by page B (that was intended for page C). This is because all the pages share the same key, and old versions of the state are overwritten by the new versions and no longer available. When the back button is hit, a newer version of state may be used where an older version was intended. With my module, page C always gets the state information stored for it by page B, since the state is stored in hidden form fields in page B. The browser is actually storing the state and will always submit that same state to page C. (I have mentioned that CGI::SecureState uses a non-versioning key a few times. A way to make CGI::SecureState tie the state information to the actual page would be to change the key whenever the state changed, thus creating a versioning key. The key could be a hash of the state itself. This potentially means that a huge number of versions of the state would have to be stored on disk. I think this method would only be helpful if the state is large and it's not acceptable to pass it back and forth between the client.) In addition, CGI::SecureState gets fuddled if the user opens a new window (something I do often) and then starts performing different operations in each window using the same state key! It has no way of knowing a new windows exists and generating a new key. If you just store a customer id, customer name, and other rarely changing information in the state, these concerns may not matter to you. If you break a long form or order process into multiple pages, gathering new information on each page and storing it in the state so that you can process the order at the end, then this is a likely problem. David
Re: [OT-ish] Session refresh philosophy
Hans Juergen von Lengerke writes: Why not put everything in one field? Are there restrictions? Does it make a difference when using POST? That's what we do. There doesn't appear to be a restriction with POST. For while, we were encoding entire forms in URLs, but the limits got to us for really large forms. Rob
RE: [OT-ish] Session refresh philosophy
Hans Juergen von Lengerke [mailto:[EMAIL PROTECTED]] wrote: David Harris [EMAIL PROTECTED] on Feb 19, 2002: The encoded information is [...] split into reasonable length hidden fields. Why not put everything in one field? Are there restrictions? Does it make a difference when using POST? The POST encoding dose not have a limit on data length. Heck, people use textarea tags with huge amounts of content all the time. However, I didn't feel comfortable assuming that the HTML parser used by the browser could easily parse a potentially 20kb attribute. Basically, I didn't want to make my production application a stress-test for my user's browsers. :-) It was easy to break the data up into multiple hidden fields, because Base64 encoding breaks the data into multiple lines by default. I simply encoded each line in one hidden field. I would *NOT* use my module with a GET form if you expect any size of data. I've seen the query string get truncated at some arbitrary size limit. David
Re: [OT-ish] Session refresh philosophy
When I used CGI::SecureState it gave the client a non-versioning (more on that later) key and stored the state information in the filesystem. Okay, I only looked at it briefly and thought it stored the data on the client. Your module is actually more like CGI::EncryptForm I think, but yours may make things a bit more transparent. Maybe you should polish it up for CPAN. I'm well aware of the page-state vs. browser-state problem. I was recently bitten by it again when some consultants built a web app for my company that puts the search results in a session keyed on a cookie. As soon as the user opens two windows, it's absolute mayhem. - Perrin
RE: [OT-ish] Session refresh philosophy
I can see how your approach adds functionality by performing as expected if the user uses the Back button or opens the app. in more than one browser window. The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? Wes Sheldahl David Harris [EMAIL PROTECTED] on 02/20/2002 09:50:11 AM To: Perrin Harkins [EMAIL PROTECTED], Drew Taylor [EMAIL PROTECTED], mod_perl Mailing List [EMAIL PROTECTED] cc: Subject: RE: [OT-ish] Session refresh philosophy Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. Sounds a lot like CGI::SecureState. Have you ever looked at it? My module doesn't need to store any information in a database or in the filesystem. The entire state is given to the client in hidden form fields, and is passed back to the server on the next request. In addition, CGI::SecureState does not tie the state information to the *page*. With my module (or any method that stores the *data* in a hidden form field, not just a non-versioning key), state information is tied to the page. Let me explain:
Re: [OT-ish] Session refresh philosophy
The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. Both page types may have form input validation code on the server side, but in the first case this is just convenience for the user (warn early and don't say woops after 9 pages and 10 minutes of typing). The latter MUST have validation for security to hold (even if this means validating twice). This way, changing hidden fields gains an attacker nothing, since he will be blocked at the final submit anyway. Doing things this way also has other advantages e.g. interfacing: one can write automatisms with wget or LWP::UserAgent to trigger actions in the database without any further programming needed on the server side. -- Dominique QUATRAVAUX Ingénieur développeur sénior 01 44 42 00 35 IDEALX
Re: [OT-ish] Session refresh philosophy
You've addressed the issue of someone submitting a form with altered fields to attack the server, and pointed out some more advantages, but I don't think you've addressed the issue of protecting the hidden cleartext data from others on the client side. I guess that's a matter of how paranoid you think you need to be, and how confidential is the data you're storing. Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more than once. Looks like it might worth be taking another look at this approach next time I start a new project. Wes [EMAIL PROTECTED] on 02/20/2002 11:48:28 AM Please respond to [EMAIL PROTECTED] To: mod_perl Mailing List [EMAIL PROTECTED] cc: Subject: Re: [OT-ish] Session refresh philosophy The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. Both page types may have form input validation code on the server side, but in the first case this is just convenience for the user (warn early and don't say woops after 9 pages and 10 minutes of typing). The latter MUST have validation for security to hold (even if this means validating twice). This way, changing hidden fields gains an attacker nothing, since he will be blocked at the final submit anyway. Doing things this way also has other advantages e.g. interfacing: one can write automatisms with wget or LWP::UserAgent to trigger actions in the database without any further programming needed on the server side. -- Dominique QUATRAVAUX Ingénieur développeur sénior 01 44 42 00 35 IDEALX
Re: [OT-ish] Session refresh philosophy
I just looked at CGI::EncryptForm and David's module. The thing I like right off the bat about C:EF is that you pass a href to encrypt() and get back a href from decypt(). Perhaps I missed something, but FormContainer takes a string, not a data structure. I prefer the simplicity of just worrying about a structure, and not having to worry about converting it to a string. That said, I like the approach that the two modules use. One just goes an extra step to guarantee data security. While looking for full-time employment, I've been doing some freelance work, which basically is small CGI apps. C:EF looks like it would make my life much easier by ensuring consistent state w/ small effort on my part, and take care of any security precautions as well. Combine that w/ CGI::Application (after I add TT2 support :-) ), and my life as a freelance CGI guy just got a whole lot easier. Thank you to everyone who contributed to this thread. I've gotten all kinds of neat ideas I'll use in future projects! Drew At 10:19 AM 2/20/2002 -0500, Perrin Harkins wrote: When I used CGI::SecureState it gave the client a non-versioning (more on that later) key and stored the state information in the filesystem. Okay, I only looked at it briefly and thought it stored the data on the client. Your module is actually more like CGI::EncryptForm I think, but yours may make things a bit more transparent. Maybe you should polish it up for CPAN. I'm well aware of the page-state vs. browser-state problem. I was recently bitten by it again when some consultants built a web app for my company that puts the search results in a session keyed on a cookie. As soon as the user opens two windows, it's absolute mayhem. - Perrin Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [OT-ish] Session refresh philosophy
[EMAIL PROTECTED] writes: Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more than once. It is always good to validate the data even if it was encrypted. It is also generally a good idea not to give the user any secrets, even if they are encrypted. In other words, avoid trusting the user. [EMAIL PROTECTED] writes: No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. It is MVC. However, instead of thinking of pages, I like to think in terms of tasks. The same task that renders the form also validates and executes it. In the case of execution, the result is a redirect described by the site's state machine. A form in our world has four states: execute_empty (fill in defaults), execute_ok, execute_other (e.g., cancel or sub form), and execute_unwind (coming back from a sub form). All of these paths go through the same task. Rob
Re: [OT-ish] Session refresh philosophy
Rob Nagler wrote: [EMAIL PROTECTED] writes: Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more than once. It is always good to validate the data even if it was encrypted. It is also generally a good idea not to give the user any secrets, even if they are encrypted. In other words, avoid trusting the user. [EMAIL PROTECTED] writes: No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. It is MVC. However, instead of thinking of pages, I like to think in terms of tasks. The same task that renders the form also validates and executes it. In the case of execution, the result is a redirect described by the site's state machine. A form in our world has four states: execute_empty (fill in defaults), execute_ok, execute_other (e.g., cancel or sub form), and execute_unwind (coming back from a sub form). All of these paths go through the same task. please take this as interested and not critical. i was viewing the source: http://petshop.bivio.biz/src?s=View.items and i noticed these lines: - snip ])-put( cellpadding = 2, cellspacing = 2, ), - snip - this looks like the presentation layer peeking through. the petshop site is obviously a demo, and therefore does not have the polished look of a professional site, which is very understandable. what i wonder is, could a professional web design team make a polished website without involving the programmers? what happens when a cell padding of 3 is more desirable for the design? it seems to me, that in all of the technologies i have looked at thus far, that attempt to separate the presentation layer from the model/view, the precision and flexibility needed to graphically communicate to the user is more difficult that the standard pagedesign approaches (dreamweaver and a little embperl or other embedded language thrown into the mix) . phrased another way, how does bivio or other mvc technology, let web artists design sites as beautiful as http://www.marthastewart.com or the even more beautiful http://www.genwax.com (cheap plug)? -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
RE: [OT-ish] Session refresh philosophy
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: Okay, I only looked at it briefly and thought it stored the data on the client. Your module is actually more like CGI::EncryptForm I think, but yours may make things a bit more transparent. Maybe you should polish it up for CPAN. I looked at CGI::EncryptForm. It is used to store data on the client. The main difference between it and my module is that: (a) it encrypts the data, while I only prevent users from modifying the data, and (b) it stores the data in one field, while I store in multiple fields to make double sure that I don't hit any length restrictions. I'm well aware of the page-state vs. browser-state problem. I was recently bitten by it again when some consultants built a web app for my company that puts the search results in a session keyed on a cookie. As soon as the user opens two windows, it's absolute mayhem. I wasn't exactly what to call it and if people would recognize it by name, so I started writing a short description which just grew. :-) David
RE: [OT-ish] Session refresh philosophy
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote: I can see how your approach adds functionality by performing as expected if the user uses the Back button or opens the app. in more than one browser window. The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? My module addresses the first concern of an attacker changing the data in the hidden fields. On encoding, I hash together the encoded data and a secret to get a security hash. On decoding, I perform the same hashing and make sure it matches. Without the secret data no one can generate a security hash for modified data. My module does not address encryption. It would be trivial to add. It wasn't a concern with my application. By note of comparison, it looks like CGI::EncryptForm addresses both the encryption and non-user-modifiable concerns for the hidden data. David
RE: [OT-ish] Session refresh philosophy
Drew Taylor [mailto:[EMAIL PROTECTED]] wrote: I just looked at CGI::EncryptForm and David's module. The thing I like right off the bat about C:EF is that you pass a href to encrypt() and get back a href from decypt(). Perhaps I missed something, but FormContainer takes a string, not a data structure. I prefer the simplicity of just worrying about a structure, and not having to worry about converting it to a string. My module, FormContainer, takes arbitrary data structures like hash references too. You probably didn't see this because I used my own serializer module called FreezeThawLite instead of Storable. The lack of documentation of my module may have also been a problem. :-) I mentioned that a trivial rewrite to use Storable would be required when I attached the code. Simply replace FreezeThawLight::freeze with Storable::freeze and FreezeThawLight::thaw with Storable::thaw. :-) I agree with you that having to manually serialize session data to a string would be a real pain! That said, I like the approach that the two modules use. One just goes an extra step to guarantee data security. While looking for full-time employment, I've been doing some freelance work, which basically is small CGI apps. C:EF looks like it would make my life much easier by ensuring consistent state w/ small effort on my part, and take care of any security precautions as well. Combine that w/ CGI::Application (after I add TT2 support :-) ), and my life as a freelance CGI guy just got a whole lot easier. See my last message about the security comparisons. Thank you to everyone who contributed to this thread. I've gotten all kinds of neat ideas I'll use in future projects! Good stuff. David
Re: [OT-ish] Session refresh philosophy
Hi there, On Mon, 18 Feb 2002, Milo Hyson wrote: maybe I'm just approaching the problem incorrectly. If one is doing a shopping-cart-style application (whereby someone selects/configures multiple items before they're ultimately committed to a database) how else would you do it? There has to be some semi-persistent (i.e. inter-request) data where selections are stored before they're confirmed. You can for example send a hidden form object back and forth between your Client and the app. 73, Ged.
Re: Session refresh philosophy
Milo Hyson writes: shopping-cart-style application (whereby someone selects/configures multiple items before they're ultimately committed to a database) how else would you do it? There has to be some semi-persistent (i.e. inter-request) data where selections are stored before they're confirmed. As I understand it, the session data is state which is committed to the database on each request (possibly). It would seem to me that instead of denomalizing the state into a separate session table, you should just store it in a normal table. If the data needs to be expired, then it can be time stamped when it is written. The point is that it's always simpler to use the existing tables directly rather than making a copy and storing it in the database somewhere else. This usually reduces the code by half or more, because you don't have to worry about making the copy in the first place. Simpler code is more reliable and usually runs faster. To me, sessions are negativist. My expectation is that users will end up clicking OK (making the purchase). If that is the case, you are much better off putting the data were belongs right from start. You may bind it to an ephemeral entity, such as a shopping cart, but when the order is complete the only thing you have to do is free the cart and replace it with an order. The items, amounts, and special considerations have already been stored. If most of your users are filling shopping baskets and walking away from them, it may be a problem with the software. Checkout http://www.useit.com for some ideas on how to improve the ratio. Often you can avoid any server side persistence by using hidden fields in the forms. We use this technique extensively, and we have encapsulated it so that it is easy to use. For example, you might have a sub form which asks the user to fill in an address. When the user clicks on the fill in address button, the server squirrels away the context of the current form in the hidden fields of the address form. When the user clicks OK on the address form, the fields are stuffed back into the original form including the new address. If you have a performance problem, solve it when you can measure it. Sessions can mitigate performance problems, but so can intelligent caching, which avoids statefulness in the client-server protocol. Rob P.S. For sample sessionless sites, visit http://www.bivio.com and http://petshop.bivio.biz (which runs on a 3 year old 300mhz box running Apache and Postgres).
Re: Session refresh philosophy
As I understand it, the session data is state which is committed to the database on each request (possibly). It would seem to me that instead of denormalizing the state into a separate session table, you should just store it in a normal table. The typical breakdown I use for this is to put simple state information that connects this browser to long-term data in the session, and everything else in normal database tables. So, I put the user's ID (if this session belongs to an identified user), a flag telling whether or not this user has given a secure login so far in this session, and not much else in the session. Actually, even this stuff could be put into a normalized sessions table rather than serialized to a blob with Storable. It just means more work if you ever change what's stored in the session. - Perrin
Re: Session refresh philosophy
Perrin Harkins writes: Actually, even this stuff could be put into a normalized sessions table rather than serialized to a blob with Storable. It just means more work if you ever change what's stored in the session. This is a tough question. If you store it in a blob, you can't query it with an ad hoc SQL query. If you store it in a table, you have to deal with data evolution. On the whole, I vote for tables over blobs. My reasoning is that you have to deal with data evolution anyway. We have had about 200 schema changes in the last two years, and very few of them have had anything to do with user/visitor state. Rob
Re: [OT-ish] Session refresh philosophy
And that is what I am doing for a small project I'm working on now. In my case, I'm not sure about the capabilities of the remote server, and I know for sure that I don't have a database available, so session information is saved via hidden form fields. It's primitive, but was actually a bit of a challenge to make sure a (unused) hidden field and a visible form element don't appear in the same form. Not my first choice, but it definitely works. Drew At 11:42 AM 2/19/2002 +, Ged Haywood wrote: Hi there, On Mon, 18 Feb 2002, Milo Hyson wrote: maybe I'm just approaching the problem incorrectly. If one is doing a shopping-cart-style application (whereby someone selects/configures multiple items before they're ultimately committed to a database) how else would you do it? There has to be some semi-persistent (i.e. inter-request) data where selections are stored before they're confirmed. You can for example send a hidden form object back and forth between your Client and the app. Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [OT-ish] Session refresh philosophy
And that is what I am doing for a small project I'm working on now. In my case, I'm not sure about the capabilities of the remote server, and I know for sure that I don't have a database available, so session information is saved via hidden form fields. It's primitive, but was actually a bit of a challenge to make sure a (unused) hidden field and a visible form element don't appear in the same form. Not my first choice, but it definitely works. Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned a few days ago about storing state entirely inside a cookie with a message digest. The only difference is that by sticking it in a form element you're attaching it to a specific page. - Perrin
Re: [OT-ish] Session refresh philosophy
At 05:55 PM 2/19/2002 -0500, Perrin Harkins wrote: Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned a few days ago about storing state entirely inside a cookie with a message digest. The only difference is that by sticking it in a form element you're attaching it to a specific page. True. I was very intrigued by his approach, and might use something like that to increase the security of my app by verifying the hidden form field contents. I suppose I could follow his approach, but the amount of data I need to store could possibly overwhelm the 4KB cookie limit. In this case, simple was better - simple application, simple session. And I know I can count on every browser implementing forms. :-) Drew Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [OT-ish] Session refresh philosophy
On Tuesday 19 February 2002 02:55 pm, Perrin Harkins wrote: Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned a few days ago about storing state entirely inside a cookie with a message digest. The only difference is that by sticking it in a form element you're attaching it to a specific page. That's not a bad idea. I guess if you're paranoid about snooping you could always encrypt the cookie. -- Milo Hyson CyberLife Labs, LLC
RE: [OT-ish] Session refresh philosophy
Drew Taylor [mailto:[EMAIL PROTECTED]]: And that is what I am doing for a small project I'm working on now. In my case, I'm not sure about the capabilities of the remote server, and I know for sure that I don't have a database available, so session information is saved via hidden form fields. It's primitive, but was actually a bit of a challenge to make sure a (unused) hidden field and a visible form element don't appear in the same form. Not my first choice, but it definitely works. I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. The encoded information is serialized, gzipped, Base64 encoded, and then split into reasonable length hidden fields. It looks like this: input type=hidden name=_fc_part000 value=eJx9zVEKwyAQhOEbhSiBhL2MrI1GW3VhR8n1a6HPeR6++ZNZCQd15YYYFIZWWEuQ2G/W4 IKqqDul input type=hidden name=_fc_part001 value=cm5Ic7Ab3UneXNmL7ym3C33EuLykTmywE0IpLp9jHu/0l2ye5UZ+lM+v/gUagTUd input type=hidden name=_fc_security value=e99478182b7c579ce65dddb676bbe52e This way, you don't have to worry about creating hidden form fields in your templates for every variable you need to encode. In your perl, simply call the session encode and decode methods. You are also assured that nobody messed with the data. You can easily pass arbitrarily complex session information from one page to another without using a database, and the session info is truly tied to the *page*. Use of the back button, therefore, doesn't break anything. I've attached some code. To use the code, you'll have to replace the module FreezeThawLite with Storable. Also, beware the \r\n newlines. (I pulled this out of CVS on my windows desktop.) HTH. David
RE: [OT-ish] Session refresh philosophy
David Harris [[EMAIL PROTECTED]] wrote:
[snip]
I've attached some code. To use the code, you'll have to replace the
module FreezeThawLite with Storable. Also, beware the \r\n newlines.
(I pulled this out of CVS on my windows desktop.)
I forgot to actually attach the code
David
package Fusion::FormContainer;
use strict;
use Digest::MD5 ();
use MIME::Base64 ();
use FreezeThawLight ();
use Compress::Zlib ();
use Carp;
# this respresents a securty hole if we open-source this module.. the securtiy string
# needs to be passed as confguration at that point somehow.
sub _create_security_string
{
my $string = shift;
my $secret = EOT;
--begin-secret--
enter your own secret binary of base64 encoded data here
enter your own secret binary of base64 encoded data here
enter your own secret binary of base64 encoded data here
enter your own secret binary of base64 encoded data here
-end-secret--
EOT
my $ctx = Digest::MD5-new;
$ctx-add($string);
$ctx-add($secret);
return $ctx-hexdigest;
}
sub encode
{
my $info = shift;
my $prefix = shift;
my $string =
MIME::Base64::encode(Compress::Zlib::compress(FreezeThawLight::freeze($info)));
$string =~ s/\n$//;
my @array;
push @array, (${prefix}_fc_security, _create_security_string($string));
my $part_number = 0;
foreach my $part ( split \n, $string ) {
my $part_number_string = sprintf(%.3d, $part_number);
push @array, (${prefix}_fc_part$part_number_string, $part);
$part_number++;
}
if ( wantarray ) {
return @array;
} else {
my $html;
while ( @array ) {
my $name = shift(@array);
my $value = shift(@array);
$html .= EOT;
input type=hidden name=$name value=$value
EOT
}
return $html;
}
}
sub decode
{
my $apr = shift;
my $prefix = shift;
my $security = $apr-param(${prefix}_fc_security);
my @string_parts;
my $part_number = 0;
while ( 1 ) {
my $part_number_string = sprintf(%.3d, $part_number);
my $part = $apr-param(${prefix}_fc_part$part_number_string);
last if ( $part eq );
push @string_parts, $part;
$part_number++;
}
my $string = join \n, @string_parts;
croak tampered or malformed FormContainer: securty string and string don't
match
if ( _create_security_string($string) ne $security );
return
FreezeThawLight::thaw(Compress::Zlib::uncompress(MIME::Base64::decode($string)));
}
1;
Re: [OT-ish] Session refresh philosophy
I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. Sounds a lot like CGI::SecureState. Have you ever looked at it? - Perrin
Session refresh philosophy
Like my previous question on object caching, this one is potentially a matter of style as well. When it comes to implementing expirations on session data, I've encountered two schools of thought on when is best to refresh the timestamp/expiration. In that the general idea of expiration is to discard information that hasn't been accessed in a while, some feel that updating the timestamp is best done during both loading and storing. After all, both are considered accessing the data. However, taking into account the general pattern of HTTP request processing, I feel that updating only during storage is best, especially when using a database for persistence. Suppose one has a SQL table for saving session data. When a request comes in, the session is loaded and its expiration is examined. Assuming the session is still valid, one could issue another statement to the database to refresh the session's expiration time. That's two database ops before the session is even used. If you count the one at the end for storing the session back in the database it's a total of three per request. My feeling is that if you're going to be writing the session back within (hopefully) a fraction of a second anyway, you might as well wait until then to refresh the time-out. The project I'm working on requires that I design a custom application platform for current and future projects. My proposed solution to the session management problem is as follows: 1) A fix-up handler is called to extract the session ID from a cookie. Assuming a valid ID was found, the session is loaded, de-serialized and checked for expiration. If all is well, the a reference to the session is stored in pnotes for use by the application. 1a) If for some reason no session was found (e.g. no cookie) a new one is created and a new cookie is stuffed in the outgoing headers. 2) During content-generation, the application obtains the session reference from pnotes and uses it as necessary. 3) A clean-up handler is called to re-serialize the session and stick it back in persistent storage (updating the expiration in the process). The handler of course does nothing if the application destroyed the session in step 2. I'm still fairly new to mod_perl and haven't fully taken apart all of the various application servers out there to see how they do it. I would still appreciate any feedback anyone may have on the above. Thanks in advance. -- Milo Hyson CyberLife Labs, LLC
Re: Session refresh philosophy
Milo Hyson writes: 1) A fix-up handler is called to extract the session ID from a cookie. [snip] 1a) If for some reason no session was found (e.g. no cookie) a new one is [snip] 2) During content-generation, the application obtains the session reference [snip] 3) A clean-up handler is called to re-serialize the session and stick it back I may be asking the wrong question: is there a need for sessions? This seems like a lot of work when, for most applications, sessions are unnecessary. Rob
Re: Session refresh philosophy
On Monday 18 February 2002 07:29 pm, Rob Nagler wrote: I may be asking the wrong question: is there a need for sessions? This seems like a lot of work when, for most applications, sessions are unnecessary. I don't see how they could be unnecessary for what we're doing. Then again, maybe I'm just approaching the problem incorrectly. If one is doing a shopping-cart-style application (whereby someone selects/configures multiple items before they're ultimately committed to a database) how else would you do it? There has to be some semi-persistent (i.e. inter-request) data where selections are stored before they're confirmed. -- Milo Hyson CyberLife Labs, LLC
Re: Cookie as session store
On Thu, 14 Feb 2002 11:35:14 -0500 Perrin Harkins [EMAIL PROTECTED] wrote: It's really a good idea to do this even when the cookie is nothing but a session ID. A standard module for this like the one Jay mentioned would definitely be nice. Apache::Cookie::Encrypted seems to be the one. http://search.cpan.org/search?dist=ApacheCookieEncrypted -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Cookie as session store
Jeffrey - interesting point! What did you have in mind to encrypt the cookie data? Perhaps you could use Storable to serialize data structure then convert, crypt to scramble and then MIME64 to text encode? I agree with you on processing delays - that is probably the biggest drawback to needing to send cookies as part of response header. Using Template Toolkit a lot myself, I have to make a workaround to handle the cookie situation as well. I've got a tied interface to Apache::Cookie's mostly completed - it would be easy to add the encryption that you describe above to them. See: http://www.infonium.com/perl/ for a link to Apache::Tie::Cookie. Featuring tied interface and lazy (demand) loading of cookie data. Jay - Original Message - From: Jeffrey W. Baker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 13, 2002 3:00 PM Subject: Cookie as session store I have sometimes proposed or recommended schemes of storing session information in an HTTP cookie, encoded and protected by cryptographic digest. I know some people on this list have implemented similar schemes, but I have never actually had occasion to do so. Now I am doing that, and I realize the chief drawback to this scheme: all session information has to be set before generating any HTML output. The chief advantage is no requirement for server-side storage of session. For certain applications, saving all output until the session is serialized may significantly increase the latency of the first data packet in the HTTP response. -jwb
Re: Cookie as session store
On Thu, 2002-02-14 at 06:17, Jay Lawrence wrote:
Jeffrey - interesting point!
What did you have in mind to encrypt the cookie data? Perhaps you could use
Storable to serialize data structure then convert, crypt to scramble and
then MIME64 to text encode?
I am not encrypting the session data in this system, because the
contents are not sensitive. I base64 encode a gzipped Storable-frozen
object, which contains another Storable-frozen object and the SHA1
digest of itself.
When the cookie is recovered, I simply decode, uncompress, thaw, check
the digest, and thaw the inner object. The code is simple:
sub realize_session {
my ($foo) = @_;
my ($i, $s);
$i = thaw(uncompress(decode_base64($foo)));
if (sha1_hex($i-{content} . BIG_SECRET) eq $i-{hash}) {
$s = thaw($i-{content});
return $s;
}
return undef;
}
sub serialize_session {
my ($s) = @_;
my ($i, $frz, $foo);
$frz = nfreeze($s);
$i = {
content = $frz
, hash= sha1_hex($frz . BIG_SECRET)
};
$foo = encode_base64(compress(nfreeze($i)));
return $foo;
}
It's fortunate that all of these functions are fast. Base64, Zlib,
Storable, and SHA1 are all implemented in C.
I agree with you on processing delays - that is probably the biggest
drawback to needing to send cookies as part
of response header. Using Template Toolkit a lot myself, I have to make a
workaround to handle the cookie situation
as well.
My strategy for document generation is to build a DOM tree and then
create the output by serializing the DOM to XML or HTML. So, it is
natural in this application to just set everything up before sending the
response. But I can imagine that if you wanted an intermediate page,
progress indications, and so forth you might have to jump through hoops.
I've got a tied interface to Apache::Cookie's mostly completed - it would be
easy to add the encryption that you describe above to
them. See: http://www.infonium.com/perl/ for a link to Apache::Tie::Cookie.
Featuring tied interface and lazy (demand) loading of cookie data.
Thanks!
-jwb
Re: Cookie as session store
When the cookie is recovered, I simply decode, uncompress, thaw, check the digest, and thaw the inner object. It's really a good idea to do this even when the cookie is nothing but a session ID. A standard module for this like the one Jay mentioned would definitely be nice. My strategy for document generation is to build a DOM tree and then create the output by serializing the DOM to XML or HTML. So, it is natural in this application to just set everything up before sending the response. Since I usually structure my applications to do all the work and then pass some data to a template, they also follow this order. The main problem I see with sending some HTML before the work is complete is that if something goes wrong later on you have no way to send a nice error page out. I sometimes see people having this problem on sites I visit: I get an OK response and some HTML and then a second set of headers with an error code and it looks like garbage in a browser. - Perrin
Re: Cookie as session store
Perrin Harkins wrote: When the cookie is recovered, I simply decode, uncompress, thaw, check the digest, and thaw the inner object. It's really a good idea to do this even when the cookie is nothing but a session ID. A standard module for this like the one Jay mentioned would definitely be nice. I dunno... That sounds lie a LOT of overhead for just a session ID that's gonna result in server lookups too... Issac
Re: Cookie as session store
I dunno... That sounds lie a LOT of overhead for just a session ID that's gonna result in server lookups too... It's really not. It adds a negligeble amount of time to the request. As Jeffrey pointed out, the functions he's using are all in C and very fast. Why verify session IDs? To make it hard to hijack sessions. This way it isn't enough to just guess someone else's session ID: you also have to know how to generate the proper digest for it. This is also useful to prevent people from screwing up your stats with bogus IDs. Many people log the session ID for use in calculating people's path through the site and similar things. Often this is done for pages that don't actually retrieve the session data from the backend store. Being able to verify that you have a valid session without hitting your data store can be very useful. - Perrin
Cookie as session store
I have sometimes proposed or recommended schemes of storing session information in an HTTP cookie, encoded and protected by cryptographic digest. I know some people on this list have implemented similar schemes, but I have never actually had occasion to do so. Now I am doing that, and I realize the chief drawback to this scheme: all session information has to be set before generating any HTML output. The chief advantage is no requirement for server-side storage of session. For certain applications, saving all output until the session is serialized may significantly increase the latency of the first data packet in the HTTP response. -jwb
Re: Apache::Session getting DESTROYed in wrong order
I register a clean up handler to explicitly untie the session variable. I am
not
sure how to do this in the setup you have running...so I can't be of much
explicit help.
Jay
- Original Message -
From: Ken Williams [EMAIL PROTECTED]
To: Perrin Harkins [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, January 18, 2002 1:53 AM
Subject: Re: Apache::Session getting DESTROYed in wrong order
On Friday, January 18, 2002, at 12:44 AM, Perrin Harkins wrote:
In a Mason context, which is where I'm using it, I do this in my
top-level autohandler (ignore the main:: subroutines, they're just for
pedagogy):
%init
# 'local' so it's available to lower-level components
local *session;
my $dbh = ::get_dbh;
my $session_id = ::get_cookie('_session_id');
tie %session, 'Apache::Session::MySQL', $session_id,
{Handle = $dbh, LockHandle = $dbh};
...
/%init
Geez, that's awfully confusing to look at (local and typeglobs is not a
newbie-friendly combo). Isn't there a simpler way? What about putting
it in pnotes?
I don't think there's a simpler way. Putting it in pnotes means that
all other components will also have to use $r-pnotes('session'), rather
than just using %session.
Perhaps local(*session) is better than local *session? It at least
looks less like a pointer to local. ;-)
-Ken
Re: Apache::Session getting DESTROYed in wrong order
I register a clean up handler to explicitly untie the session variable. I have found that it's safer to put things in pnotes than to use globals and cleanup handlers. We used a lot of cleanup handlers at eToys to clear globals holding various request-specific things, and we started getting unpredictable segfaults. When I moved them to pnotes instead the segfaults went away. I think it may have had something to do with cleanup handlers running in an unpredictable order and some of them trying to use things that were already cleaned up, so it was probably my fault, but pnotes just seems a bit more foolproof. - Perrin
locking bug in Apache::Session::File
I've been told this is the place to send questions related to apache perl
modules.
I believe I have discovered a locking bug in Apache::Session::File.
The following code should retrieve an existing session from the file system
and place an exclusive lock on the session file:
my $locking_args = { 'Directory' = '/tmp/sessions_dir',
'LockDirectory' = '/tmp/sessions_lock_dir',
'Transaction' = '1' };
tie(%session, 'Apache::Session::File', $session_id, $locking_args);
The 'locking_args' hash is used to pass parameters to the locking object
contained by the session object. According to the Apache::Session
documentation any true value of Transaction should force the object to
exclusively lock the session file. Unfortunately this does not appear to
work (at least not all the time).
Looking in the TIEHASH I think I've discovered the reason. The session
uses a locking object. In this case the locking object is
Apache::Session::Lock::File. This object has two methods which acquire
locks, aptly named acquire_read_lock and acquire_write_lock. The first
method uses flock to acquire a non-exclusive lock. The second method uses
flock to acquire an exclusive lock. TIEHASH checks the value of
'Transaction' and calls acquire_write_lock if the value is true. It then
calls a method named restore. It does this regardless of the value of
'Transaction'. The restore method calls acquire_read_lock. Again it does
this without examining the value of 'Transaction'.
Now according to the flock man page if a process requests a lock on a file
it already has locked, then the new lock will replace the old one. Thus
requesting a non-exclusive lock on file which the process already has an
exclusive lock for will cause the non-exclusive lock to replace the
exclusive one.
The call to acquire_read_lock in the restore method wipes out the exclusive
lock on the session file. This makes it impossible to maintain
transactional consistency with Apache::Session::File.
I was wondering if anyone else out there has run into this problem. Is
there a fix available? My version of Apache::Session is 1.54 which is the
newest version that I see on CPAN. Is there another version out there that
fixes this problem or should I bring this up with the author?
Re: Apache::Session getting DESTROYed in wrong order
On Friday, January 4, 2002, at 02:22 AM, Ken Williams wrote:
For the sake of thread completion, here's a script which demonstrates
the bug. It turns out to be a Perl bug (5.6.1, at least), not an
Apache::Session bug. I'll post to p5p after I post here.
I was surprised to find the it's not a bug, it's a feature defense on
p5p. So here's an update. The following is either a workaround, or the
proper fix, depending on what you think Perl's proper behavior should
be. ;-)
{
local *session;
tie %session, 'Apache::Session::MySQL', ...;
...
}
The local *session; is the important bit. It doesn't work to do
local %session;, because %session will still be tied even after it
goes out of scope, and thus the hash data will never get written to
storage.
In a Mason context, which is where I'm using it, I do this in my
top-level autohandler (ignore the main:: subroutines, they're just for
pedagogy):
%init
# 'local' so it's available to lower-level components
local *session;
my $dbh = ::get_dbh;
my $session_id = ::get_cookie('_session_id');
tie %session, 'Apache::Session::MySQL', $session_id,
{Handle = $dbh, LockHandle = $dbh};
...
/%init
-Ken
Re: Apache::Session getting DESTROYed in wrong order
In a Mason context, which is where I'm using it, I do this in my
top-level autohandler (ignore the main:: subroutines, they're just for
pedagogy):
%init
# 'local' so it's available to lower-level components
local *session;
my $dbh = ::get_dbh;
my $session_id = ::get_cookie('_session_id');
tie %session, 'Apache::Session::MySQL', $session_id,
{Handle = $dbh, LockHandle = $dbh};
...
/%init
Geez, that's awfully confusing to look at (local and typeglobs is not a
newbie-friendly combo). Isn't there a simpler way? What about putting
it in pnotes?
- Perrin
Re: Apache::Session getting DESTROYed in wrong order
On Friday, January 18, 2002, at 12:44 AM, Perrin Harkins wrote:
In a Mason context, which is where I'm using it, I do this in my
top-level autohandler (ignore the main:: subroutines, they're just for
pedagogy):
%init
# 'local' so it's available to lower-level components
local *session;
my $dbh = ::get_dbh;
my $session_id = ::get_cookie('_session_id');
tie %session, 'Apache::Session::MySQL', $session_id,
{Handle = $dbh, LockHandle = $dbh};
...
/%init
Geez, that's awfully confusing to look at (local and typeglobs is not a
newbie-friendly combo). Isn't there a simpler way? What about putting
it in pnotes?
I don't think there's a simpler way. Putting it in pnotes means that
all other components will also have to use $r-pnotes('session'), rather
than just using %session.
Perhaps local(*session) is better than local *session? It at least
looks less like a pointer to local. ;-)
-Ken
Re: Apache::Session getting DESTROYed in wrong order
Hey,
For the sake of thread completion, here's a script which demonstrates
the bug. It turns out to be a Perl bug (5.6.1, at least), not an
Apache::Session bug. I'll post to p5p after I post here.
Note that $foo and %bar are cleaned up by refcount, but %foo isn't
cleaned up until global destruction. This means there must be some bad
interaction between tie(), closures, and global variables, I guess.
-
#!/usr/bin/perl
use strict;
{
package Dummy;
sub new { bless {@_[1,2]} }
sub TIEHASH { bless {@_[1,2]} }
sub DESTROY { warn Destroying $_[0]-{name}: $_[0] }
}
use vars qw(%foo $foo);
{
# Will get cleaned up properly
local $foo = new Dummy(name = '$foo');
# Will get cleaned up properly
my %bar;
tie %bar, 'Dummy', name = '%bar';
# Won't get cleaned up properly
local %foo;
tie %foo, 'Dummy', name = '%foo';
}
Destroying %bar: Dummy=HASH(0x632c) at destroy.pl line 9.
Destroying $foo: Dummy=HASH(0x641c) at destroy.pl line 9.
Destroying %foo: Dummy=HASH(0x22ccc) at destroy.pl line 9 during global
destruction.
Investigating with Devel::Peek suggests that it's a %foo refcount
problem, it's somehow getting set to 2 after tie(%foo).
-Ken
Re: Apache::Session getting DESTROYed in wrong order
# Won't get cleaned up properly local %foo; tie %foo, 'Dummy', name = '%foo'; local only make a copy of the original value and restores it at the end of the scope, so %foo will not destroyed, but restored at the end of the scope. I guess this is the reason my it still stays tied. In my experiences there are more weired behaviours with tied hashs and arrays. (e.g. don't access a tied hash inside of a method of a tied hash, use FETCH instead, tied hash element doesn't always spring into existence, like normal hash elements does). You have to use them with some care. Investigating with Devel::Peek suggests that it's a %foo refcount problem, it's somehow getting set to 2 after tie(%foo). 2 is ok. one for %foo itself and one because it's tied to another object Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Apache::Session getting DESTROYed in wrong order
On Friday, January 4, 2002, at 02:48 AM, Gerald Richter wrote:
# Won't get cleaned up properly
local %foo;
tie %foo, 'Dummy', name = '%foo';
local only make a copy of the original value and restores it at the end
of
the scope, so %foo will not destroyed, but restored at the end of the
scope.
I guess this is the reason my it still stays tied.
AMS just posted this small test case to p5p:
sub X::TIEHASH{bless{}}
{ local %x; tie %x, X } print tied %x ? a : b;
5.004_03 prints b, and 5.004_04 (and higher) prints a. I think b
is the proper behavior, at least that's my opinion.
-Ken
Re: Apache::Session getting DESTROYed in wrong order
Hi Aaron,
I don't have a test case involving Apache::Session yet (I've been out of
town for a couple days), but here's a simple one in Perl that
demonstrates the DESTROY order problem:
--
#!/usr/bin/perl
{
package Outer;
sub new { bless {inner = 'Inner'-new} }
sub DESTROY { warn Destroying $_[0] }
}
{
package Inner;
sub new { bless {} }
sub DESTROY { warn Destroying $_[0] }
}
{
warn refcount destruction:\n;
my $foo = 'Outer'-new;
}
warn \nglobal destruction:\n;
my $bar = 'Outer'-new;
$bar-{self} = $bar;
--
So I think I need to find out why the Apache::Session objects aren't
being destroyed until global destruction time, i.e. why their refcounts
aren't going to zero.
This is in the context of testing the new HTML::Mason 1.10, so something
complicated might be happening with that too.
-Ken
On Wednesday, January 2, 2002, at 04:15 AM, Aaron E. Ross wrote:
refcount destruction. I've declared %session as a locally-scoped
variable, so it should evaporate before global destruction, unless it's
got circular data structures or something. Anyone know what might be
going on?
Do you have a simple case we can test yet?
Re: Apache::Session getting DESTROYed in wrong order
On Thursday, January 3, 2002, at 11:57 AM, Perrin Harkins wrote: I don't have a test case involving Apache::Session yet (I've been out of town for a couple days), but here's a simple one in Perl that demonstrates the DESTROY order problem: That's sort of a weird example, since it has a circular reference. Does it have problems without the circular ref? The circular reference was the only way I could think of to force an object to be destroyed during global destruction. I don't know whether it has a problem without circularity or not. At a guess, I'd say you're making an unintentional closure somewhere. Hmm, that may be - Mason does create more closures now than it used to. It seems like only 'named' closures would create this problem, though, and not 'anonymous' closures (since the refcount of the anonymous closure itself should go to zero, freeing its contents). Mason is supposed to be using all anonymous closures. I'm finding the destruction behavior highly unpredictable with the 'named' closure actually, so maybe I should bring it up on p5p. Perhaps the order of destruction is just random during global destruction, because I've seen it happen from the inside out from the outside in. -Ken
Re: Apache::Session getting DESTROYed in wrong order
The circular reference was the only way I could think of to force an
object to be destroyed during global destruction.
What happens if you use a global?
Hmm, that may be - Mason does create more closures now than it used to.
It seems like only 'named' closures would create this problem, though,
and not 'anonymous' closures (since the refcount of the anonymous
closure itself should go to zero, freeing its contents).
I was thinking of this situation:
my %session = get_session();
sub transmogrify {
$session{'foo'}++;
}
I could be wrong, but I think that will make %session stick around, because
transmogrify() now has a private copy of it.
- Perrin
Re: Apache::Session getting DESTROYed in wrong order
On Mon, 31 Dec 2001, Ken Williams wrote: Hey, I'm having problems with Apache::Session, the symptom is that none of my data is getting written to the database. It's not the nested-data problem, since I'm not using any nested data structures. After some investigation, I've discovered that the Apache::Session::Store::MySQL::DESTROY routine is getting called before the Apache::Session::MySQL::DESTROY routine, so when the latter is called it doesn't have any way to write to the database. I think Perl is supposed to guarantee that the outer object's DESTROY is called before the inner object's, but I think maybe this guarantee doesn't extend to the global destruction phase. So I'm wondering why the session is getting cleaned up in global destruction rather than refcount destruction. I've declared %session as a locally-scoped variable, so it should evaporate before global destruction, unless it's got circular data structures or something. Anyone know what might be going on? This is Apache::Session version 1.53. Note: this problem isn't related to mod_perl, but IIRC this list is the proper place for discussing Apache::Session. Ken, Yeah this is the right list for Apache::Session discussion, and Perrin is the unofficial guy who answers all the questios, since I don't pay that much attention. This seems like a really weird problem. The Store module is destroyed while another module still has a reference to it. Unfortunately for you and I, the only conclusion I have been able to draw is that Perl's DESTROY magic is unreliable. We have modules in my company where things are randomly undefined in DESTROY subroutines, because the DESTROY of the referenced thing has already been called. So, somewhere in Perl there is a bug, possibly an off-by-one in the reference counting. Anyway you can work around it. Explicitly call tied(%session)-save() when the time is right. -jwb
Re: Apache::Session getting DESTROYed in wrong order
On Thursday, January 3, 2002, at 02:02 PM, Jeffrey W. Baker wrote: This seems like a really weird problem. The Store module is destroyed while another module still has a reference to it. Unfortunately for you and I, the only conclusion I have been able to draw is that Perl's DESTROY magic is unreliable. We have modules in my company where things are randomly undefined in DESTROY subroutines, because the DESTROY of the referenced thing has already been called. So, somewhere in Perl there is a bug, possibly an off-by-one in the reference counting. It's probably not the reference counting, since the global destruction phase uses a mark-and-sweep system rather than refcounts (and that's where my knowledge ends). I think that the order of global object destruction is totally random, whereas refcount destruction is predictable. After searching p5p, this seems to be known and accepted behavior. I suppose there could be a refcount bug that's causing %session not to be cleaned up until global destruction. Anyway you can work around it. Explicitly call tied(%session)-save() when the time is right. True, I guess I'll do that, but I'd like to figure out a little more about it too. -Ken
Re: Apache::Session getting DESTROYed in wrong order
Hi Ken, refcount destruction. I've declared %session as a locally-scoped variable, so it should evaporate before global destruction, unless it's got circular data structures or something. Anyone know what might be going on? Do you have a simple case we can test yet? Aaron
Apache::Session getting DESTROYed in wrong order
Hey, I'm having problems with Apache::Session, the symptom is that none of my data is getting written to the database. It's not the nested-data problem, since I'm not using any nested data structures. After some investigation, I've discovered that the Apache::Session::Store::MySQL::DESTROY routine is getting called before the Apache::Session::MySQL::DESTROY routine, so when the latter is called it doesn't have any way to write to the database. I think Perl is supposed to guarantee that the outer object's DESTROY is called before the inner object's, but I think maybe this guarantee doesn't extend to the global destruction phase. So I'm wondering why the session is getting cleaned up in global destruction rather than refcount destruction. I've declared %session as a locally-scoped variable, so it should evaporate before global destruction, unless it's got circular data structures or something. Anyone know what might be going on? This is Apache::Session version 1.53. Note: this problem isn't related to mod_perl, but IIRC this list is the proper place for discussing Apache::Session. -Ken
Apache::Session using Frames
I have been beating my head against this problem for days, to no avail. I have tried google searches, etc., still no dice. So, I apologize for the noise people. I'm using Apache::Session and cookies to perform session management. In watching the debug messages in my error_log, I can see that the cookie is created, the session is created, and all subsequent calls correctly loads the session. However, part of the design for my web application requires the use of frames, with several frames containing mod_perl generated data. Each one of those frames relies on using the session. I wouldn't think this would be a problem, except that some of the frames cannot tie to the datastore, and as a result create new sessions. I would think the default behavior would block until the session is unlocked, but this doesn't seem to be the case. I was first using Apache::Session::Flex (For easier configuration), but have also tried Apache::Session::MySQL, ::DB_File and ::File, all exhibit the same problem. This site is developed using AxKit and AxKit::XSP::Session, but the sessions are created before AxKit is even invoked so that isn't the issue. Any suggestions? I'd like to resolve this without loosing my hair. :) -man Michael A Nachbaur
Re: Apache::Session using Frames
Just to let anyone who was wondering (and for the benefit of the archives), I ended up ditching sessions all together. Instead, I'm using Apache::AuthDBI to do authentication, and am making calls directly to my database server to maintain state. Its not the most pleasant way of maintaining state, but at least it works. -man Michael A Nachbaur
Re: Apache::Session using Frames
Just to let anyone who was wondering (and for the benefit of the archives), I ended up ditching sessions all together. Instead, I'm using Apache::AuthDBI to do authentication, and am making calls directly to my database server to maintain state. Its not the most pleasant way of maintaining state, but at least it works. Then this won't be much help to you anymore, but here are a couple of things that could have been happening: - Not getting the cookies sent from all frames. You may have a race condition involving when the cookie gets storeed and when other frames send their requests. - Not using the locking API correctly. You didn't post any code, but the locking options for Apache::Session sometimes trip people up and you may have had a misconfiguration of some kind. Anyway, there's nothing wrong with writing directly to the database. Apache::Session is just a convenient hash interface on top of that. - Perrin
Apache::Session and frames
I have been beating my head against this problem for days, to no avail. I have tried google searches, etc., still no dice. So, I apologize for the noise people. I'm using Apache::Session and cookies to perform session management. In watching the debug messages in my error_log, I can see that the cookie is created, the session is created, and all subsequent calls correctly loads the session. However, part of the design for my web application requires the use of frames, with several frames containing mod_perl generated data. Each one of those frames relies on using the session. I wouldn't think this would be a problem, except that some of the frames cannot tie to the datastore, and as a result create new sessions. I would think the default behavior would block until the session is unlocked, but this doesn't seem to be the case. I was first using Apache::Session::Flex (For easier configuration), but have also tried Apache::Session::MySQL, ::DB_File and ::File, all exhibit the same problem. This site is developed using AxKit and AxKit::XSP::Session, but the sessions are created before AxKit is even invoked so that isn't the issue. Any suggestions? I'd like to resolve this without loosing my hair. :) -man Michael A Nachbaur
Re: Apache::Session and frames
Basic Idea, what is the path argument of the cookie you are using? If the called pages are lying underneath different roots then the cookie won't be read. I even do not loose the session between windows :-) Thanks for the prompt reply. The way I have this going, is a file at: /index.xsp which just performs a redirect to /callisto.xsp (so that it has a chance to create the cookie). /callisto.xsp creates a frameset which loads, among other things: /folder-listing.xsp /task-listing.xsp /sitename.xsp Each one of those sub pages are in their own frames, and each attempts to load the session. Occasionally, one of them successfully loads the original session, but the other two end up creating their own sessions. When I call: tie %session, 'Apache::Session::Flex', $id, \%options; it doesn't return anything in $@, except there is no data inside %session. Therefore, the code that checks for _session_id, thinks that this is a new session, and goes ahead to create one. Any ideas?
Re: Apache::Session and frames
At 3:06 PM -0800 12/5/01, Michael A Nachbaur wrote: I have been beating my head against this problem for days, to no avail. I have tried google searches, etc., still no dice. So, I apologize for the noise people. I'm using Apache::Session and cookies to perform session management. In watching the debug messages in my error_log, I can see that the cookie is created, the session is created, and all subsequent calls correctly loads the session. However, part of the design for my web application requires the use of frames, with several frames containing mod_perl generated data. Each one of those frames relies on using the session. I wouldn't think this would be a problem, except that some of the frames cannot tie to the datastore, and as a result create new sessions. I would think the default behavior would block until the session is unlocked, but this doesn't seem to be the case. I was first using Apache::Session::Flex (For easier configuration), but have also tried Apache::Session::MySQL, ::DB_File and ::File, all exhibit the same problem. This site is developed using AxKit and AxKit::XSP::Session, but the sessions are created before AxKit is even invoked so that isn't the issue. Any suggestions? I'd like to resolve this without loosing my hair. :) Cookies set in a parent frame are not immediatly accessable to a child frames. It's a fun little bug that requires a full frame reload to be detected. Another thing to watch out for are the cookie paths. I've never used Apache::Session, so I don't know what path is set for the cookies, but if the pages loading in the child frames have non matching urls, then the session cookies aren't going to come through. Good Luck, Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
Re: Apache::Session and frames
Hi Michael -
I'm using Apache::Session and cookies to perform session management. In
watching the debug messages in my error_log, I can see that the cookie
is created, the session is created, and all subsequent calls correctly
loads the session. However, part of the design for my web application
requires the use of frames, with several frames containing mod_perl
generated data. Each one of those frames relies on using the session. I
wouldn't think this would be a problem, except that some of the frames
cannot tie to the datastore, and as a result create new sessions.
We had similar problems with a frameset scheme - the browser requests the
page containing the frameset definition and then almost simultaneously
requests each of the pages that must be loaded into each frame, and
confusion ensues. What worked for us (I don't know for sure if this will
help you) was to turn on the Transaction flag during the session tie,
e.g.:
tie %s, 'Apache::Session::File', $id {
Directory = '/tmp/sessions',
LockDirectory = '/var/lock/sessions',
Transaction = 1
};
which should (depending on the underlying session mechanism) provide
transactional consistency. In our case it helped prevent data loss that
was occurring while each of the frameset pages was simultaneously
monkeying with the session.
Larry Leszczynski
[EMAIL PROTECTED]
RE: Apache::Session and frames
I have 'heard' that in some browsers there is a bug using HTTP/1.1 when they use Keep-Alive. As they don't necessarily create another explicit tcp connection for a request (but rather try to keep the connection alive), they 'forget' to send the Cookie headers for subsequent requests in the same connection. It might not be the problem, but its worth checking what headers each request (and each connection) is getting/sending... -Original Message- From: Robert Landrum [mailto:[EMAIL PROTECTED]] Sent: Thursday, 6 December 2001 10:29 AM To: Michael A Nachbaur; [EMAIL PROTECTED] Subject: Re: Apache::Session and frames At 3:06 PM -0800 12/5/01, Michael A Nachbaur wrote: I have been beating my head against this problem for days, to no avail. I have tried google searches, etc., still no dice. So, I apologize for the noise people. I'm using Apache::Session and cookies to perform session management. In watching the debug messages in my error_log, I can see that the cookie is created, the session is created, and all subsequent calls correctly loads the session. However, part of the design for my web application requires the use of frames, with several frames containing mod_perl generated data. Each one of those frames relies on using the session. I wouldn't think this would be a problem, except that some of the frames cannot tie to the datastore, and as a result create new sessions. I would think the default behavior would block until the session is unlocked, but this doesn't seem to be the case. I was first using Apache::Session::Flex (For easier configuration), but have also tried Apache::Session::MySQL, ::DB_File and ::File, all exhibit the same problem. This site is developed using AxKit and AxKit::XSP::Session, but the sessions are created before AxKit is even invoked so that isn't the issue. Any suggestions? I'd like to resolve this without loosing my hair. :) Cookies set in a parent frame are not immediatly accessable to a child frames. It's a fun little bug that requires a full frame reload to be detected. Another thing to watch out for are the cookie paths. I've never used Apache::Session, so I don't know what path is set for the cookies, but if the pages loading in the child frames have non matching urls, then the session cookies aren't going to come through. Good Luck, Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
RE: Apache::Session Problem -- Addendum
On Thu, 22 Nov 2001, Jonathan M. Hollin wrote:
My code now includes:
35: # Session handler...
36: my %session; undef my $session_id;
37: use Apache::Session::MySQL;
38: tie %session, 'Apache::Session::MySQL', $session_id,
39: { DataSource = 'dbi:mysql:sessions', UserName = 'db_user', Password
= 'secret' };
40: $session_id = session_id=$session{_session_id};;
I am using Apache-Session v1.54.
The above code generates the following error:
[Thu Nov 22 10:31:38 2001] [error] PerlRun: `Can't connect(
HASH(0xbdcf54)), no database driver specified and DBI_DSN env var not set at
E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36 (in cleanup)
Can't connect( HASH(0x47e2f14)), no database driver specified and DBI_DSN
env var not set at E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36'
You aren't following the documentation. perldoc Apache::Session::MySQL.
It says to pass in connection info for a lock connection.
- Perrin
RE: Apache::Session Problem -- Addendum
Thank you everyone for the quality of help I've so far received and your
rapid responses. However... :-(
My code now includes:
35: # Session handler...
36: my %session; undef my $session_id;
37: use Apache::Session::MySQL;
38: tie %session, 'Apache::Session::MySQL', $session_id,
39: { DataSource = 'dbi:mysql:sessions', UserName = 'db_user', Password
= 'secret' };
40: $session_id = session_id=$session{_session_id};;
I am using Apache-Session v1.54.
The above code generates the following error:
[Thu Nov 22 10:31:38 2001] [error] PerlRun: `Can't connect(
HASH(0xbdcf54)), no database driver specified and DBI_DSN env var not set at
E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36 (in cleanup)
Can't connect( HASH(0x47e2f14)), no database driver specified and DBI_DSN
env var not set at E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36'
So, as you can see, I've moved on a little - but still don't have a working
session handler. Any offers?
Note: I know how boring it is to keep reading the same thread - I'll drop
it if I don't solve this today.
Kindest regards,
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
:: -Original Message-
:: From: Tatsuhiko Miyagawa [mailto:[EMAIL PROTECTED]]
:: Sent: 22 November 2001 04:34
:: To: [EMAIL PROTECTED]
:: Cc: mod_perl Mailing List
:: Subject: Re: Apache::Session Problem -- Addendum
::
::
:: On Wed, 21 Nov 2001 23:23:33 -
:: Jonathan M. Hollin [EMAIL PROTECTED] wrote:
::
:: 42: tie %session, 'Apache::Session::DBI',
:: 43: {DataSource = dbi:$db_driver:sessions:$db_address};
::
:: put $sid (session id: undef for fresh) after 'Apache::Session::MySQL'.
::
:: --
:: Tatsuhiko Miyagawa [EMAIL PROTECTED]
::
RE: Apache::Session Problem -- Addendum
At 10:43 AM + 11/22/01, Jonathan M. Hollin wrote:
Thank you everyone for the quality of help I've so far received and your
rapid responses. However... :-(
At the rist of making a shameless plug, you can visit
http://www.kitebird.com/mysql-perl/ and grab the webdb
source distribution there. This accompanies the book
for which the aforementioned URL is the home site. Said
book has a chapter on sessions focusing on Apache::Session,
so you may find the example scripts useful for helping
you solve your problem.
My code now includes:
35: # Session handler...
36: my %session; undef my $session_id;
37: use Apache::Session::MySQL;
38: tie %session, 'Apache::Session::MySQL', $session_id,
39: { DataSource = 'dbi:mysql:sessions', UserName = 'db_user', Password
= 'secret' };
40: $session_id = session_id=$session{_session_id};;
I am using Apache-Session v1.54.
The above code generates the following error:
[Thu Nov 22 10:31:38 2001] [error] PerlRun: `Can't connect(
HASH(0xbdcf54)), no database driver specified and DBI_DSN env var not set at
E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36 (in cleanup)
Can't connect( HASH(0x47e2f14)), no database driver specified and DBI_DSN
env var not set at E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36'
So, as you can see, I've moved on a little - but still don't have a working
session handler. Any offers?
Note: I know how boring it is to keep reading the same thread - I'll drop
it if I don't solve this today.
Kindest regards,
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
:: -Original Message-
:: From: Tatsuhiko Miyagawa [mailto:[EMAIL PROTECTED]]
:: Sent: 22 November 2001 04:34
:: To: [EMAIL PROTECTED]
:: Cc: mod_perl Mailing List
:: Subject: Re: Apache::Session Problem -- Addendum
::
::
:: On Wed, 21 Nov 2001 23:23:33 -
:: Jonathan M. Hollin [EMAIL PROTECTED] wrote:
::
:: 42: tie %session, 'Apache::Session::DBI',
:: 43: {DataSource = dbi:$db_driver:sessions:$db_address};
::
:: put $sid (session id: undef for fresh) after 'Apache::Session::MySQL'.
::
:: --
:: Tatsuhiko Miyagawa [EMAIL PROTECTED]
::
Apache::Session Problem
Fellow Perl Mongers,
Can anyone help with my latest programming riddle?
I am trying to take advantage of the session-handling features of
Apache::Session. My program includes the following code (line numbers added
for clarity):
20: # Session handler (I)...
21: use Apache::Session::DBI;
[cut]
40: # Session handler (II)...
41: my %session;
42: tie %session, 'Apache::Session::DBI',
43: {DataSource = dbi:$db_driver:sessions:$db_address};
44: my $session_cookie = session_id=$session{_session_id};;
[cut]
The variables $db_driver and $db_address are imported from a small
configuration file that defines them as mysql and 192.168.0.201
respectively.
My program dies when called (via CGI under mod_perl) with an 500 Internal
Server Error with the following line appended to error.log:
[Wed Nov 21 22:25:12 2001] [error] PerlRun: `Can't locate object method
TIEHASH via package Apache::Session::DBI at
e:/apache/htdocs/shapeshifter/system/logon.cgi line 42.'
Platform: Win2K, Apache, mod_perl, MySQL...
Any suggestions (apart from quit programming and take up farming instead)?
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
Re: Apache::Session Problem
On Wed, 21 Nov 2001 22:49:46 -, Jonathan M. Hollin [EMAIL PROTECTED] said: Jonathan Fellow Perl Mongers, Jonathan Can anyone help with my latest programming riddle? Jonathan I am trying to take advantage of the session-handling Jonathan features of Apache::Session. My program includes the Jonathan following code (line numbers added for clarity): Jonathan 20: # Session handler (I)... Jonathan 21: use Apache::Session::DBI; Jonathan [..skip..] Jonathan Platform: Win2K, Apache, mod_perl, MySQL... Jonathan Any suggestions (apart from quit programming and take up Jonathan farming instead)? I'm not sure why your code doesn't work but why are you using such old Apache::Session? Take new Apache::Session which provides MySQL support via Apache::Session::MySQL. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/) TIV.net (http://tiv.net/) | | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Apache::Session Problem -- Addendum
Thanks to Ilya Martynov for his response...
I changed Apache::Session::DBI to Apache::Session::MySQL and tried
again. The following error graced my error log:
[Wed Nov 21 23:01:13 2001] [error] PerlRun: `Died at
E:/Apache/site/lib/Apache/Session/Generate/MD5.pm line 40.'
Looking at MD5.pm - line 39, 40 and 41 read as follows:
if ($session-{data}-{_session_id} !~ /^[a-fA-F0-9]+$/) {
die;
}
I adjusted line 40 to read:
die $session-{data}-{_session_id};
The error log now gets:
[Wed Nov 21 23:07:54 2001] [error] PerlRun: `HASH(0x48acc64) at
E:/Apache/site/lib/Apache/Session/Generate/MD5.pm line 40.'
Yikes!
Any ideas?...
[original email follows...]
Fellow Perl Mongers,
Can anyone help with my latest programming riddle?
I am trying to take advantage of the session-handling features of
Apache::Session. My program includes the following code (line numbers added
for clarity):
20: # Session handler (I)...
21: use Apache::Session::DBI;
[cut]
40: # Session handler (II)...
41: my %session;
42: tie %session, 'Apache::Session::DBI',
43: {DataSource = dbi:$db_driver:sessions:$db_address};
44: my $session_cookie = session_id=$session{_session_id};;
[cut]
The variables $db_driver and $db_address are imported from a small
configuration file that defines them as mysql and 192.168.0.201
respectively.
My program dies when called (via CGI under mod_perl) with an 500 Internal
Server Error with the following line appended to error.log:
[Wed Nov 21 22:25:12 2001] [error] PerlRun: `Can't locate object method
TIEHASH via package Apache::Session::DBI at
e:/apache/htdocs/shapeshifter/system/logon.cgi line 42.'
Platform: Win2K, Apache, mod_perl, MySQL...
Any suggestions (apart from quit programming and take up farming instead)?
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
Re: Apache::Session Problem -- Addendum
I changed Apache::Session::DBI to Apache::Session::MySQL and tried
again.
What's the version number of your Apache::Session? It should be 1.54.
42: tie %session, 'Apache::Session::DBI',
43: {DataSource = dbi:$db_driver:sessions:$db_address};
With Apache::Session::MySQL, the docs say you should be passing the user
name and password.
- Perrin
Re: Apache::Session Problem -- Addendum
On Wed, 21 Nov 2001 23:23:33 -
Jonathan M. Hollin [EMAIL PROTECTED] wrote:
42: tie %session, 'Apache::Session::DBI',
43: {DataSource = dbi:$db_driver:sessions:$db_address};
put $sid (session id: undef for fresh) after 'Apache::Session::MySQL'.
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
_session_id-problem with Apache::Session::Store::Postgres
Hi,
sorry, this is not exactly a mod_perl question but I hope somehow in the
wake of this issue.
Apache::Session::Store::Postgres problem:
After the initial login to my page, I define and tie a %session which
produces a _session_id that is totally different from what it stores in the
sessions-table. So the next time my page is started (given the _session_id
as a parameter) I get the error-message
Apache/Session/Store/Postgres.pm: Object does not exist in the data store
Does anybody know what might cause this strange behavior? I will add the
code I consider important. If you don't have any idea (or the time to think
about it) I would be grateful for some lines of code that show how you use
Apache::Session::Store::Postgres.
Thanks for your help, Chris
use Apache::Session::Postgres;
use Apache::Session::Store::Postgres;
sub session
{
my %session;
tie %session, 'Apache::Session::Postgres', undef, {DataSource =
dbi:Pg:$dbrz_name, UserName =$dbrz_ben, Password = $dbrz_pw, Commit =
1} || return (f, Es kann im Moment keine neue Sizung angelegt werden.,
);
$session{bildrec} = [$_[1]];
$session{rz_benutzername} = $_[2];
return (s, , \%session);
}
##
Apache::Session WindowsNT File Locking problems
Hi, I'm using the precompiled binaries of Apache 1.3.20 + mod_perl on WinNT. I have grabbed Apache::Session 1.54 and nmake test fails at 99dbfile.t. The test routine basically hangs, and the culprit is in one of the last lines: tied(%$s)-delete; It seems to be some kind of file locking problem. I stepped through the code and I seem to have a problem with Autoloader loading Fcntl. Has anyone else experienced this, and could perhaps suggest a way to resolve this? Thanks. Chui Tey Software Engineer Advanced Data Integration PO Box 660 Spring Hill QLD 4004 AUSTRALIA Ph:07 3250 5300 Fax: 07 3250 5399 [mailto: [EMAIL PROTECTED]]
Re: ANN/RFC: Apache::Session::Generate variants
If you have other things on your mind, that's fine. That's why I suggested you should consider letting someone else maintain it. I know I'm not the only person frustrated by the current state of affairs. My solution to this problem is, that I have created a package named Apache::SessionX which subclasses Apache::Session and contains all the eXtentsion I need (most of them for Embperl, but they are also usefull outside of Embperl). This also contains a replacement for Apache::Session::Flex which can be configured via Makefile.PL and make test is testing if this really works on the system. The main point why I wrote this is, that Jeff doesn't like to have some of the functionality in the Apache::Session base class and I can bugfix and maintain it myself, without waiting for the next release of Apache::Session (there are also some ways to subsubclass Apache::Session::x:y packages build in) It is currently available from ftp://ftp.dev.ecos.de/pub/perl/session/ and will be soon released to CPAN Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: ANN/RFC: Apache::Session::Generate variants
On Fri, 12 Oct 2001, Gerald Richter wrote: If you have other things on your mind, that's fine. That's why I suggested you should consider letting someone else maintain it. I know I'm not the only person frustrated by the current state of affairs. My solution to this problem is, that I have created a package named Apache::SessionX which subclasses Apache::Session and contains all the eXtentsion I need (most of them for Embperl, but they are also usefull outside of Embperl). This also contains a replacement for Apache::Session::Flex which can be configured via Makefile.PL and make test is testing if this really works on the system. See, Gerald is a smart fellow, and I like that he never threatened to take over my modules. -jwb
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001 01:06:33 -0500 (CDT) Dave Rolsky [EMAIL PROTECTED] wrote: Jeff, if you're still maintaining this package it'd be nice to put out a new release. If not, it'd be good to give it to someone else. Hell, I'll volunteer if no one more interested comes along. I don't have any big plans for it but I can at least integrate patches and such. Apache::Session is in use in a lot of places and it would be good to have an active maintainer. ++1. And I don't mind taking over, if nobody else wants to. -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Apache::Session 1.54 released
Apache::Session 1.54, also know as the you impatient bastards release, has been uploaded to CPAN. Changes in this release include: Fix ID validation in Flex Move from MD5 to Digest::MD5 Include new generators ModUniqueId and ModUsertrack -jwb
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001, Jeffrey W. Baker wrote: Well, you guys are touchy lot! My releases are no less frequent than releases of DBI or even mod_perl. So just chill out, I sometimes have other things on my mind. I don't know about touchy so much as frustrated. Apache::Session is very widely used but it doesn't feel well supported. Comparing it to DBI or mod_perl seems a bit silly. It is not as widely used as either and is far less complex. My big concern is that there is a fatal error in Apache::Session::Flex that makes it completely unusable. You've known about this for at least 9-12 months but you haven't bothered to release a simple bugfix release for it. Its a 3-4 line change! The only way around it is to constantly patch my local copies or use a hack work-around code which subclasses Flex to fix the populate method. This is stupid. I don't really want to reinvent the wheel or tell people not to use Apache::Session, but its getter harder to avoid either. If you have other things on your mind, that's fine. That's why I suggested you should consider letting someone else maintain it. I know I'm not the only person frustrated by the current state of affairs. -dave /*== www.urth.org We await the New Sun ==*/
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001, Dave Rolsky wrote: On Thu, 11 Oct 2001, Jeffrey W. Baker wrote: Well, you guys are touchy lot! My releases are no less frequent than releases of DBI or even mod_perl. So just chill out, I sometimes have other things on my mind. I don't know about touchy so much as frustrated. Apache::Session is very widely used but it doesn't feel well supported. Comparing it to DBI or mod_perl seems a bit silly. It is not as widely used as either and is far less complex. My big concern is that there is a fatal error in Apache::Session::Flex that makes it completely unusable. You've known about this for at least 9-12 months but you haven't bothered to release a simple bugfix release for it. Its a 3-4 line change! Then package it up, send me the tarball, and I'll upload it to CPAN. Repeatedly sending me patches isn't any more likely to get me to pay attention to it. Regarding Flex, nobody uses it. It is for debugging. If you have a particular variant of Flex that you use all the time (very likely), you can code up a 6-line module to make a real implementation like all the other session modules. Flex is for debugging, period. Version 1.54 is uploaded to CPAN so go nuts. -jwb
ANN/RFC: Apache::Session::Generate variants
Here is Apache::Session::Generate::* variants, which especially uses Apache standard C-modules. Apache::Session::Generate::ModUniqueId http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.tar.gz http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.html uses mod_unique_id for session id. Apache::Session::Generate::ModUsertrack http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.tar.gz http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.html uses mod_usertrack's cookie for session id. Suggestions patches are welcome. Thanks. -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: ANN/RFC: Apache::Session::Generate variants
Here is Apache::Session::Generate::* variants, which especially uses Apache standard C-modules. Apache::Session::Generate::ModUniqueId http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.ta r.gz http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.ht ml uses mod_unique_id for session id. Apache::Session::Generate::ModUsertrack http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.t ar.gz http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.h tml uses mod_usertrack's cookie for session id. This is great! Good work. One less piece to write when getting a new project started... - Perrin
Re: ANN/RFC: Apache::Session::Generate variants
These are now on CPAN, which I've forgotten to mention. Note that if you try to use these modules functionality, Apache::Session::Flex should be patched with one included in both tarballs. Thanks. On Thu, 11 Oct 2001 01:30:29 +0900 Tatsuhiko Miyagawa [EMAIL PROTECTED] wrote: Here is Apache::Session::Generate::* variants, which especially uses Apache standard C-modules. Apache::Session::Generate::ModUniqueId http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.tar.gz http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.html uses mod_unique_id for session id. Apache::Session::Generate::ModUsertrack http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.tar.gz http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.html uses mod_usertrack's cookie for session id. -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001, Tatsuhiko Miyagawa wrote: Note that if you try to use these modules functionality, Apache::Session::Flex should be patched with one included in both tarballs. I sent a patch to Jeffrey last week or such that (I imagine) covers the same thing. -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001, Tatsuhiko Miyagawa wrote: Here is Apache::Session::Generate::* variants, which especially uses Apache standard C-modules. Apache::Session::Generate::ModUniqueId http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.tar.gz http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.html uses mod_unique_id for session id. Cool. Apache::Session::Generate::ModUsertrack http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.tar.gz http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.html uses mod_usertrack's cookie for session id. Don't do that! mod_usertrack is not meant to be used for secure session ids. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: ANN/RFC: Apache::Session::Generate variants
On Wed, 10 Oct 2001 17:23:04 -0700 (PDT) Ask Bjoern Hansen [EMAIL PROTECTED] wrote: Apache::Session::Generate::ModUsertrack http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.tar.gz http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.html uses mod_usertrack's cookie for session id. Don't do that! mod_usertrack is not meant to be used for secure session ids. I know, I know! just an example of using *already tracked* cookie for newly generated sessions. My another plan is to release my session id tracking modules, which Apache::Session doesn't do. -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: ANN/RFC: Apache::Session::Generate variants
On Wed, 10 Oct 2001 17:22:23 -0700 (PDT) Ask Bjoern Hansen [EMAIL PROTECTED] wrote: Note that if you try to use these modules functionality, Apache::Session::Flex should be patched with one included in both tarballs. I sent a patch to Jeffrey last week or such that (I imagine) covers the same thing. Wow, I did almost half a year ago :-) http://aspn.activestate.com/ASPN/Mail/Message/modperl/532294 -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001, Tatsuhiko Miyagawa wrote: Wow, I did almost half a year ago :-) http://aspn.activestate.com/ASPN/Mail/Message/modperl/532294 Yeah, and I think I sent one a year ago, at least. Jeff, if you're still maintaining this package it'd be nice to put out a new release. If not, it'd be good to give it to someone else. Hell, I'll volunteer if no one more interested comes along. I don't have any big plans for it but I can at least integrate patches and such. Apache::Session is in use in a lot of places and it would be good to have an active maintainer. -dave /*== www.urth.org We await the New Sun ==*/
Re: Apache::ASP - using Apache::Session
Jindo Soul wrote:
Hi!
I recently made a decision to adopt Apache::ASP as the template tool for my site.
The only thing I'd like to find out is whether or not Apache::ASP works with
Apache::Session. I read from an online article
http://perl.apache.org/features/tmpl-cmp.html that Apache::ASP can be hookied up to
Apache::Session. However, I just could not find the instruction on how this can and
should be done. Am I mistaken or have I missed something in the online docs?
Note the Apache::ASP mailing list is now at: [EMAIL PROTECTED]
Subscribe by sending an email to [EMAIL PROTECTED]
Integration of Apache::Session is similar to other environments,
except where you put the code. In Apache::ASP, you can put it
in global.asa Script_OnStart to get run every time, then you
can init the session to look like the ASP $Session.
The only differences are you don't get the ASP API around $Session,
like session management with garbage collection/timeouts, events,
or other API calls like Lock(), Abandon(), SessionID().
Also, without using ASP session, you won't get to use
SessionQueryParse cookieless sessions either.
Here is some untested code that you could start with
for using Apache::Session with MySQL:
# in httpd.conf, turn off $Application, $Session
PerlSetVar NoState 1
# in global.asa
use Apache::Session::MySQL;
sub Script_OnStart {
# ... init mysql dbh before
my $id = $Request-Cookies(SESSION_ID);
tie %hash, 'Apache::Session::MySQL', $id, { Handle = $dbh, LockHandle = $dbh };
if($id ne $hash{_session_id}) {
$Response-Cookies(SESSION_ID, $hash{_session_id});
}
$Session = \%hash;
$Server-RegisterCleanup(sub { untie (%$Session) }); }
}
--Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Apache::ASP - using Apache::Session
Hi! I recently made a decision to adopt Apache::ASP as the template tool for my site. The only thing I'd like to find out is whether or not Apache::ASP works with Apache::Session. I read from an online article http://perl.apache.org/features/tmpl-cmp.html that Apache::ASP can be hookied up to Apache::Session. However, I just could not find the instruction on how this can and should be done. Am I mistaken or have I missed something in the online docs? Thanks for your input. Cheers, Jindo
RFC: Apache::Session::CacheAny
Announcing the Adapter module which provides a way to use
Cache::Cache subclasses as Apache::Session storage implementation.
http://bulknews.net/lib/archives/Apache-Session-CacheAny-0.01.readme
http://bulknews.net/lib/archives/Apache-Session-CacheAny-0.01.tar.gz
Any suggestions are welcome. Thanks.
--
NAME
Apache::Session::CacheAny - use Cache::* for Apache::Session storage
SYNOPSIS
use Apache::Session::CacheAny;
tie %session, 'Apache::Session::CacheAny', $sid, {
CacheImpl = 'Cache::FileCache',
};
tie %size_aware_session, 'Apache::Session::CacheAny', $sid, {
CacheImpl= 'Cache::SizeAwareFileCache',
Namespace= 'apache-session-cacheany',
DefaultExpiresIn = '2 hours',
AutoPurgeOnGet = 0,
AutoPurgeOnSet = 1,
MaxSize = 10_000,
};
DESCRIPTION
Apache::Session::CacheAny is a bridge between Apache::Session and
Cache::Cache. This module provides a way to use Cache::Cache subclasses
as Apache::Session storage implementation.
ARGUMENTS
You must specify class name of Cache::Cache implementation (like
Cache::SharedMemoryCache) in arguments to the constructor. See the
Apache::Session::Store::CacheAny manpage for details about other
optional arguments.
NOTE
Apache::Session::CacheAny uses Apache::Session::Lock::Semaphore as its
locking scheme. You can use Apache::Session::Flex to change that.
AUTHOR
Tatsuhiko Miyagawa [EMAIL PROTECTED]
This library is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
SEE ALSO
the Apache::Session manpage, the Cache::Cache manpage
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: RFC: Apache::Session::CacheAny
Tatsuhiko Miyagawa wrote: Announcing the Adapter module which provides a way to use Cache::Cache subclasses as Apache::Session storage implementation. Hmmm... Don't take this the wrong way, but what's the purpose of this? Apache::Session does very little beyond what Cache::Cache does. In fact, the only things I can think of are the tied interface, which is slower than methods and often confuses people who make updates deep within the structure that don't trigger a save, and the ID generation, which is really just a stub and needs to be replaced for any serious project. Also, why bother with Apache::Session::Lock::Semaphore at all? Cache::Cache already provides atomic updates. You should be able to use NullLocker with the same level of safety. - Perrin
Re: RFC: Apache::Session::CacheAny
Perrin Harkins writes: Tatsuhiko Miyagawa wrote: Announcing the Adapter module which provides a way to use Cache::Cache subclasses as Apache::Session storage implementation. Hmmm... Apache::Session does very little beyond what Cache::Cache does. In fact, the only things I can think of are the tied interface, which is slower than methods and often confuses people who make updates deep within the structure that don't trigger a save, and the ID generation, which is really just a stub and needs to be replaced for any serious project. [ preface: if there were a [EMAIL PROTECTED] list, I think this discussion would be better received there. can someone make such a list? ] Above and beyond the efficiency issues you discuss above, could you comment on what Apache::Session would need to be useful in a serious project? I have found it very useful in conjunction with CGI::Cookie to maintain state between forms. I mean, as far as I can see, it does one job and does it well with no perceived shortcomings in my eyes. But evidently something in your experiences leads you to other conclusions. And I would like to hear about this.
Re: RFC: Apache::Session::CacheAny
princepawn wrote: Above and beyond the efficiency issues you discuss above, could you comment on what Apache::Session would need to be useful in a serious project? I was commenting specifically on the ID generation. The algorithm supplied does not guarantee unique IDs, especially when you have a cluster of machines. The design of Apache::Session makes it possible to drop in your own replacement for ID generation, which is what you should do if you're building a large-scale production system. Last time I needed to deal with this I used mod_unique_id as my starting point, which does generate unique IDs across a cluster. - Perrin
Re: RFC: Apache::Session::CacheAny
On Sun, 09 Sep 2001 15:24:14 -0700 Perrin Harkins [EMAIL PROTECTED] wrote: Announcing the Adapter module which provides a way to use Cache::Cache subclasses as Apache::Session storage implementation. Hmmm... Don't take this the wrong way, but what's the purpose of this? To glue Cache::Cache with Apache::Session. That's all :-) Apache::Session does very little beyond what Cache::Cache does. In fact, the only things I can think of are the tied interface, which is slower than methods and often confuses people who make updates deep within the structure that don't trigger a save, and the ID generation, which is really just a stub and needs to be replaced for any serious project. Cache::Cache is a cache interface for any key-value pairs with optioinal automatic expire purge. Apache::Session is a framework for persisntent hash data with unique identifier and automatic serialiization/deserialization for hash. Why not combine these two? That's all what this module does. Also, why bother with Apache::Session::Lock::Semaphore at all? Cache::Cache already provides atomic updates. You should be able to use NullLocker with the same level of safety. Cache::Cache ensures file-based atomic update. But IMHO it's not enough for Apache::Session's session transactions, which should be done exclusively. Session data would get logically inconsistent when there are multiple concurrent requests with same one session id. Off course, you can change that to adopt A::S::Lock::Null with A::S::Flex. -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: RFC: Apache::Session::CacheAny
Tatsuhiko Miyagawa wrote: Cache::Cache is a cache interface for any key-value pairs with optioinal automatic expire purge. Apache::Session is a framework for persisntent hash data with unique identifier and automatic serialiization/deserialization for hash. To me, they both look like persistent hashes. Apache::Session assumes you will be storing a serialized hash in each hash value, and that it will generate IDs for keys if you don't supply one, but otherwise they're about the same. Why not combine these two? That's all what this module does. Okay. Just wondered if I was missing something. Cache::Cache ensures file-based atomic update. But IMHO it's not enough for Apache::Session's session transactions, which should be done exclusively. Session data would get logically inconsistent when there are multiple concurrent requests with same one session id. Apache::Session uses shared read locks, so I think you can still have problems there. It doesn't gurantee an atomic read-change-modify. - Perrin
Re: RFC: Apache::Session::CacheAny
On Sun, 09 Sep 2001 18:33:11 -0700
Perrin Harkins [EMAIL PROTECTED] wrote:
To me, they both look like persistent hashes. Apache::Session assumes
you will be storing a serialized hash in each hash value, and that it
will generate IDs for keys if you don't supply one, but otherwise
they're about the same.
You're right. The (slight) difference you mention is all that this
module does.
Cache::Cache ensures file-based atomic update. But IMHO
it's not enough for Apache::Session's session transactions, which
should be done exclusively. Session data would get logically
inconsistent when there are multiple concurrent requests with same
one session id.
Apache::Session uses shared read locks, so I think you can still have
problems there. It doesn't gurantee an atomic read-change-modify.
Forgot to mention 'Transaction = 1' argument. Thanks for fixing
me.
In fact, the storage model I heavily use is A::S::Store::MySQL,
whick locking scheme is *always* exclusive.
Now, without Transaction = 1 argument, there is no need to use
locking scheme for preventing corrupted data update, because
Cache::Cache already ensures it, as you wrote.
Should I make Apache::Session::Lock::Cache, using Semaphore or
File only in case of Transacton mode?
package Apache::Session::Lock::Cache;
use strict;
use base qw(Apaache::Session::Lock::Semaphore);
sub acquire_read_lock { 1 }
sub release_read_lock { 1 }
sub acquire_write_lock {
my($self, $session) = @_;
if ($session-{args}-{Transaction}) {
$self-SUPER::acquire_write_lock($session);
}
}
# blah, blah
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Apache::Session::File and free memory weirdness
Hi All - I'm running Apache, mod_perl and HTML::Mason on Solaris 2.6, and using Apache::Session::File for session management. I've been monitoring free memory as reported by top, and I'm seeing some behavior that is totally baffling me. (If you're interested, there's a graph at: http://www.furph.com/graph.png) Here's the scenario: Around 6 AM, when things are relatively quiet, the graph shows about 1.3GB free memory (out of 4GB total). As traffic picks up during the course of the day, free memory drops to about 300MB by 3 or 4 PM. So far so good, no big surprise - there's a lot more httpd processes running so you'd expect more memory in use. Odd thing #1: As it gets into evening time, load on the machine drops off and there are fewer httpd children running, but I am not seeing free memory return to that 1.3GB level. At most it comes back up to 400MB or so. I don't think the httpd children are hanging on to memory, because they cycle through pretty quickly - MaxRequestsPerChild is set to 512 and none of the processes are ever more than a couple minutes old when I look in. Is there any reason to think the parent httpd process would hang on to anything? Odd thing #2: (This part seems most bizarre to me.) At 5:15 AM, we run a Perl script that finds and deletes Apache::Session::File session and lock files that are older than 28 days. Usually there are about 50,000 old files that get deleted out of about 2,300,000 total. Almost immediately, free memory on the machine jumps back up to 1.3GB. What's up with that? If I run the script during the middle of the day, when things are busier, I still see the free memory jump up although not all the way to 1.3GB - maybe to 800MB or so. Because of the rate the httpd children cycle, I don't think it's possible any of them could be holding open filehandles to session files that haven't changed for 28 days. Is there something weird about the way top reports free memory? The numbers I get seem consistent with the free column from vmstat. Why would deleting a bunch of files free up 1GB of memory? Any ideas or explanations would be much appreciated! Thanks! Larry Leszczynski [EMAIL PROTECTED]
Re: Apache::Session::File and free memory weirdness
Odd thing #1: As it gets into evening time, load on the machine drops off and there are fewer httpd children running, but I am not seeing free memory return to that 1.3GB level. At most it comes back up to 400MB or so. I don't think the httpd children are hanging on to memory, because they cycle through pretty quickly - MaxRequestsPerChild is set to 512 and none of the processes are ever more than a couple minutes old when I look in. Is there any reason to think the parent httpd process would hang on to anything? I have noticed that over time the new processes will spawn with less memory shared. I'm not sure exactly why this is, but it does seem to happen. A nightly complete restart of the server will reset things, but you may not have that option. Odd thing #2: (This part seems most bizarre to me.) At 5:15 AM, we run a Perl script that finds and deletes Apache::Session::File session and lock files that are older than 28 days. Usually there are about 50,000 old files that get deleted out of about 2,300,000 total. Almost immediately, free memory on the machine jumps back up to 1.3GB. What's up with that? Sounds like you're counting the buffers and cache in your used memory. Depending on what OS you're on, you may want to look at a tool other than top. The memory used for buffers and cache will be available to applications if they need it. - Perrin
Re: Apache::Session::File and free memory weirdness
Perrin Harkins wrote: Odd thing #1: As it gets into evening time, load on the machine drops off and there are fewer httpd children running, but I am not seeing free memory return to that 1.3GB level. At most it comes back up to 400MB or so. I don't think the httpd children are hanging on to memory, because they cycle through pretty quickly - MaxRequestsPerChild is set to 512 and none of the processes are ever more than a couple minutes old when I look in. Is there any reason to think the parent httpd process would hang on to anything? I have noticed that over time the new processes will spawn with less memory shared. I'm not sure exactly why this is, but it does seem to happen. A nightly complete restart of the server will reset things, but you may not have that option. I have noticed this also. I have a theory about its cause, but I haven't had the free time to hack with it yet. My theory is that when the VM subsystem swaps pages of the mod_perl parent process, those pages become forever unshared (even after they return to memory from swap). So I was going to test the mlockall() Linux system call to see if it made a difference. (Search the archives for mlockall). However, I am using the Linux platform - the VM behavior may be totally different on Solaris. If anyone else has some time to play with mlockall() on Linux, I'd like to know the results. It'll be a few more weeks till I get a chance. -Adi
Apache::Session not updating session
I really hope this isn't a FAQ, but I've lost more hair over this problem than I really should have, which is why I'm here. I'm using Apache::Session::File, and am setting a cookie for my sessionid, and my code is currently running in plain-old CGI mode (one of the libraries I'm using keeps segfaulting under mod_perl for some strange reason). When I visit the CGI, it successfully creates the session file in the /tmp directory, and all subsequent accesses to the page successfully load the session information from the right file on disk. However, my problem is that any value I set in my session is never updated on disk. I have tried explicitly calling tied(%session)-save and delete, to no avail. Permissions look good, the disk isn't full, and obviously it was able to access the disk in the first place since it was able to write the session file to disk. I'm about to go crazy here, since my application is working with the exception of this crucial piece. Any help anyone can provide would be greatly appreciated. System config: Redhat 7.1, with stock Apache/mod_perl RPMs. Stock RH7.1 Perl. Apache::Session v1.53 -man Michael A Nachbaur
