Re: Apache::Session permissions problem
On Saturday, Sep 13, 2003, at 09:22 America/Denver, Perrin Harkins wrote: I found a pretty useful article at http://www.linuxjournal.com/article.php?sid=4143 on how to use Apache::Session with Mason. I'm afraid that is not a very good article. It's out of date, and shows poor error handling. If you want to use sessions with Mason, you should be using the session handler that Mason provides. That is available on CPAN and is supported on the Mason list. Beggars can't be choosers, and all that, but would you mind telling me what handler you're talking about? I looked around for session handling and Mason, and that article was the best one I found in terms of explaining how it worked and how to use it. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. How can I know this? The documentation for Apache::Session::DBIStore (which A::S::DBI refers to) doesn't say anything about being obsolete or deprecated. Is there an archive of received wisdom somewhere I should be checking to validate articles like the one I found? You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. How? I never asked for IPC locking; it somehow snuck in. It's not particularly obvious from the documentation I can find that it's going to be used, or how to select alternative methods. I installed Apache::Session from CPAN, and the docs refer to PosixFileLocker SysVSemaphoreLocker and NullLocker, but no perldocs for those modules are on my system. I'm honestly trying to figure out how I can draw those conclusions for myself, so I'm not stuck asking this list about them. Suggestions are more than welcome; I'm not quite sure how Session::SysVSempaphoreLocker got involved in the first place, since I don't explicitly reference it. Apache::Session::DBI uses it for locking. 'perldoc Apache::Session::DBI' says it uses A::S::PosixFileLocker, not A::S::SysVSemaphoreLocker. Are the docs wrong, or the code? -=Eric
Re: Apache::Session permissions problem
Eric, Sorry if I came off overly critical. Many people have had problems trying to use Mason with Apache::Session because of that article. This is why on the Mason website the link to that article describes it as outdated and steers people to newer documentation. (It probably should also steer them to the new handler...) Eric Schwartz wrote: Beggars can't be choosers, and all that, but would you mind telling me what handler you're talking about? I looked around for session handling and Mason, and that article was the best one I found in terms of explaining how it worked and how to use it. Did you look on the Mason site, http://masonhq.com/? That's the best place to find information on Mason. A search for session on that site includes a reference to MasonX::Request::WithApacheSession, available from CPAN. This is mentioned in the administrator's manual that comes with Mason. It's possible that you have an old version of Mason that predates this. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. How can I know this? The documentation for Apache::Session::DBIStore (which A::S::DBI refers to) doesn't say anything about being obsolete or deprecated. Is there an archive of received wisdom somewhere I should be checking to validate articles like the one I found? The latest Apache::Session on CPAN is version 1.54, released in October 2001. The last release that included a module called Apache::Session::DBI was version 1.03, released two years earlier. I'm not certain what CPAN.pm would do if you told it to install Apache::Session::DBI. It might install the old one, which would be very unfortunate. Is that how you installed it? You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. How? By using Apache::Session::Flex. The configuration for MasonX::Request::WithApacheSession also lets you do this. It's not particularly obvious from the documentation I can find that it's going to be used, or how to select alternative methods. Look at the source and you'll see it. It's all much clearer in the more recent release though. I installed Apache::Session from CPAN, and the docs refer to PosixFileLocker SysVSemaphoreLocker and NullLocker, but no perldocs for those modules are on my system. The Apache::Session::PosixFileLocker and Apache::Session::SysVSemaphoreLocker modules are included with Apache::Session (although both are obsolete and only part of the old version that you installed). They have no documentation, so perldoc will not find them. The later equivalents (Apache::Session::Lock::File) do have docs. 'perldoc Apache::Session::DBI' says it uses A::S::PosixFileLocker, not A::S::SysVSemaphoreLocker. Are the docs wrong, or the code? The docs are wrong. You can see it refers to the semaphore locker if you look at the source. Basically, you stumbled across an old article that referred to an obsolete version of Apache::Session, and all of your problems stem from that. If you get a later version and check out the Mason handler and the newer documentation on masonhq.com, I think it will all start to make sense to you. - Perrin
RE: Apache::Session permissions problem
I'm afraid that is not a very good article. It's out of date, ... Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. I stumbled upon this problem quite a few times. Trying to get the hang of using cookies for authentication and sessions there are tons of modules and (a bit less...) articles, but they all seem outdated or simply not useful. So I build something myself, but am not quite sure this was the way to go. I had the same experience when (OT, sorry) I looked into things about using XML in combination with (mod_)perl. Most of the articles are rather old and I have no clue if they are outdated. Here as well I made some choices of my own, still thinking I am at least reinventing part of the wheel. Is there a, or are there initiatives to keep an 'accurate' document repository? I personally like perl.apache.org as a starting point, but it is quite restricted to mod_perl and mod_perl alone. (This is not meant as a rude remark!). Should and could this be broader containing links to interesting articles on 'well known subjects'? Should we then need som (continuous) reviewing and rating mechanism to separate the good from the bad? Or is Google still the way to go? --Frank PS: Apache::Session::DBI might be ancient, when I did some research for this mail I stumbled upon http://perl.apache.org/docs/1.0/guide/snippets.html#An_example_of_using_Apac he__Session__DBI_with_cookies. Perhaps it is a good beginning to try to keep/get outdated and ancient stuff from Our Main Source of Information?
RE: Apache::Session permissions problem
Is there a, or are there initiatives to keep an 'accurate' document repository? The field of knowledge is too broad for any one person to maintain, especially since the main people who maintain the site docs are quite busy building mod_perl 2. This is why we count on individuals stepping up and sending in corrections to outdated things they find in the docs. I personally like perl.apache.org as a starting point, but it is quite restricted to mod_perl and mod_perl alone. (This is not meant as a rude remark!). Should and could this be broader containing links to interesting articles on 'well known subjects'? There are quite a few links to other sources on perl.apache.org. My basic rule of thumb is to start with the most specific source of documentation. In your case, since you are trying to use Mason, you should look on the Mason site. There you would have found a note that the article you read is outdated, and a link to the current docs:http://masonhq.com/user/adpacifico/ApacheSessionMason.html PS: Apache::Session::DBI might be ancient, when I did some research for this mail I stumbled upon http://perl.apache.org/docs/1.0/guide/snippets.html#An_example_of_using_Apac he__Session__DBI_with_cookies. Perhaps it is a good beginning to try to keep/get outdated and ancient stuff from Our Main Source of Information? Yes, it would definitely be good to update or remove that snippet. A patch would certainly be appreciated. - Perrin
Re: Apache::Session permissions problem
I found a pretty useful article at http://www.linuxjournal.com/article.php?sid=4143 on how to use Apache::Session with Mason. I'm afraid that is not a very good article. It's out of date, and shows poor error handling. If you want to use sessions with Mason, you should be using the session handler that Mason provides. That is available on CPAN and is supported on the Mason list. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. Permission denied at /Library/Perl/Apache/Session/SysVSemaphoreLocker.pm line 46. Which seems to indicate it isn't. I STFW, and found several people who seem to have had the same problem I have, but the solutions proffered involve ipcs and ipcrm, which don't exist on my Mac OS X 10.2.6 system. You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. Suggestions are more than welcome; I'm not quite sure how Session::SysVSempaphoreLocker got involved in the first place, since I don't explicitly reference it. Apache::Session::DBI uses it for locking. - Perrin
Re: Apache::Session and pnotes
On Tue, 2 Sep 2003 20:21:45 +0200 Xavier Noria [EMAIL PROTECTED] wrote: On Tuesday 02 September 2003 07:28, Perrin Harkins wrote: Sorry, I don't understand what you're saying here. What you should be doing is fetching the session once, putting it in pnotes, and getting it from pnotes for the rest of the request. I am sorry, I'll try to reword it. Let's assume a new user comes to the website. We set up a session for him and put the session id in a cookie to be sent in the response. As you know, somewhere in the request cycle of that particular request Apache::Session::Oracle stores the session in the database. When later that very user comes back to the website with a valid session id in the cookie, one reads the session from the database. The problem I am facing is that if the session is stored in pnotes() it doesn't end up in the database. When the user comes back that id corresponds to no row in the sessions table. Hi Xavier, If you want a transaparent session management you could also look Apache::SessionManager mod_perl extension. No extra code to write but a few lines to add in httpd.conf or .htaccess.file :-) by - Enrico -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
Sorry, I missed this message until now... On Tue, 2003-09-02 at 14:21, Xavier Noria wrote: Let's assume a new user comes to the website. We set up a session for him and put the session id in a cookie to be sent in the response. As you know, somewhere in the request cycle of that particular request Apache::Session::Oracle stores the session in the database. It happens when the session object gets destroyed. The problem I am facing is that if the session is stored in pnotes() it doesn't end up in the database. When the user comes back that id corresponds to no row in the sessions table. Okay, the problem is not pnotes. The pnotes stuff gets cleared at the end of every request, so it would save then, after the user disconnects. Probably what's happening is that you have a scoping problem somewhere in your code that deals with pnotes and it is keeping the session object from going out of scope. One thing you can try is explicitly saving the session, using the method described in the Apache::Session documentation. If that works, it means you just have to find your scoping problem. Maybe you can locate it by removing code bit by bit until the problem goes away. If you can make a very short script that demonstrates the problem, you can post it here and we'll help you find it. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
Xavier Noria wrote:
It seems, however, that Apache::Session objects stop being stored when I
put the session in pnotes() with a code analogous to this:
Can you tell us more about the problem is? What do you see when you
take the session hash back out of pnotes?
my $r = Apache::Request-instance(shift);
No need to involve Apache::Request just for this. Your handler should
be getting $r passed to it.
tie my (%session), 'Apache::Session::Oracle', undef,
{Handle = $class-dbh(), Commit = 1};
$r-pnotes(session = \%session);
Show us the code you use to get it back.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session extra record not write to Mysql db.
James.Q.L wrote:
before i had three fields in table sessions : a_session,id,time in the DB.
Did you add code of your own to update the time column?
and updating table etc from the program was working just fine. however, after i added
one more
field (username) to the sessions table through phpmysql, updating it in the program
seems has no effect on the username record. no problem on others.
Do you understand what Apache::Session does? It simply use Storable to
turn the whole hash of values into a single binary chunk and stores it
all in the a_session field. It uses the id field to find the session
again. It will not update any other fields unles syou hack the code
yourself.
$session{'test'} = time();## this doesn't update 'test'
That updates the field test in the session, which is stored as part of
the column a_session in the database.
$session{'uname'} = $uname if $uname; ## this doesn't update 'uname'
Same as above -- it updates the uname value of the session.
$session{'time'} = time();## this updates 'time' record
But it doesn't update the time column in the database unless you hacked
the Apache::Session code to do that.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session extra record not write to Mysql db.
--- Perrin Harkins [EMAIL PROTECTED] wrote:
James.Q.L wrote:
before i had three fields in table sessions : a_session,id,time in the DB.
Did you add code of your own to update the time column?
no.
and updating table etc from the program was working just fine. however, after i
added one more
field (username) to the sessions table through phpmysql, updating it in the program
seems has no effect on the username record. no problem on others.
Do you understand what Apache::Session does? It simply use Storable to
turn the whole hash of values into a single binary chunk and stores it
all in the a_session field. It uses the id field to find the session
again. It will not update any other fields unles syou hack the code
yourself.
I read the doc of Apache::Session::Store::Mysql but there isn't much in it.
and i tried first to have a 'time' field in the sessions table. and it did get
updated. so that's why i thought the record get stored just like that.
and from my phpmysql, you can see the time record.
id a_session time unametest
0543f2dc8dd196c5adeb29f18113f88d 2003090122521800
and indeed as you said in record a_session it stores the session data. so if i
understand
correctly, i don't add _new_ column to the sessions table, instead i call
$session{'username'} =
'username' which add it to the column a_session.
$session{'time'} = time();## this updates 'time' record
But it doesn't update the time column in the database unless you hacked
the Apache::Session code to do that.
now i don't know why the time record gets updated. isn't it suppose to update the one
in
a_session?
one more question if you don't mind.
i know Apache::Session can't do session managerment directly. but i found out that
when a user
session timeout, the record also gone automatically.is tied(%session)-delete; delete
the session?
Thanks
Qiang
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session extra record not write to Mysql db.
$session{'time'} = time();## this updates 'time' record
But it doesn't update the time column in the database unless you hacked
the Apache::Session code to do that.
now i don't know why the time record gets updated. isn't it suppose to
update the one in
a_session?
I guess 'time' field gets updated because of it is 'timestamp' type, isn't
it?
MySQL has this type for automatically updated field with current date and
time (RTFM :)).
Best wishes,
Anton Permyakov.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session extra record not write to Mysql db.
On Tue, 2003-09-02 at 00:13, James.Q.L wrote:
--- Perrin Harkins [EMAIL PROTECTED] wrote:
Did you add code of your own to update the time column?
no.
Maybe you added the time column as an automatic timestamp column? There
is no time column in the schema described in the Apache::Session
documentation.
and from my phpmysql, you can see the time record.
id a_session time unametest
0543f2dc8dd196c5adeb29f18113f88d 2003090122521800
Is that a real column, or just a last-modified time that phpmysql adds
in somehow?
and indeed as you said in record a_session it stores the session data. so if i
understand
correctly, i don't add _new_ column to the sessions table, instead i call
$session{'username'} =
'username' which add it to the column a_session.
That's right.
i know Apache::Session can't do session managerment directly. but i found out that
when a user
session timeout, the record also gone automatically.is tied(%session)-delete;
delete the session?
Apache::Session has no concept of timeouts so it never deletes sessions,
but you can delete sessions manually with the delete method that you're
talking about.
By the way, you might find it easier to use CGI::Session. It works fine
with mod_perl, and it directly supports things like timeouts.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
On Tuesday 02 September 2003 07:46, you wrote:
(I am sorry I am not replying to the actual email, but to a forwarded
copy from my desktop at home.)
It seems, however, that Apache::Session objects stop being stored
when I put the session in pnotes() with a code analogous to this:
Can you tell us more about the problem is? What do you see when you
take the session hash back out of pnotes?
I have dumped the hash in a content handler and it seems to be OK.
my $r = Apache::Request-instance(shift);
No need to involve Apache::Request just for this. Your handler
should be getting $r passed to it.
Apache::Request is used because the authenticator handles login via
param(), and more handlers need the parameters afterwards.
tie my (%session), 'Apache::Session::Oracle', undef,
{Handle = $class-dbh(), Commit = 1};
$r-pnotes(session = \%session);
Show us the code you use to get it back.
When a request is received the session id is retrieved from a cookie.
The schema (with some irrelevant checks removed) would be this:
my %cookies = Apache::Cookie-fetch;
my $cookie = $cookies{COOKIE_NAME()};
my $session_id = $cookie-value;
my %session;
eval {
tie %session, 'Apache::Session::Oracle', $session_id,
{Handle = $class-dbh(), Commit = 1};
};
The eval block is there now because it seems Apache::Session::Oracle
dies if it cannot retrieve the session.
That code works all right if \%session is not stored in pnotes(), but if
it is put the session is not read back from the database and I have
checked from a database client that there is no new row written.
I am doing basic stuff with this, so if it sounds strange it is likely
that I doing something wrong.
-- fxn
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
On Tue, 2003-09-02 at 05:02, Xavier Noria wrote:
Can you tell us more about the problem is? What do you see when you
take the session hash back out of pnotes?
I have dumped the hash in a content handler and it seems to be OK.
Okay, then what is the problem that you're asking for help with here?
When a request is received the session id is retrieved from a cookie.
The schema (with some irrelevant checks removed) would be this:
my %cookies = Apache::Cookie-fetch;
my $cookie = $cookies{COOKIE_NAME()};
my $session_id = $cookie-value;
my %session;
eval {
tie %session, 'Apache::Session::Oracle', $session_id,
{Handle = $class-dbh(), Commit = 1};
};
Okay, but I was asking how you get it back from pnotes.
That code works all right if \%session is not stored in pnotes(), but if
it is put the session is not read back from the database and I have
checked from a database client that there is no new row written.
Sorry, I don't understand what you're saying here. What you should be
doing is fetching the session once, putting it in pnotes, and getting it
from pnotes for the rest of the request.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
On Tuesday 02 September 2003 07:28, Perrin Harkins wrote: Sorry, I don't understand what you're saying here. What you should be doing is fetching the session once, putting it in pnotes, and getting it from pnotes for the rest of the request. I am sorry, I'll try to reword it. Let's assume a new user comes to the website. We set up a session for him and put the session id in a cookie to be sent in the response. As you know, somewhere in the request cycle of that particular request Apache::Session::Oracle stores the session in the database. When later that very user comes back to the website with a valid session id in the cookie, one reads the session from the database. The problem I am facing is that if the session is stored in pnotes() it doesn't end up in the database. When the user comes back that id corresponds to no row in the sessions table. Is it better now? -- fxn -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session
Hi I might be missing the point but if you already are tracking with Apache::Session why not encrypt the session id before giving it to the user in the first place. You could store a public 'key' for the encryption in a cookie on the users machine. That way only that user can give you the right info to decode the session. If this sounds reasonable, you may want to check out Paul DuBois book MySQL and Perl for the Web ISBN 0-7357-1054-6. He outlines a method to encrypt the apache::session id. Mike - Original Message - From: Aleksandr Guidrevitch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: August 14, 2003 6:54 AM Subject: Apache::Session Hi, All Sorry, this post might be out of scope of this particular list, but still... don't punch me heavily :) I just think the people here might have met this problem while deploying big public applications. I use Apache::Session to identify logged in users. However, the users are allowed to post html (obviously with javascript) messages viewable by others. That could create an XSS vulnerability and allow to steal the sessions (cookies) from other users. Is it possible to uniquely identify the user by some attributes ? The only thing I consider now is IP, but what about proxies and NATs ? User Agent string could also be stolen via javascript. That means I tend to make stolen session ids non-reusable. Any thoughts ? Sincerely, Aleksandr Guidrevitch
Re: Apache::Session
Aleksandr, we had our own stripping methods. Just get the source for slashcode http://slashcode.com and look for Slash/Display/Display.pm: strip_paramattr = \strip_paramattr, Slash/Display/Display.pm: strip_urlattr = \strip_urlattr, Slash/Display/Display.pm: strip_anchor= \strip_anchor, Slash/Display/Display.pm: strip_attribute = \strip_attribute, Slash/Display/Display.pm: strip_code = \strip_code, Slash/Display/Display.pm: strip_extrans = \strip_extrans, Slash/Display/Display.pm: strip_html = \strip_html, Slash/Display/Display.pm: strip_literal = \strip_literal, Slash/Display/Display.pm: strip_nohtml= \strip_nohtml, Slash/Display/Display.pm: strip_notags= \strip_notags, Slash/Display/Display.pm: strip_plaintext = \strip_plaintext, and this'll give you an idea of what slashcode does to deal with it. Hope this helps, Patrick Aleksandr Guidrevitch wrote: Hi, All What have you used to stip out that stuff ? I've reviewied HTML::StripScripts, but it seems to be very slow. I've also considered HTML::Filter to do that but I'm also affraid that HTML::Parser is not the fastest thing on the earth, even though it will be invoked once during initial submission. Could you also advise on this safe subset of html you use ? Sincerely, Alex Patrick Galbraith wrote: Strip out stuff that could be problematic. This is what we did with Slash. We strip out javascript or any tag that can be problematic, or be used even to break the layout of the page. It'll make you're life much easier ;) Take this from someone who coded tons of features to ward off trolls! -- -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] 206.719.2461
Re: Apache::Session
Hi, All What have you used to stip out that stuff ? I've reviewied HTML::StripScripts, but it seems to be very slow. I've also considered HTML::Filter to do that but I'm also affraid that HTML::Parser is not the fastest thing on the earth, even though it will be invoked once during initial submission. Could you also advise on this safe subset of html you use ? Sincerely, Alex Patrick Galbraith wrote: Strip out stuff that could be problematic. This is what we did with Slash. We strip out javascript or any tag that can be problematic, or be used even to break the layout of the page. It'll make you're life much easier ;) Take this from someone who coded tons of features to ward off trolls!
Re: Apache::Session
Hi I do a few basic things that improve security - its still not strict security but What i do is store both the remote IP and the user agent HTTP parameters in the session when the session is created. Whenever a new request comes in with that session I check that those havent changed. If they havent I allow access and update the 'last access time' (for expiry) - if not they are logged out and the session closed. This means that any user disconnected from their ISP has to login again, which i consider acceptable. It also means that if they copy an url and paste it into another browser they will end up logged out, again it does not happen often and people should accept it as the price of security. It does mean that someone on the same proxy and using the same browser could still do something but that is already a lot fewer people. I also check referrer to make sure people are coming from a page that makes sense. If you wanted to be more sophisticated you could store where an user has been recently (the 5 last URLs maybe) and check that the referrer is one of them. If the referrer is not a page where the user has been then things are fishy and you log them out. If you need even better security there's ssl, or storing unique, random'challenge-response' style tokens into pages that have to be sent back on the next connection Probably many people on this list have more sophisticated systems in place. I'd be interested to know too :) Joelle Nebbe
Re: Apache::Session
Strip out stuff that could be problematic. This is what we did with Slash. We strip out javascript or any tag that can be problematic, or be used even to break the layout of the page. It'll make you're life much easier ;) Take this from someone who coded tons of features to ward off trolls! Aleksandr Guidrevitch wrote: Hi, All Sorry, this post might be out of scope of this particular list, but still... don't punch me heavily :) I just think the people here might have met this problem while deploying big public applications. I use Apache::Session to identify logged in users. However, the users are allowed to post html (obviously with javascript) messages viewable by others. That could create an XSS vulnerability and allow to steal the sessions (cookies) from other users. Is it possible to uniquely identify the user by some attributes ? The only thing I consider now is IP, but what about proxies and NATs ? User Agent string could also be stolen via javascript. That means I tend to make stolen session ids non-reusable. Any thoughts ? Sincerely, Aleksandr Guidrevitch -- -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] 206.719.2461
Re: Apache::Session
Aleksandr Guidrevitch said: ... Is it possible to uniquely identify the user by some attributes ? The only thing I consider now is IP, but what about proxies and NATs ? User Agent string could also be stolen via javascript. That means I tend to make stolen session ids non-reusable. Went through this many years ago and I assure you that there is 'no' proper heuristic for identifying that user. UserAgent fails when you have a building full of people with a standard install. IP fails with proxies - and even worse - through crappy isp's where each request appears to be chained through some different proxy. imho, you have to accept some level of insecurity. Make the walls higher. Use post, use cookies, make your session id's short lived, make heuristics for comparing temporaly close subsequent request's useragent/ip etc. Perhaps there's someone clever out there who has found a some chaotic fractal which will reveal the mac address from the combination of everything else, however besides this, I think it a no-winner. Well, good luck, Rafiq
Re: Apache::Session
On Thursday 14 August 2003 8:06 am, Joelle Nebbe wrote: What i do is store both the remote IP and the user agent HTTP parameters in the session when the session is created. Whenever a new request comes in with that session I check that those havent changed. So, you don't care about AOL users then? They can change IPs on every request as they get routed between proxies. I also check referrer to make sure people are coming from a page that makes sense. Not much of a barrier to anyone who cares enough to bother coding up a cross-site scripting attack. If you need even better security there's ssl, or storing unique, random'challenge-response' style tokens into pages that have to be sent back on the next connection That's an idea. You could try making every cookie good for only one use, and send a new one out every time. Ultimately though, I think the answer is that sites with sensitive information can't leave themselves open to CSS attacks. - Perrin
Re: Apache::Session::Lock::File hangs under Windows
PH On Mon, 2003-07-07 at 07:29, Andrew Alakozow wrote:
Apache::Session::Lock::File hangs under Windows if you try to remove
session or add data to existing session. This happenes because you
cannot flock($self-{fh}, LOCK_EX) if you already has
flock($self-{fh}, LOCK_SH) in Windows.
PH Under mod_perl 1, there is no need to use locking on Win32 since
PH mod_perl runs single-threaded there.
I write code that should work on both Unix and Win. More compatible libs I
use, less branching I need in my code. Now it's mod_perl 1, but I'll have to
move it to mod_perl 2 someday.
PH This patch might be useful for mod_perl 2 on Win32, but LOCK_UN is
PH tricky. Have you seen this?
http://perl.plover.com/yak/flock/samples/slide004.html
Apache::Session::Lock::File doesn't put any data in lock files.
IMHO, this lib should be patched or contain alarm about Windows, but it
shouldn't just hang. It was first time I've run perl -d on purpose. %)
BTW, 'clean' method of this model hangs as well.
aa29
Re: Apache::Session::Lock::File hangs under Windows
On Tue, 8 Jul 2003 10:26:54 +0400 Andrew Alakozow [EMAIL PROTECTED] wrote: Hi Andrew BTW, 'clean' method of this model hangs as well. Also Apache::Session::Lock::File (1.54) 'clean' method has a little bug in checking lockfiles last access time. See my post at: http://mathforum.org/epigone/modperl/plinfrargoo Since I've mailed this to the author with no response, I'll include the patch into my next release of Apache::SessionManager (A::S wrapper). by - Enrico
Re: Apache::Session::Lock::File hangs under Windows
On Mon, 2003-07-07 at 07:29, Andrew Alakozow wrote:
Apache::Session::Lock::File hangs under Windows if you try to remove
session or add data to existing session. This happenes because you cannot
flock($self-{fh},
LOCK_EX) if you already has flock($self-{fh}, LOCK_SH) in Windows.
Under mod_perl 1, there is no need to use locking on Win32 since
mod_perl runs single-threaded there. This patch might be useful for
mod_perl 2 on Win32, but LOCK_UN is tricky. Have you seen this?
http://perl.plover.com/yak/flock/samples/slide004.html
- Perrin
RE: Apache::Session and Postgres
Perrin Harkins wrote: On Mon, 2003-02-24 at 07:09, Grant McLean wrote: I get this error: Can't locate object method get_lock_manager via package Apache::Session::Postgres And indeed, that method does not seem to be defined in any of the modules which Apache::Session::Postgres inherits from. I don't see anything that calls that method anywhere in the Apache::Session distribution. Either you have some code doing it, or you have an old version. You should be running the 1.54 distribution. Thanks for the advice. I had installed 1.54 but must have had an old version lying around. Deleting lib/Apache/Session* and rerunning the make install fixed the problem. Thanks again Grant
Re: Apache::Session and Postgres
On Mon, 2003-02-24 at 07:09, Grant McLean wrote: I get this error: Can't locate object method get_lock_manager via package Apache::Session::Postgres And indeed, that method does not seem to be defined in any of the modules which Apache::Session::Postgres inherits from. I don't see anything that calls that method anywhere in the Apache::Session distribution. Either you have some code doing it, or you have an old version. You should be running the 1.54 distribution. - Perrin
Re: Apache::Session::File hangs
Axel Huizinga wrote: The following code hangs after reloading and the try to tie again the previously created session! WHY? ... use vars qw( $id $sID $lockDir %session $sessionDir ); The session variable has to go out of scope for the lock to be released. I know it seems like the untie should do it, but try making %session a lexical instead of a global. - Perrin
RE: Apache::Session
Carl Have you check the active perl site (http://www.activeperl.com) ? It may be available there -Original Message- From: Carl Holm [mailto:[EMAIL PROTECTED]] Sent: Thu 1/16/2003 9:12 PM To: [EMAIL PROTECTED] Cc: Subject: Apache::Session Hello, I am looking for a PPM version of Apache::Session for Perl (v5.8.0 built for MSWin32-x86-multi-thread) and Apache/2.0.43. Any pointers would be greatly appreciated. Thanks, Carl Holm [EMAIL PROTECTED] This message may contain proprietary or confidential company information. Any unauthorized use or disclosure is prohibited.
Re: Apache::Session
On Thu, 16 Jan 2003, Carl Holm wrote: Hello, I am looking for a PPM version of Apache::Session for Perl (v5.8.0 built for MSWin32-x86-multi-thread) and Apache/2.0.43. Any pointers would be greatly appreciated. Thanks, Carl Holm [EMAIL PROTECTED] I just put one up under http://theoryx5.uwinnipeg.ca/ppms/. However, some of the tests fail and/or hang under ActivePerl 8xx ... -- best regards, randy kobes
Re: Apache::Session::MySQL
Is this the correct list for help with Apache::Session::MySQL? This is a good list for it if you are using mod_perl. If you're using CGI, try one of the CGI resources instead, or stick with perlmonks.org. I just replied to your post there a few minutes ago. - Perrin
Re: Apache::Session::MySQL
Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. What do you think? Thanks, Richard. (I'll go see your reply in a min. Thank you!) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 11:49 AM Subject: Re: Apache::Session::MySQL Is this the correct list for help with Apache::Session::MySQL? This is a good list for it if you are using mod_perl. If you're using CGI, try one of the CGI resources instead, or stick with perlmonks.org. I just replied to your post there a few minutes ago. - Perrin
Re: Apache::Session::MySQL
Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? It's not true. The parent process runs as root in order to open port 80, but that's the same for CGI as well. The child processes that actually handle requests runs as whatever user you specify in httpd.conf (typically nobody). I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. If you have clean code (use strict and -w) that will run under mod_perl, you should definitely take advantage of the speed increase. Depending on what you're doing, it can make a really huge difference in performance. I do recommend that you fix your current Apache::Session problem first, before thinking about converting to mod_perl. - Perrin
Re: Apache::Session::MySQL
So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts, without using Mod_Perl, or do I have to use one or the other, only. Thank you, Richard. PS I just replied to the PerlMonks reply you did. Thank you. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 12:08 PM Subject: Re: Apache::Session::MySQL Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? It's not true. The parent process runs as root in order to open port 80, but that's the same for CGI as well. The child processes that actually handle requests runs as whatever user you specify in httpd.conf (typically nobody). I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. If you have clean code (use strict and -w) that will run under mod_perl, you should definitely take advantage of the speed increase. Depending on what you're doing, it can make a really huge difference in performance. I do recommend that you fix your current Apache::Session problem first, before thinking about converting to mod_perl. - Perrin
Re: Apache::Session::MySQL
At 01:25 PM 12/28/2002 -0600, Richard wrote: So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts, without using Mod_Perl, or do I have to use one or the other, only. Richard, Yes,you can still run regular cgi, as with MP you have to explicitly tell (via directives in httpd.conf) which files to process using MP handlers. My guess is if you are going to convert cgi scripts to run under MP, you are going to be iinterested in Apache::Registry. There is probably a ton of good info on apache.org and elsewhere about how to do this exactly. GV
Re: Apache::Session::MySQL
So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. Okay, that may be an issue because SuExec does not work with mod_perl. Each apache daemon can only run mod_perl processes as a single user, but that user can be any user you choose. You would never set them to run as root, because that would be a security problem. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts Yes, and you should still be able to run them with SuExec. As George said, there is quite a bit documentation on the perl.apache.org site that may help you. - Perrin
Re: Apache::Session::MySQL
Great, thank you guys! I am trying to first fix my Apache::Session problem before I open a whole new bag of candy :o) Thank you very much for your input, I am grateful! Richard. - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 2:32 PM Subject: Re: Apache::Session::MySQL So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. Okay, that may be an issue because SuExec does not work with mod_perl. Each apache daemon can only run mod_perl processes as a single user, but that user can be any user you choose. You would never set them to run as root, because that would be a security problem. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts Yes, and you should still be able to run them with SuExec. As George said, there is quite a bit documentation on the perl.apache.org site that may help you. - Perrin
Re: Apache::Session and user sessions
md wrote: My question is with regards to whether I need or should put the submitted data into the session as the user navigates the forms (to create an account). The user will be taken through three forms to create an account. So for instance, form one will ask the user to create a username, password, and provide an email address. Before moving on to form two (billing info), should I put this data in the session, or just go ahead and dump it in the database (after making any nec. checks), since I won't need the info until they actually login? Or should I collect all the info from all three screens by putting it in the session as the user traverses the forms and then put it all in the database at once? I'm currently using the first option. BTW, it is possible for a user to create a free account by hitting form one only, so no harm would come if something happened after form one. This is really a question of requirements. In systems where all information needs to be collected before a valid account can be created, you have to wait until the end to put it in the permanent tables. I usually don't store form input in the session because it leads to strange results if the user has multiple browser windows open on the site, but that may not be an issue for your application. Another question, while not mod_perl related (sorry:), is how to taint check input data like usernames, address fields and email addresses. All info is just put in the database, no unsafe system calls are run. I'm curious as to what characters to limit for usernames in particular. If you're using bind variables with DBI, there is no technical reason to restrict the characters at all. Just make sure you HTML-escape them whenever you display them on a page. - Perrin
Re: Apache::Session and user sessions
On Mon, 9 Dec 2002, Perrin Harkins wrote:
md wrote:
My question is with regards to whether I need or
should put the submitted data into the session as the
user navigates the forms (to create an account). The
user will be taken through three forms to create an
account. So for instance, form one will ask the user
to create a username, password, and provide an email
address. Before moving on to form two (billing info),
should I put this data in the session, or just go
ahead and dump it in the database (after making any
nec. checks), since I won't need the info until they
actually login? Or should I collect all the info from
all three screens by putting it in the session as the
user traverses the forms and then put it all in the
database at once? I'm currently using the first
option. BTW, it is possible for a user to create a
free account by hitting form one only, so no harm
would come if something happened after form one.
This is really a question of requirements. In systems where all
Agreed.
I have a golden rule for this:
if (( management are annoying and like to know about incomplete
registrations
||
you want one point of varifying input so that designers can
shove in as many intermediary pages as possible)
)
You don't have a ridiculous amount of fields to process )
{
place in session
}
else
{
shove in hiddens.
}
I wouldn't start populating your real tables until the registration is
complete since you may end up with lots of incomplete junk in there and
your form design will be governed by any database constraints placed on
your table (foreign keys, and stuff).
Then again, I sometimes have to bend my golden rules. Fortunately Perl
and Gold both bend easily.
usually don't store form input in the session because it leads to
strange results if the user has multiple browser windows open on the
site, but that may not be an issue for your application.
I'm not sure how often a user will attempt to complete one form through
multiple browsers. To be honest I'm not sure that he/she should. I think
of a form as one process which may remain persistant due to hiddens or a
session. Once the form has been completed or a user has logged in, the
session data used for the rest of the site should probably be unrelated
and populated separately.
That's just my 0.02 EU on a cold Monday evening.
R.
Re: Apache::Session and user sessions
Rafiq Ismail (ADMIN) wrote: I'm not sure how often a user will attempt to complete one form through multiple browsers. To be honest I'm not sure that he/she should. There are all kind of forms. An obvious example would be a search. Users often open up multiple windows when browsing a site and do searches in them. If you store search-related data in the session, the multiple windows will interfere with each other. These should be stored in the HTML instead. - Perrin
Re: Apache::Session and user sessions
--- Perrin Harkins [EMAIL PROTECTED] wrote: Todd W wrote: I have a table with some basic user information (first name, last name, address, phone number, etc...). That's permanent data, not session data. Session data is transient. I was reading through the archives and came across this. Everyone was so helpful the last time I had a Apache::Session question (thread what goes in a session?) so I'm back with another question. The last project I worked on really had no transient data, so the only thing I put in the session was the user id (well, there was one transisent item...current page, so that got put in the session as well). The project I'm currently working on (mod_perl, TT, Apache::Session) is a registration system. Since this is closer to a shopping cart, I would consider the data transisent. My question is with regards to whether I need or should put the submitted data into the session as the user navigates the forms (to create an account). The user will be taken through three forms to create an account. So for instance, form one will ask the user to create a username, password, and provide an email address. Before moving on to form two (billing info), should I put this data in the session, or just go ahead and dump it in the database (after making any nec. checks), since I won't need the info until they actually login? Or should I collect all the info from all three screens by putting it in the session as the user traverses the forms and then put it all in the database at once? I'm currently using the first option. BTW, it is possible for a user to create a free account by hitting form one only, so no harm would come if something happened after form one. Another question, while not mod_perl related (sorry:), is how to taint check input data like usernames, address fields and email addresses. All info is just put in the database, no unsafe system calls are run. I'm curious as to what characters to limit for usernames in particular. Thanks... __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Apache::Session and user sessions
It's just a storage mechanism. Typically the procedure is that one a user identified herself with some kind of login process, you put her user ID (a primary key to a database table) into the session, and keep it as a key for accessing that data. I have a table with some basic user information (first name, last name, address, phone number, etc...). That's permanent data, not session data. Session data is transient. Okay... That makes sense What i did was created the two columns, and hoped it would work without the id column being the primary key. It won't. All of the Apache::Session data is in a blob in the a_session column. It has no access to the other columns. Thats what I was looking for. I ran through the code with ptkdb but since I wasnt using it right, it never did a lookup anyway. So now Trying to decide what to do, in a perlHeaderParserHandler Ill just get an id from Sys::UniqueID, send it to the browser each request in a cookie or whatever, then use DBI::Tie to reinstate the session for each request. (Thinking about it, that sounds easier than Apache::Session anyways) Isn't your user table referenced by a user ID? Yeah. I said that in the OP but you snipped it. You have to connect the user ID to a browser somewhere. The normal way to do this is give the browser an ID (the session ID) and then store the relationship with Apache::Session. If you have no other transient data besides the user ID, you can skip Apache::Session and just send a user ID cookie. Make sure you have security in place to prevent people from simply entering another user ID in their cookie and gaining access to another person's information. Yeah, Ill relate the users id and a session id when she logs in. Writing Apache Modules in Perl and C has some good suggestions about securing the cookie. This all makes good sense after you distinguished the difference between session data and permanent data for me. By the way Tie::DBI is slow. Writing some kind of module for accessing your specific user table would be faster. Okay. Thanks for all your insight. Todd W. _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: Apache::Session and user sessions
Todd W wrote: Im looking at Apache::Session and trying to figure out what it does. It provides shared storage of a hash of data, and gives you a unique ID that you can tie to a user. From what I can tell, Apache::Session will only give generic sessions, of which I know nothing about the user untill they give me information during that particular session. It's just a storage mechanism. Typically the procedure is that one a user identified herself with some kind of login process, you put her user ID (a primary key to a database table) into the session, and keep it as a key for accessing that data. I have a table with some basic user information (first name, last name, address, phone number, etc...). That's permanent data, not session data. Session data is transient. What i did was created the two columns, and hoped it would work without the id column being the primary key. It won't. All of the Apache::Session data is in a blob in the a_session column. It has no access to the other columns. So now Trying to decide what to do, in a perlHeaderParserHandler Ill just get an id from Sys::UniqueID, send it to the browser each request in a cookie or whatever, then use DBI::Tie to reinstate the session for each request. (Thinking about it, that sounds easier than Apache::Session anyways) Isn't your user table referenced by a user ID? You have to connect the user ID to a browser somewhere. The normal way to do this is give the browser an ID (the session ID) and then store the relationship with Apache::Session. If you have no other transient data besides the user ID, you can skip Apache::Session and just send a user ID cookie. Make sure you have security in place to prevent people from simply entering another user ID in their cookie and gaining access to another person's information. By the way Tie::DBI is slow. Writing some kind of module for accessing your specific user table would be faster. - Perrin
Re: Apache::Session - What goes in session?
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote: We are investigating using IPC rather then a file based structure but its purely investigation at this point. What are the speed diffs between an IPC cache and a Berkely DB cache. My gut instinct always screams 'Stay Off The Disk' but my gut is not always right.. Ok, rarely right.. ;) IPC (for many definitions of that) has all sorts of odd limitations and isn't that fast. Don't go there. The disk is usually much faster than you think. Often overlooked for caching is a simple file based cache. Here's a story about that: A while ago Graham Barr and I spend some time going through a number of iterations for a self cleaning cache system. It would take lots of writes and fewer reads. In each cache entry a number of integers would be stored. Just storing the last thousand entries would be enough. We tried quite a few different approaches; the most noteworthy was a system of semaphores to control access to a number of slots in a BerkeleyDB. That should be pretty fast, right? It got a bit complicated as our systems didn't support that many semaphores, so we had to come up with a system for sharing the semaphores across multiple slots in the database. Designing and writing this implementation took a few days. It was really cool. Anyway, after fixing that and a few deadlocks we were benchmarking away. The system was so clever. We thought it was simple and neat. Okay, neat at least. And it was really slow. Slow. (~200 writes a second on a 400MHz Pentium II if I recall correctly). First we suspected we did something wrong with the semaphores, but further benchmarking showed that the BerkeleyDB just wasn't that fast for writing. 30 minutes thinking and 30 minutes typing code later we had a prototype for a simple filebased system. Now using good old Fcntl to control access to simple flat files. (Data serialized with pack(N*, ...); I don't think anything beats pack and unpack for serializing data). The expiration went into the data and purging the cache was a simple cronjob to find files older than a few minutes and deleting them. The performance? I don't remember the exact figure, but it was at least several times faster than the BerkeleyDB system. And *much* simpler. The morale of the story: Flat files rock! ;-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Apache::Session - What goes in session?
On 21 Aug 2002 at 2:09, Ask Bjoern Hansen wrote: Now using good old Fcntl to control access to simple flat files. (Data serialized with pack(N*, ...); I don't think anything beats pack and unpack for serializing data). The expiration went into the data and purging the cache was a simple cronjob to find files older than a few minutes and deleting them. The performance? I don't remember the exact figure, but it was at least several times faster than the BerkeleyDB system. And *much* simpler. The morale of the story: Flat files rock! ;-) If I'm using Apache::DBI so I have a persistent connection to MySQL, would it not be faster to simply use a table in MySQL? Peter --- Reality is that which, when you stop believing in it, doesn't go away. -- Philip K. Dick
RE: Apache::Session - What goes in session?
Hi Peter -- The morale of the story: Flat files rock! ;-) If I'm using Apache::DBI so I have a persistent connection to MySQL, would it not be faster to simply use a table in MySQL? Unlikely. Even with cached database connections you are probably not going to beat the performance of going to a flat text file. Accessing files is something the OS is optimized to do. The process of issuing a SQL query, having it parsed and retrieving results is probably more time-consuming than you think. One way to think about it is this: MySQL stores its data in files. There are many layers of code between DBI and those files, each of which add processing time. Going directly to files is far less code, and less code is most often faster code. The best way to be cure is to benchmark the difference yourself. Try out the Benchmark module. Quantitative data trumps anecdotal data every time. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Apache::Session - What goes in session?
Jesse Erlbaum [EMAIL PROTECTED] wrote: Hi Peter -- The morale of the story: Flat files rock! ;-) If I'm using Apache::DBI so I have a persistent connection to MySQL, would it not be faster to simply use a table in MySQL? Unlikely. Even with cached database connections you are probably not going to beat the performance of going to a flat text file. Accessing files is something the OS is optimized to do. The process of issuing a SQL query, having it parsed and retrieving results is probably more time-consuming than you think. All depends on the file structure. A linear search through a thousand records can be slower than a binary search through a million (500 ave. compares vs. about 20 max [10 ave.] compares - hope the extra overhead for the binary search is worth the savings in comparisons). One way to think about it is this: MySQL stores its data in files. There are many layers of code between DBI and those files, each of which add processing time. Going directly to files is far less code, and less code is most often faster code. MySQL also stores indices. As soon as you start having to store data in files and maintain indices, you might as well start using a database. The best way to be cure is to benchmark the difference yourself. Try out the Benchmark module. Quantitative data trumps anecdotal data every time. Definitely. But before you do, make sure the proper indices are created on the MySQL side. Wrong database configurations can kill any performance gain. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
RE: Apache::Session - What goes in session?
Hey James -- One way to think about it is this: MySQL stores its data in files. There are many layers of code between DBI and those files, each of which add processing time. Going directly to files is far less code, and less code is most often faster code. MySQL also stores indices. As soon as you start having to store data in files and maintain indices, you might as well start using a database. You bring up a really important point: Scale. If a custom file-based data storage system starts growing in both size and functionality it will sooner or latter reach a point where it is a far worse solution. Relational databases are optimized for two things: Ease of access and management of large data sets. If the data set is small and the functional requirements are very narrow then a custom system can outperform a database most of the time (not including poorly written systems!). Once you have to deal with large amounts of data, or you need to have an interface which allows customizable retrieval of sub-sets of data (a la SQL), a database is going to be the way to go. The trick is knowing which path to choose. Having an idea of the potential growth of the system and use of the data, combined with a few well chosen benchmarks come in handy here. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Apache::Session - What goes in session?
Ask Bjoern Hansen wrote: The performance? I don't remember the exact figure, but it was at least several times faster than the BerkeleyDB system. And *much* simpler. In my benchmarks, recent versions of BerkeleyDB, used with the BerkeleyDB module and allowed to manage their own locking, beat all available flat-file modules. It may be possible to improve the flat-file ones, but it even beat Tie::TextDir which is about as simple (and therefore fast) as they come. The only thing that did better was IPC::MM. - Perrin
Re: Apache::Session - What goes in session?
Peter J. Schoenster wrote: If I'm using Apache::DBI so I have a persistent connection to MySQL, would it not be faster to simply use a table in MySQL? Probably not, if the MySQL server is on a separate machine. If it's on the same machine, it would be close. Remember, MySQL has more work to do (parse SQL statement, make query plan, etc.) than a simple hash-based system like BerkeleyDB does. Best thing would be to benchmark it though. - Perrin
Re: Apache::Session - What goes in session?
--- Perrin Harkins [EMAIL PROTECTED] wrote: There are a few ways to deal with this. The simplest is to use the sticky load-balancing feature that many load-balancers have. Failing that, you can store to a network file system like NFS or CIFS, or use a database. (There are also fancier options with things like Spread, but that's getting a little ahead of the game.) You can use MySQL for caching, and it will probably have similar performance to a networked file system. Unfortunately, the Apache::Session code isn't all that easy to use for this, since it assumes you want to generate IDs for the objects you store rather than passing them in. You could adapt the code from it to suit your needs though. The important thing is to leave out all of the mutually exclusive locking it implements, since a cache is all about get the latest as quick as you can and lost updates are not a problem (last save wins is good enough for a cache). I haven't looked at the cache modules docs yet...would it be possible to build cache on the separate load-balanced machines as we go along...as we do with template caching? By that I mean if an item has cached on machine one then further requests on machine one will come from cache where if on machine two the same item hasn't cached, it will be pulled from the db the first time and then cached? If this isn't possible, I'm not sure if I'll be able to implement any caching or not (some of the site configuration is out of my hands) and everything seems so user specific...I'll definitely reread your posts and go through my app for things that should be cached. I would be curious though that if my choice is simply that the data is stored in the session or comes from the database with each request, would it still be best to essentially only store the session id in the session and pull everything else from the db? It still seems that something trivial like a greeting name (a preference) could go in the session. The relationships to the features and pages differ by user, but there might be general information about the features themselves that is stored in the database and is not user-specific. That could be cached separately, to save some trips to the db for each user. The only thing I can think of right now is a calendar...that should probably be cached. The only gotcha would be that the calendar would need to update every day, at least on the current month's pages. But this is only on a feature page, not a users created page (that is a user can click a link on their daily page that takes them to a feature page where they can go through archives). You can cache the names too if you want to, but keeping them out of the session means that you won't be slowed down by fetching that extra data and de-serializing it with Storable unless the page you're on actually needs it. Even though there are some preset pages, the user can change the names and the user can also create a cutom page with its own name. So there could be thousands of unique page names, many (most) specific to unique users (like Jim's Sports Page, etc.). Not to mention that between the fact that the users' daily pages can have any number of user selected features per page and features themselves can have archive depths of anywhere from 3 to 20 years, there's a lot of info. It's also good to separate things that have to be reliable (like the ID of the current user, since without that you have to send them back to log in again) from things that don't need to be (you could always fetch the list of pages from the db if your cache went down). Very good advice. I've found that occasionally something happens to my session where the sesssion id is ok but some of the other data disapears (like current page id) which really screws things up until you log out and log back in again. This leads me to suspect that I've answered my own question from above. It's just whether I can cache or not. Thanks for all your time and help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Apache::Session - What goes in session?
On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote: I can definitely get it all from the db, but that doesn't seem very efficient. Don't worry about whether it *seems* efficient. Do it right, and then worry about how to speed that up - if, and only if, it's too slow. Premature optimisation is the root of all evil, and all that .. At BlackStar the session was just a single hashed ID and all other info was loaded from the database every time. We thought about caching some info a few times, but always ran into problems with replication. In the end we discovered that fetching everything from the database on every request wasn't noticeably slower than anything else we could up with, and was a lot more flexible. Throwing more memory at the database servers was usually quicker, cheaper and more effective than micro-optimising our session vs caching strategy... Tony
Re: Apache::Session - What goes in session?
We do see some slowdown on our langauge translation db calls since they are so intensive. Moving to a 'per child' cache for each string as it came out of the db sped page loads up from 4.5 seconds to .6-1.0 seconds per page which is significant. Currently we are working on a 'per machine' cache so all children can benefit for each childs initial database read of the translated string, the differential between children is annoying in the 'per child cache' strategy. John- On Tue, 20 Aug 2002 16:33:07 +0100 Tony Bowden [EMAIL PROTECTED] wrote: On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote: I can definitely get it all from the db, but that doesn't seem very efficient. Don't worry about whether it *seems* efficient. Do it right, and then worry about how to speed that up - if, and only if, it's too slow. Premature optimisation is the root of all evil, and all that .. At BlackStar the session was just a single hashed ID and all other info was loaded from the database every time. We thought about caching some info a few times, but always ran into problems with replication. In the end we discovered that fetching everything from the database on every request wasn't noticeably slower than anything else we could up with, and was a lot more flexible. Throwing more memory at the database servers was usually quicker, cheaper and more effective than micro-optimising our session vs caching strategy... Tony
Re: Apache::Session - What goes in session?
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
Currently we are working on a 'per machine' cache so all
children can benefit for each childs initial database read
of the translated string, the differential between
children is annoying in the 'per child cache' strategy.
Sounds like you want BerkeleyDB.pm (not DB_File), which is quite fast and
handles locking/concurrent access internally (when set up properly).
See the Alzabo::ObjectCache::{Store,Sync}::BerkeleyDB modules for
examples.
For Alzabo, I also have a caching system that caches data in a database,
for cross-machine caching/syncing. I haven't really benchmarked it yet
but I imagine it could be a win in some situations. For example, you
could set up the cache as a separate machine running MySQL and still pull
your data from another machine, possibly running a different RDBMS.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: Apache::Session - What goes in session?
We are investigating using IPC rather then a file based
structure but its purely investigation at this point.
What are the speed diffs between an IPC cache and a
Berkely DB cache. My gut instinct always screams 'Stay Off
The Disk' but my gut is not always right.. Ok, rarely
right.. ;)
John-
On Tue, 20 Aug 2002 11:49:52 -0500 (CDT)
Dave Rolsky [EMAIL PROTECTED] wrote:
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
Currently we are working on a 'per machine' cache so all
children can benefit for each childs initial database
read
of the translated string, the differential between
children is annoying in the 'per child cache' strategy.
Sounds like you want BerkeleyDB.pm (not DB_File), which
is quite fast and
handles locking/concurrent access internally (when set up
properly).
See the Alzabo::ObjectCache::{Store,Sync}::BerkeleyDB
modules for
examples.
For Alzabo, I also have a caching system that caches data
in a database,
for cross-machine caching/syncing. I haven't really
benchmarked it yet
but I imagine it could be a win in some situations. For
example, you
could set up the cache as a separate machine running
MySQL and still pull
your data from another machine, possibly running a
different RDBMS.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: Apache::Session - What goes in session?
md wrote:
I haven't looked at the cache modules docs yet...would
it be possible to build cache on the separate
load-balanced machines as we go along...as we do with
template caching?
Of course. However, if a user is sent to a random machine each time you
won't be able to cache anything that a user is allowed to change during
their time on the site, because they could end up on a machine that has
an old cached value for it. Sticky load-balancing or a cluster-wide
cache (which you can update when data changes) deals with this problem.
everything seems so user specific...
That doesn't mean you can't cache it. You can do basically the same
thing you were doing with the session: stuff a hash of user-specific
stuff into the cache. The next time that user sends a request, you
check the cache for data on that user ID (you get the user ID from the
session) and if you don't find any you just fetch it from the db.
Pseudo-code:
sub fetch_user_data {
my $user_id = shift;
my $user_data;
unless ($user_data = fetch_from_cache($user_id)) {
$user_data = fetch_from_db($user_id);
}
return $user_data;
}
I would be curious though that if my choice is simply
that the data is stored in the session or comes from
the database with each request, would it still be best
to essentially only store the session id in the
session and pull everything else from the db? It still
seems that something trivial like a greeting name (a
preference) could go in the session.
Your decision about what to put in the session is not connected to your
decision about what to pull from the db each time. You can cache all
the data if you want to, and still have very little in the session.
This might sound like an academic distinction, but I think it's
important to keep the concepts separate: a session is a place to store
transient state information that is irrelevant as soon as the user logs
out, and a cache is a way of speeding up access to a slow resource like
a database, and the two things should not be confused. You can actually
cache the session data if you need to (with a write-through cache that
updates the backing database as well). A cache will typically be faster
than session storage because it doesn't need to be very reliable and
because you can store and retrieve individual chunks of data (user's
name, page names) when you need them instead of storing and retrieving
everything on every request. Separating these concepts allows you to do
things like migrate the session storage to a transactional database some
day, and move your cache storage to a distributed multicast cache when
someone comes out with a module for that.
The only
gotcha would be that the calendar would need to update
every day, at least on the current month's pages.
The cache modules I mentioned have a concept of timeout so that you
can say cache this for 12 hours and then when it expires you fetch it
again and update the cache for another 12 hours.
Even though there are some preset pages, the user
can change the names and the user can also create a
cutom page with its own name.
No problem, you can cache data that's only useful for a single user, as
I explained above.
Not
to mention that between the fact that the users' daily
pages can have any number of user selected features
per page and features themselves can have archive
depths of anywhere from 3 to 20 years, there's a lot
of info.
No problem, disks are cheap. 400MB of disk space will cost you about as
much as a movie in New York these days.
- Perrin
Re: Apache::Session - What goes in session?
Thanks...you've given me plenty to work with. Great explination. This is good pragmatic stuff to know! __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Apache::Session - What goes in session?
[EMAIL PROTECTED] wrote: We are investigating using IPC rather then a file based structure but its purely investigation at this point. What are the speed diffs between an IPC cache and a Berkely DB cache. My gut instinct always screams 'Stay Off The Disk' but my gut is not always right.. Ok, rarely right.. ;) Most of the shared memory modules are much slower than Berkeley DB. The fastest option around is IPC::MM, but data you store in that does not persist if you restart the server which is a problem for some. BerkeleyDB (the new one, not DB_File) is also very fast, and other options like Cache::Mmap and Cache::FileCache are much faster than anything based on IPC::Sharelite and the like. I have charts and numbers in my TPC presentation, which I will be putting up soon. - Perrin
Re: Apache::Session - What goes in session?
Thanks, you just saved us a ton of time. Off to change course ;) J On Tue, 20 Aug 2002 13:12:29 -0400 Perrin Harkins [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: We are investigating using IPC rather then a file based structure but its purely investigation at this point. What are the speed diffs between an IPC cache and a Berkely DB cache. My gut instinct always screams 'Stay Off The Disk' but my gut is not always right.. Ok, rarely right.. ;) Most of the shared memory modules are much slower than Berkeley DB. The fastest option around is IPC::MM, but data you store in that does not persist if you restart the server which is a problem for some. BerkeleyDB (the new one, not DB_File) is also very fast, and other options like Cache::Mmap and Cache::FileCache are much faster than anything based on IPC::Sharelite and the like. I have charts and numbers in my TPC presentation, which I will be putting up soon. - Perrin
Re: Apache::Session - What goes in session?
Just to jump in here - as I understand it you can split a hash across multiple threads if you preload it before apache forks. So load it in your startup.pl and get it in memory prior to forking. It'll be part of the shared memory since you aren't writing to it. Or at least that's how I understand the theory to work anyway. Josh [EMAIL PROTECTED] 08/20/2002 10:54 AM To: Tony Bowden [EMAIL PROTECTED], md [EMAIL PROTECTED] cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: Apache::Session - What goes in session? We do see some slowdown on our langauge translation db calls since they are so intensive. Moving to a 'per child' cache for each string as it came out of the db sped page loads up from 4.5 seconds to .6-1.0 seconds per page which is significant. Currently we are working on a 'per machine' cache so all children can benefit for each childs initial database read of the translated string, the differential between children is annoying in the 'per child cache' strategy. John- On Tue, 20 Aug 2002 16:33:07 +0100 Tony Bowden [EMAIL PROTECTED] wrote: On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote: I can definitely get it all from the db, but that doesn't seem very efficient. Don't worry about whether it *seems* efficient. Do it right, and then worry about how to speed that up - if, and only if, it's too slow. Premature optimisation is the root of all evil, and all that .. At BlackStar the session was just a single hashed ID and all other info was loaded from the database every time. We thought about caching some info a few times, but always ran into problems with replication. In the end we discovered that fetching everything from the database on every request wasn't noticeably slower than anything else we could up with, and was a lot more flexible. Throwing more memory at the database servers was usually quicker, cheaper and more effective than micro-optimising our session vs caching strategy... Tony
Re: Apache::Session - What goes in session?
I havent had much luck with that but we will look at it again and see what we can get from it. We want to avoid preloading all data per child direct from the database but I wouldnt mind doing it on startup for the root process and then copying it to each child. J On Tue, 20 Aug 2002 16:39:45 -0500 [EMAIL PROTECTED] wrote: Just to jump in here - as I understand it you can split a hash across multiple threads if you preload it before apache forks. So load it in your startup.pl and get it in memory prior to forking. It'll be part of the shared memory since you aren't writing to it. Or at least that's how I understand the theory to work anyway. Josh [EMAIL PROTECTED] 08/20/2002 10:54 AM To: Tony Bowden [EMAIL PROTECTED], md [EMAIL PROTECTED] cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: Apache::Session - What goes in session? We do see some slowdown on our langauge translation db calls since they are so intensive. Moving to a 'per child' cache for each string as it came out of the db sped page loads up from 4.5 seconds to .6-1.0 seconds per page which is significant. Currently we are working on a 'per machine' cache so all children can benefit for each childs initial database read of the translated string, the differential between children is annoying in the 'per child cache' strategy. John- On Tue, 20 Aug 2002 16:33:07 +0100 Tony Bowden [EMAIL PROTECTED] wrote: On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote: I can definitely get it all from the db, but that doesn't seem very efficient. Don't worry about whether it *seems* efficient. Do it right, and then worry about how to speed that up - if, and only if, it's too slow. Premature optimisation is the root of all evil, and all that .. At BlackStar the session was just a single hashed ID and all other info was loaded from the database every time. We thought about caching some info a few times, but always ran into problems with replication. In the end we discovered that fetching everything from the database on every request wasn't noticeably slower than anything else we could up with, and was a lot more flexible. Throwing more memory at the database servers was usually quicker, cheaper and more effective than micro-optimising our session vs caching strategy... Tony
Re: Apache::Session - What goes in session?
Not in the MS house that I am living in right now :^( On Tue, 20 Aug 2002, Perrin Harkins wrote: Ian Struble wrote: And just to throw one more wrench into the works. You could load up only the most popular data at startup and let the rest of the data get loaded on a cache miss. That is one technique that we have used for some customer session servers. It allowed each server to start up in well under a minute instead of in 15-30 minutes while pegging the DB. The 15-30 minutes was when we were dealing with ~5mil total entries and I would hate to see it now that the size of the table has doubled. Now we just need to do some batch processing to determine what subset gets loaded at startup. You could also just dump the whole thing into a Berkeley DB file every now and then. - Perrin
RE: Apache::Session - What goes in session?
Hello md -- I'm using mod_perl and Apache::Session on an app that is similar to MyYahoo. I found a few bits of info from a previous thread, but I'm curious as to what type of information should go in the session and what should come from the database. One thing to watch out for is the trap of using session data as a dumping ground for global variables. Since you are asking what belongs in a session, it seems you are already thinking along those lines. I have found that many people who are fond of sessions often use them to store data which I would be personally inclined to store in hidden form data, in a simple cookie, or retrieve from a database when needed. In my systems I usually only store a single session ID in a cookie -- a key which references a database row. This allows me to have as much data as I like but keep it all in the database. There is one case where it might make sense to put data into a session of some sort -- to cache information which is very time-consuming to retrieve. Minimizing time-consuming database operations is an important thing to think about in large systems, and a place where session data might come in handy. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Apache::Session - What goes in session?
md wrote: Currently I'm putting very little in the session Good. You should put in as little as possible. what I am putting in the session is more global in nature...greeting, current page number, current page name... That doesn't sound very global to me. What happens when users open multiple browser windows on your site? Doesn't it screw up the current page data? I'm pulling a lot of info from the database and I wonder if my design is sound. Optimizing database fetches or caching data is independent of the session issue. Nothing that is relevant to more than one user should ever go in the session. Now I need to add global modules to the page which will show user info like which pages they have created and which features are being emailed to the user. These modules will display on every page unless the user turns them off. That sounds like a user or subscriptions object to me, not session data. It seems that since this info wouldn't change very often that I should put the data in the session... No, that's caching. Don't use the session for caching, use a cache for it. They're not the same. A session is often stored in a database so that it can be reliable. A cache is usually stored on the file system so it can be fast. Things like the login status of this session, and the user ID that is associated with it go in the session. Status of a particular page has to be passed in query args or hidden fields, to avoid problems with multiple browser windows. Data that applies to multiple users or lasts more than the current browsing session never goes in the session. - Perrin
RE: Apache::Session - What goes in session?
Thanks though. That was succinctly put. Could you go back in time and tell me that a year or two ago? That would be great, thanks again. -Josh :) Things like the login status of this session, and the user ID that is associated with it go in the session. Status of a particular page has to be passed in query args or hidden fields, to avoid problems with multiple browser windows. Data that applies to multiple users or lasts more than the current browsing session never goes in the session. -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
Re: Apache::Session - What goes in session?
--- Perrin Harkins [EMAIL PROTECTED] wrote: md wrote: That doesn't sound very global to me. What happens when users open multiple browser windows on your site? Doesn't it screw up the current page data? I don't think global was the term I should have used. What I mean is data that will be seen on all or most pages by the same user...like Hello Jim, where Jim is pulled from the database when the session is created and passed around in the session after that (and updated in the db and session if user changes their greeting name). Current page name and id are never stored in db, so different browser windows can be on different pages...I'm not sure if that's good or bad. However, changes to the user name will be seen in both browser windows since that's updated both in the session and db. Optimizing database fetches or caching data is independent of the session issue. Nothing that is relevant to more than one user should ever go in the session. Correct. That little info I am putting in the session corresponds directly to a single user. That sounds like a user or subscriptions object to me, not session data. Once again, I shouldn't have used the term global. This is the subscriptions info for a single user...that's why I had thought to put this in the session instead of pulling from the db each page call since the data will rarely change. This info will be displayed on every page the user visits (unless they turn off this module). No, that's caching. Don't use the session for caching, use a cache for it. They're not the same. A session is often stored in a database so that it can be reliable. A cache is usually stored on the file system so it can be fast. The session is stored in a database (Apache::Session::MySQL), and I am using TT caching for the templates, but I'm not sure how to cache the non-session data. I've seen this discussed but I definitely need more info on this. As it stands I see two options: get data from the session or get it from the db...how do I bring caching into play? Things like the login status of this session, and the user ID that is associated with it go in the session. Status of a particular page has to be passed in query args or hidden fields, to avoid problems with multiple browser windows. Data that applies to multiple users or lasts more than the current browsing session never goes in the session. What about something like default page id, which is the page that is considered your home page? This id is stored permanently in the db (lasts more than the current current browsing session) but I keep it in the session since this also rarely changes so I don't want to keep hitting the db to get it. Thanks again... __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Apache::Session - What goes in session?
md wrote: I don't think global was the term I should have used. What I mean is data that will be seen on all or most pages by the same user...like Hello Jim Okay, don't put that in the session. It belongs in a cache. The session is for transient state information, that you don't want to keep after the user logs out. Current page name and id are never stored in db, so different browser windows can be on different pages... I thought your session was all stored in MySQL. Why are you putting these in the session exactly? If these things are not relevant to more than one request (page), they don't belong in the session. They should just be in ordinary variables. That sounds like a user or subscriptions object to me, not session data. Once again, I shouldn't have used the term global. This is the subscriptions info for a single user...that's why I had thought to put this in the session instead of pulling from the db each page call since the data will rarely change. You should use a cache for that, rather than the session. This is long-term data that you just want quicker access to. I am using TT caching for the templates, but I'm not sure how to cache the non-session data. Template Toolkit caches the compiled template code, but it doesn't cache your data or the output of the templates. What you should do is grab a module like Cache::Cache or Cache::Mmap and take a look at the examples there. You use it in a way that's very similar to what you're doing with Apache::Session for the things you referred to as global. There are also good examples in the documentation for the Memoize module. There are various reasons to use a cache rather than treating the session like a cache. If you put a lot of data in the session, it will slow down every hit loading and saving that data. In a cache, you can just keep multiple cached items separately and only grab them if you need them for this page. With a cache you can store things that come from the database but are not user-specific, like today's weather. What about something like default page id, which is the page that is considered your home page? This id is stored permanently in the db (lasts more than the current current browsing session) but I keep it in the session since this also rarely changes so I don't want to keep hitting the db to get it. I would have some kind of user object which has a property of default_page_id. The first time the user logs in I would fetch that from the database, and then I would cache it so that I wouldn't need to go back to the database for it on future requests. - Perrin
Re: Apache::Session - What goes in session?
--- Perrin Harkins [EMAIL PROTECTED] wrote: Current page name and id are never stored in db, so different browser windows can be on different pages... I thought your session was all stored in MySQL. Why are you putting these in the session exactly? If these things are not relevant to more than one request (page), they don't belong in the session. They should just be in ordinary variables. You are correct, these items are in the session in the db. I meant that they weren't kept in long term storage in the db after the session ended like the default page id and user name are. The current page id/name is only relevent for an active session. Once a session is started current page is set to whatever the default page id is and will change as the user changes pages. The only reason I did this (as I recall) is that way I can get the page name once. You should use a cache for that, rather than the session. This is long-term data that you just want quicker access to. Yes, that's exactly what I want to do. My main concern is long-term data that I want quicker access to. I can definitely get it all from the db, but that doesn't seem very efficient. Template Toolkit caches the compiled template code, but it doesn't cache your data or the output of the templates. What you should do is grab a module like Cache::Cache or Cache::Mmap and take a look at the examples there. You use it in a way that's very similar to what you're doing with Apache::Session for the things you referred to as global. There are also good examples in the documentation for the Memoize module. Great...exactly the kind of info I was looking for. I'll look at those. We are using a load-balanced system; I shoudl have mentioned that earlier. Won't that be an issue with caching to disk? Is it possible to cache to the db? There are various reasons to use a cache rather than treating the session like a cache. If you put a lot of data in the session, it will slow down every hit loading and saving that data. In a cache, you can just keep multiple cached items separately and only grab them if you need them for this page. With a cache you can store things that come from the database but are not user-specific, like today's weather. Thank you for all the excellent advice and explination(in this and other posts). Most of the info I'll be pulling is *very* user-specific...user name, which features to display on which page, what features the user gets by email, etc. What happens is the user logs in and then the username (greeting), the default page id (the user can create many pages with different features per page) and what features go on the default page are pulled from the database and the default page is displayed, as well as any module info. The modules will consist of a pages module with the names of all the pages the user has created (with links) and a emails module which will display all the features that the user is getting via email. These modules will be displayed on every page. You can see that almost everything is user-specific. Right now I'm storing the page names/ids in a hash ref in the session (the emails module isn't live yet), but I thought that I would change that and only store the module id and pull the names from the db (if the user hasn't turned off the module) with each page call. Thanks again for all the info! __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Apache::Session - What goes in session?
md wrote: We are using a load-balanced system; I shoudl have mentioned that earlier. Won't that be an issue with caching to disk? Is it possible to cache to the db? There are a few ways to deal with this. The simplest is to use the sticky load-balancing feature that many load-balancers have. Failing that, you can store to a network file system like NFS or CIFS, or use a database. (There are also fancier options with things like Spread, but that's getting a little ahead of the game.) You can use MySQL for caching, and it will probably have similar performance to a networked file system. Unfortunately, the Apache::Session code isn't all that easy to use for this, since it assumes you want to generate IDs for the objects you store rather than passing them in. You could adapt the code from it to suit your needs though. The important thing is to leave out all of the mutually exclusive locking it implements, since a cache is all about get the latest as quick as you can and lost updates are not a problem (last save wins is good enough for a cache). The modules will consist of a pages module with the names of all the pages the user has created (with links) and a emails module which will display all the features that the user is getting via email. These modules will be displayed on every page. You can see that almost everything is user-specific. The relationships to the features and pages differ by user, but there might be general information about the features themselves that is stored in the database and is not user-specific. That could be cached separately, to save some trips to the db for each user. Right now I'm storing the page names/ids in a hash ref in the session (the emails module isn't live yet), but I thought that I would change that and only store the module id and pull the names from the db (if the user hasn't turned off the module) with each page call. You can cache the names too if you want to, but keeping them out of the session means that you won't be slowed down by fetching that extra data and de-serializing it with Storable unless the page you're on actually needs it. It's also good to separate things that have to be reliable (like the ID of the current user, since without that you have to send them back to log in again) from things that don't need to be (you could always fetch the list of pages from the db if your cache went down). - Perrin
Re: Apache::Session HELP!
What does your config file look like? All pointing at the right tables
and fields and such?
-Fran
Rafiq Ismail (ADMIN) wrote:
Hi, I'm in major poop.
Got a presentation soon and my just implemented, implementation of
Apache::Session is not working as per the man page.
I've set commit to 1 and tied a session to a postgres database. I then
set a field and check the table it's not there.
When I later do a fetch on it, I get a scarey error:
[error] Object does not exist in the data store at
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Store/Postgres.pm line 81
Create and fetch methods, with table schema, below:
1)Create:
sub tieSession
{
my $self = shift;
my %session;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
print STDERR \n CREATING SESSION using dsn: $dsn \n;
tie %session, 'Apache::Session::Postgres', undef,
{
DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store creation time
$session{CREATION_TIME}=time;
return \%session;
}
2) fetching the session:
sub fetchSession
{
my $self = shift;
my $sessionId = shift;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
my %session;
print STDERR \n getting session for $sessionId\n;
tie %session, 'Apache::Session::Postgres', $sessionId,
{ DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store last access
$session{LAST_ACCESS} = time;
$ENV{GUEST_ID} = $session{GUEST_ID} || undef;
return \%session;
}
3) Table Schemata
CREATE TABLE sessions (
id char(32) not null primary key,
a_session text
);
help?
Cheers,
fiq
Re: Apache::Session HELP!
Wait, ignore that - I was getting my Apache::Session and my
Apache::AuthCookie signals crossed. Sorry.
-Fran
Fran Fabrizio wrote:
What does your config file look like? All pointing at the right
tables and fields and such?
-Fran
Rafiq Ismail (ADMIN) wrote:
Hi, I'm in major poop.
Got a presentation soon and my just implemented, implementation of
Apache::Session is not working as per the man page.
I've set commit to 1 and tied a session to a postgres database. I then
set a field and check the table it's not there.
When I later do a fetch on it, I get a scarey error:
[error] Object does not exist in the data store at
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Store/Postgres.pm line 81
Create and fetch methods, with table schema, below:
1)Create:
sub tieSession
{
my $self = shift;
my %session;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
print STDERR \n CREATING SESSION using dsn: $dsn \n;
tie %session, 'Apache::Session::Postgres', undef,
{
DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store creation time
$session{CREATION_TIME}=time;
return \%session;
}
2) fetching the session:
sub fetchSession
{
my $self = shift;
my $sessionId = shift;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
my %session;
print STDERR \n getting session for $sessionId\n;
tie %session, 'Apache::Session::Postgres', $sessionId,
{ DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store last access
$session{LAST_ACCESS} = time;
$ENV{GUEST_ID} = $session{GUEST_ID} || undef;
return \%session;
}
3) Table Schemata
CREATE TABLE sessions (
id char(32) not null primary key,
a_session text
);
help?
Cheers,
fiq
Re: Apache::Session HELP!
Your provided code looks accurate. Given that you get no errors
trying to place the session ID in the first place, it implies that the
$sessionID you are passing in your fetchSession routine is either not being
passed, being passed incorrectly or the object does not, in fact, live in
the database.
You should check what you are passing into the routine and then see
if the key for the session is in your table.
--jayson
Rafiq Ismail
(ADMIN) To: mod_perl list
[EMAIL PROTECTED]
[EMAIL PROTECTED] cc:
hought.com Subject: Apache::Session HELP!
Sent by: Rafiq
Ismail (ADMIN)
rafiq@Dreamthought.
com
08/09/02 06:01:23 AM
Hi, I'm in major poop.
Got a presentation soon and my just implemented, implementation of
Apache::Session is not working as per the man page.
I've set commit to 1 and tied a session to a postgres database. I then
set a field and check the table it's not there.
When I later do a fetch on it, I get a scarey error:
[error] Object does not exist in the data store at
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Store/Postgres.pm line 81
Create and fetch methods, with table schema, below:
1)Create:
sub tieSession
{
my $self = shift;
my %session;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
print STDERR \n CREATING SESSION using dsn: $dsn \n;
tie %session, 'Apache::Session::Postgres', undef,
{
DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store creation time
$session{CREATION_TIME}=time;
return \%session;
}
2) fetching the session:
sub fetchSession
{
my $self = shift;
my $sessionId = shift;
my $dsn = DBI:Pg:dbname=.$DBI_DB.;host=.$DBI_HOST;
my %session;
print STDERR \n getting session for $sessionId\n;
tie %session, 'Apache::Session::Postgres', $sessionId,
{ DataSource = $dsn,
UserName = $DBI_USER,
Password = $DBI_PWD,
Commit = 1
};
## store last access
$session{LAST_ACCESS} = time;
$ENV{GUEST_ID} = $session{GUEST_ID} || undef;
return \%session;
}
3) Table Schemata
CREATE TABLE sessions (
id char(32) not null primary key,
a_session text
);
help?
Cheers,
fiq
--
Jefferies archives and reviews outgoing and incoming e-mail. Such may be
produced at the request of regulators. Sender accepts no liability for
any errors or omissions arising as a result of transmission. Use by other than
intended recipients is prohibited. This is neither an offer nor a
solicitation of an offer to buy or sell securities. Opinions or estimates
constitute our best judgment at this time and are subject to change without
notice. Information upon which this material is based was obtained from
sources believed to be reliable but has not been verified. Additional
information is available upon request. Jefferies its affiliates and
respective directors officers and employees may buy or sell
securities mentioned as agent or principal. This is for use by
professional or institutional investors only. No investments or
services mentioned or described are available to private
customers as defined by the SFA or to anyone in Canada not a Designated
Institution.
Re: 'Apache::Session' using REMOTE_USER as key
Perrin Harkins wrote:
Brian Parker wrote:
I'm trying to use Apache::Session::MySQL. Since I'm generating my own
session key outside of Apache::Session (using $ENV{REMOTE_USER}), what
method(s) do I have to override to prevent Apache::Session from trying
to create a session key for me? Since I'm not using Apache::Session's
key generation capability, is there another implementation that would be
more appropriate for my application?
Just write a replacement for Apache::Session::Generate::MD5.
Thanks Perrin. That at least got me looking in the right place.
I had to replace 'Apache::Session::Generate::MD5' as you suggested and then
create my own subclass of 'Apache::Session' (specifies which 'validate' and
'generate' subroutines to call). Because 'Apache::Session' does not provide a
way to create a session with a certain id, I ended up having to do doing
something like this:
my $rm = $ENV{REMOTE_USER}
eval{
# see if the user has a session created
tie %session, 'WC::ApacheSession::MySQL', $rm, {
Handle = $dbh,
LockHandle = $dbh
};
1;
} or do {
# create the session using $ENV{REMOTE_USER} as key
tie %session, 'WC::ApacheSession::MySQL', undef, {
Handle = $dbh,
LockHandle = $dbh
};
};
... to handle the case of the the first time a user. This will work until I
invent a cleaner solution.
regards,
Brian
You can
look at Apache::Session::Generate::ModUsertrack, which is probably very
close to what you want to do.
- Perrin
RE: Apache::Session
You need to do some more debugging. Problems with Apache::Session are usually due to scoping, so put in some debug statements to see that the session objects for the IDs having trouble are getting properly cleaned up (i.e. DESTROY is getting called). It is possible to have problems with DB_File if it doesn't get untied after each request. In my experience when untie is not called the request usually hangs. It seems odd that it would be isolated to just a few workstations though. Is it possible that the issue can be isolated to a child instance even with different ID's? Thanks for the response : )
RE: Apache::Session
You need to do some more debugging. Problems with Apache::Session are usually due to scoping, so put in some debug statements to see that the session objects for the IDs having trouble are getting properly cleaned up (i.e. DESTROY is getting called). It is possible to have problems with DB_File if it doesn't get untied after each request. Wouldn't the issue above (untie) be alleviated by restarting apache?
Re: Apache::Session
Stathy G. Touloumis wrote: You need to do some more debugging. Problems with Apache::Session are usually due to scoping, so put in some debug statements to see that the session objects for the IDs having trouble are getting properly cleaned up (i.e. DESTROY is getting called). It is possible to have problems with DB_File if it doesn't get untied after each request. Wouldn't the issue above (untie) be alleviated by restarting apache? Probably. There are some strange situations you can get into with DB_File if you don't untie (due to caching and lost updates), but you're right that the file locks would probably make the system hang if the session wasn't getting cleaned up. I don't know what else could be causing your problem, but I would still suggest trying Apache::Session::File as a potential fix. - Perrin
Re: Apache::Session suggested mod
Vuillemot, Ward W [EMAIL PROTECTED] wrote: Has anyone ever thought to have the table name modifiable? E.g. instead of 'sessions', you could set it to something like 'preferences' for a given instance. I wanted to maintain session information, but also preferences that are attached to a given username. I could just put the two within the same table. . .but as I am anal, I would rather see the data separated. I was thinking of doing it myself -- but thought it might be a worthwhile mod for the entire community. And it saves me maintaining two sets of nearly identical code...and of course, there might be good reasons NOT to do this. Ideas? Thoughts? I would love to see this, but am not sure how it would be implemented (don't want to design something without the author's input). I'm wanting to use it to track sessions and contexts -- sessions can own multiple contexts and contexts can pass from session to session. Basically break identity apart from process. Apache::Session would be ideal for both since the storage mechanisms are identical. Unfortunately, the table name is hard-coded. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: Apache::Session suggested mod
I once did a one-off mod of Apache::Session to do just this but eventually gave up and just changed my table names. It was to hard to keep in sync with new releases of Apache::Session and I don't have enough faith in my ability to send a real patch :) So I think its a natural path. When you create your session object send it some args for its table name as well as field names, that would give a lot of flexiblity as well as allowing apache::session to morph into existing data structures. John- On Wed, 10 Apr 2002 14:00:44 -0700 Vuillemot, Ward W [EMAIL PROTECTED] wrote: Has anyone ever thought to have the table name modifiable? E.g. instead of 'sessions', you could set it to something like 'preferences' for a given instance. I wanted to maintain session information, but also preferences that are attached to a given username. I could just put the two within the same table. . .but as I am anal, I would rather see the data separated. I was thinking of doing it myself -- but thought it might be a worthwhile mod for the entire community. And it saves me maintaining two sets of nearly identical code...and of course, there might be good reasons NOT to do this. Ideas? Thoughts? Cheers, Ward
Re: Apache::Session
On Mon, 2002-03-25 at 15:44, Stathy G. Touloumis wrote: Has anyone ran into issues with data being written to the data source using Apache::Session::Store::DB_File and Apache::Session::Lock::File? We are running into a unique instance where a value is not being saved to the session store at a certain point through a workflow. There are multiple frames which are making requests but only one frame makes the request to the server which runs code to write to the Session store. We do have KeepAlive's enabled so I don't think there should be any contention issues when attempting to write to the store. Nevertheless this still seems like the only reason this might be happening. Apache 1.3.22 mod_perl 1.26 Apache::Session 1.54 Could you give a little more detail please? Lots of people have lots of problems with Apache::Session, but it always comes down to not destroying Session objects. -jwb
RE: Apache::Session
Thanks for responding . . . Not sure what else you need. Destroying session objects? Do you mean to untie the session $obj? This is done at the end of each request via untie ( untie(%$obj) ). I have noticed behavior where when attempting to delete a session object ( tied(%$obj)-delete ) I get a 'false' value returned which I cannot figure out why. Has anyone ran into issues with data being written to the data source using Apache::Session::Store::DB_File and Apache::Session::Lock::File? We are running into a unique instance where a value is not being saved to the session store at a certain point through a workflow. There are multiple frames which are making requests but only one frame makes the request to the server which runs code to write to the Session store. We do have KeepAlive's enabled so I don't think there should be any contention issues when attempting to write to the store. Nevertheless this still seems like the only reason this might be happening. Apache 1.3.22 mod_perl 1.26 Apache::Session 1.54 Could you give a little more detail please? Lots of people have lots of problems with Apache::Session, but it always comes down to not destroying Session objects.
Re: Apache::Session problem with DBD::Oracle
Brian Lavender wrote: I am trying to install Apache::Session and it is failing on the DBD::Oracle tests. It is asking for a default user. Do I need to configure Oracle for a default user? Or do I need to set some environment variable with a user id and password? well, looking at t/99oracle.t (line 45) it looks like you need to define the following environment variables: ORACLE_HOME (of course) AS_ORACLE_USER AS_ORACLE_PASS HTH --Geoff
Re: Apache::Session problem with DBD::Oracle
On Mon, 11 Mar 2002, Brian Lavender wrote:
Date: Mon, 11 Mar 2002 11:24:35 -0800
From: Brian Lavender [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Apache::Session problem with DBD::Oracle
I am trying to install Apache::Session and it is failing on
the DBD::Oracle tests. It is asking for a default user. Do
I need to configure Oracle for a default user? Or do I need
to set some environment variable with a user id and password?
brian
Here are the errors I am getting:
t/99oracle..DBI-connect(sgum) failed: ORA-01004: default username feature
not supported; logon denied (DBD ERROR: OCISessionBegin) at
blib/lib/Apache/Session/Store/Oracle.pm line 45
(in cleanup) DBI-connect(sgum) failed: ORA-01004: default username feature
not supported; logon denied (DBD ERROR: OCISessionBegin) at
blib/lib/Apache/Session/Store/Oracle.pm line 45
t/99oracle..dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-10
Failed 10/10 tests, 0.00% okay
Oracle is fairly picky about the connection info. Here's an example
of one I use:
use constant FooDataSource = 'dbi:Oracle:';
use constant FooDBUser =
q{user/password@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host)(PORT=1521))(CONNECT_DATA=(SID=sid)))};
use constant FooDBPassword = '';
use constant FooDBOptions = {
RaiseError = 1,
FetchHashKeyName = 'NAME_lc',
LongReadLen = 3000,
LongTruncOk = 1,
};
my $db = DBI-connect(FooDataSource, FooDBUser, FooDBPassword, FooDBOptions);
I'm also fairly sure that some environment variables should be set.
If I grep my env for ORA, I see:
ORACLE_SID=name changed to protect the innocent
ORACLE_BASE=/oracle1/app/oracle
ORACLE_HOME=/oracle1/app/oracle/product/8.0.5
ORACLE_TERM=xsun5
Obviously, the $ENV{'ORACLE_SID'} matches the SID in the FooDBUser
string. The above string is used from a host other than the machine
that houses Oracle, so it may have more in it than you need if you're
on the same machine.
HTH,
ky
Re: Apache::Session problem with DBD::Oracle
Yup, that fixed it. I have another problem with the File portion. Seems that the test giving the following fail statements. I checked /tmp and there is a lock file. I am not sure about how File::Store all works, and I couldn't quite understand the test file either. Should I just $ make install anyway? t/99dbfile..File exists at t/99dbfile.t line 77. t/99dbfile..dubious Test returned status 17 (wstat 4352, 0x1100) after all the subtests completed successfully t/99dbfilestore.File exists at t/99dbfilestore.t line 73. t/99dbfilestore.dubious Test returned status 17 (wstat 4352, 0x1100) after all the subtests completed successfully On Mon, Mar 11, 2002 at 02:33:17PM -0500, Geoffrey Young wrote: Brian Lavender wrote: I am trying to install Apache::Session and it is failing on the DBD::Oracle tests. It is asking for a default user. Do I need to configure Oracle for a default user? Or do I need to set some environment variable with a user id and password? well, looking at t/99oracle.t (line 45) it looks like you need to define the following environment variables: ORACLE_HOME (of course) AS_ORACLE_USER AS_ORACLE_PASS HTH --Geoff -- Brian Lavender http://www.brie.com/brian/
Re: Apache::Session problem with DBD::Oracle
The tests were writing to an NFS mounted directory, and I think NFS was creating some lock files which prevented the directory from being written to. I moved the install to a non NFS mounted area, and it all worked. brian On Mon, Mar 11, 2002 at 12:00:47PM -0800, Brian Lavender wrote: Yup, that fixed it. I have another problem with the File portion. Seems that the test giving the following fail statements. I checked /tmp and there is a lock file. I am not sure about how File::Store all works, and I couldn't quite understand the test file either. Should I just $ make install anyway? t/99dbfile..File exists at t/99dbfile.t line 77. t/99dbfile..dubious Test returned status 17 (wstat 4352, 0x1100) after all the subtests completed successfully t/99dbfilestore.File exists at t/99dbfilestore.t line 73. t/99dbfilestore.dubious Test returned status 17 (wstat 4352, 0x1100) after all the subtests completed successfully On Mon, Mar 11, 2002 at 02:33:17PM -0500, Geoffrey Young wrote: Brian Lavender wrote: I am trying to install Apache::Session and it is failing on the DBD::Oracle tests. It is asking for a default user. Do I need to configure Oracle for a default user? Or do I need to set some environment variable with a user id and password? well, looking at t/99oracle.t (line 45) it looks like you need to define the following environment variables: ORACLE_HOME (of course) AS_ORACLE_USER AS_ORACLE_PASS HTH --Geoff -- Brian Lavender http://www.brie.com/brian/ -- Brian Lavender http://www.brie.com/brian/
Re: Apache::Session problems
On Thu, 2002-02-28 at 06:16, Domien Bakker wrote: Hello, I am trying to use Apache::Session to store http session information. The version number of Apache::Session is 1.54. It is running on Apache/1.3.20 (Unix) mod_perl/1.26 configured. ... Both methods resolve to the same error: [Thu Feb 28 11:46:39 2002] [error] Storable binary image v24.48 more recent than I am (v2.4) at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 351, at /usr/local/lib/perl5/site_perl/5.6.1/Apache/Session/Serialize/Storable.p m line 27 Does anybody knows a sollution to this problem, as far as I can see, all Apache::Session modules are up to date. This sounds like someone with a more recent version of Storable in their private lib has been testing sessions or something, since there's a mismatch of what is in the database versus the module trying to read the data. Be sure you've got the latest version of Storable installed. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Apache::Session problems
CW == Chris Winters [EMAIL PROTECTED] writes: On Thu, 2002-02-28 at 06:16, Domien Bakker wrote: [Thu Feb 28 11:46:39 2002] [error] Storable binary image v24.48 more recent than I am (v2.4) at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 351, at /usr/local/lib/perl5/site_perl/5.6.1/Apache/Session/Serialize/Storable.p m line 27 CW This sounds like someone with a more recent version of Storable CW in their private lib has been testing sessions or something, CW since there's a mismatch of what is in the database versus the CW module trying to read the data. Be sure you've got the latest CW version of Storable installed. I had a very similar problem, claiming that the data was serialised using version 50.xx; I think it indicates that the serialised data is somehow corrupt. I think I saw it because I had frozen a scalar that was not a reference, but I could be mistaken. But it is not a version problem, it just looks like one ;) Anway, after fixing some other bugs, blowing away the stored items and re-starting, the problem vanished. Good luck, - Adam
Re: Apache::Session
As an add-on to this, does anyone know if one could use MySQL HEAP (memory resident) tables for the session table? --Jon Robison Rob Bloodgood wrote: 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. Sorry if this is obvious, but do you have an index on your sessions table, on the sessionid column? Because, without an index, PG will have to do a full table read for each request. Which means the more sessions you get, the slower each lookup is going to be. Whereas, if you index SESSIONID (or SESSION_ID or whatever it is), it can go right to the row in question and return it immediately. L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
RE: Apache::Session
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. Sorry if this is obvious, but do you have an index on your sessions table, on the sessionid column? Because, without an index, PG will have to do a full table read for each request. Which means the more sessions you get, the slower each lookup is going to be. Whereas, if you index SESSIONID (or SESSION_ID or whatever it is), it can go right to the row in question and return it immediately. L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
Re: Apache::Session
Hi Milo,
thanks for your answer. I hope you will excuse, but I am not sure
whether I got you right.
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.
Guess this was another silly question, thus a thousand times thanks for
your help,
Chris
Re: Apache::Session
On Sun, 2002-02-24 at 02:43, Christoph Lange wrote:
Hi Milo,
thanks for your answer. I hope you will excuse, but I am not sure
whether I got you right.
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};
It is of no importance.
-jwb
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
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: 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
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
