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
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
On Fri, 12 Sep 2003 01:01:24 -0600 Eric Schwartz <[EMAIL PROTECTED]> wrote: Hi Eric, > I found a pretty useful article at > http://www.linuxjournal.com/article.php?sid=4143 on how to use > Apache::Session with Mason. I wrote a tutorial on session management with HTML::Mason and Apache::SessionManager (a wrapper around Apache::Session) available at: http://search.cpan.org/author/ENRYS/Apache-SessionManager-0.06/SessionManager/cookpod.pod#Apache::SessionManager_WITH_HTML::Mason I hope that it will be useful for you. Yes, I know, now there is a Mason extension to handle sessions (not in the Mason core), _but_: 1) when I wrote Apache::SessionManager, the extension wasn't yet available :-) (moreover A::SM has a session expiration/inactivity built-in cleanup mechanism) 2) with Apache::SessionManager you can use session object also in other Apache life request phases than Response phase (for example I need session in Authentication phase). With MasonX::Request::WithApacheSession you cannot (if I not mistake) 3) There is no way to use URI session tracking (session id is embedded in left side of the URI) In all other case, MasonX::Request::WithApacheSession works fine. by - Enrico
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'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
> 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
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 followed the article, more or less, and
ended up with this bit of code in my handler.pl to tie() my $session
variable to an Apache::Session class:
eval {
tie %HTML::Mason::Commands::session, 'Apache::Session::DBI',
($cookies{$session_cookie_name} ?
$cookies{$session_cookie_name}->value() : undef),
{
DataSource => $dbsource,
UserName => $dbuser,
Password => $dbpass
};
};
All the database variables are correct; I use them elsewhere with no
problem. The problem is that the session seems to be intermittent--
some pages seem to recognize it, others don't. This smelled a lot like
a problem where the session was getting set in one Apache instance and
not others, so I wondered if the session was getting stored in the
database correctly; after the previous eval, all I ever get in $@ is:
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.
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.
Mightily confused,
-=Eric
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
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
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 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 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 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.
--- 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.
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 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
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
Apache::Session extra record not write to Mysql db.
i am experiencing a weird problem with the use of apache::session::mysql
before i had three fields in table sessions : a_session,id,time in the DB.
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.
i am sure the username is present in the program. and i can add username record by
hand through
phpmysql without problem. so i dont think it's lack of database rights.
i also add a test record which just get timestamp. but it still don't get updated.
here is code.
sub set_cookie {
my $self = shift;
my $sid = shift;
$sid ||= '';
my %session;
&_open_db($self) unless $self->{DBH};
eval {
tie %session, "Apache::Session::MySQL", $sid,
{Handle => $self->{DBH}, LockHandle => $self->{DBH} };
};
croak("creating cookie error: [EMAIL PROTECTED]") if ($@);
$sid = $session{'_session_id'};
my $uname = &get_uname($self);
$session{'test'} = time();## this doesn't update 'test'
$session{'uname'} = $uname if $uname; ## this doesn't update 'uname'
$session{'time'} = time();## this updates 'time' record
my $cookie = Apache::Cookie->new(
$self->{request},
-name => 'ID',
-value => $sid,
-expires => $self->{CONFIG}->{cookie}->{cookie_expire},
);
$cookie->bake;
return $self->{request};
}
i feel i may have done something stupid but i couldn't find it...
Regards,
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
Apache::Session and pnotes
I am trying to retrieve/create an Apache::Session object for a given
user in the authentication phase, so the following handlers have them
available via pnotes. Sessions are stored in an Oracle database.
It seems, however, that Apache::Session objects stop being stored when I
put the session in pnotes() with a code analogous to this:
my $r = Apache::Request->instance(shift);
tie my (%session), 'Apache::Session::Oracle', undef,
{Handle => $class->dbh(), Commit => 1};
$r->pnotes(session => \%session);
Is there any gotcha regarding the kind of objects that can be passed
with pnotes? Or do you know what can be happening anyway if not?
-- fxn
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session
All the information that comes from the user-agent can be faked. So the session id is as insecure as any other identifier you get from the Browser. The only thing that could be used is the IP address, and as somebody said earlier, some ISPs and big company LANs may use different proxies for different requests (or use random routes for multiple output interfaces with some NAT gateway). Also the MAC address is not an option, any routing above layer 2? will loose the MAC address (if I'm not wrong). But there is somehow a way to get it more secure. Basically a key/IP combination would be very secure, it's just not useable for all users. Therefore you need to allow multiple IPs for the same session key. After you see that a user from another IP request a session id, you prompt a login again, and after successfull login you allow both IPs to access this session ID. Every user then basically has to login for each IP he uses; but it could be done more tricky, so the whole subnet that those two IPs are in is allowed. The security risk would be, that any other user going though the same gateway can steal the session just by knowing the correct session id. If the user is coming through proxies (as it IMHO normally is if you have several IPs for a session), you could even do more fancy stuff. Proxies should send an x-forwarded-for header, where they will add every IP that sent the request (can be multiple hosts). This way you could allow all those proxies for the session, but just for the same end IP (which should be the last IP from the x-forwarded-for field before any internal IP). Now we just have the security hole left, if someone is in control of those proxies, then he could steal the session from the original user. IMHO this is really everything you can get out of it; you even get it a lot securer for proxied users. The only problem are LANs that use random NAT-Gateways, which IMHO aren't widely spread ??. If you see anything more to make it secure, or if I'm totally wrong, I'm glad to hear !? greets, Marcel Greter -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
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
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
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
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
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
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
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 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: "Magic number checking on storable" error with Apache::Session::MySQL
Dan McCormick wrote: Hi, I'm running a site with Apache, MySQL, Mason, and Apache::Session::MySQL. I've been sporadically seeing this message in my error log: [Wed Jul 9 20:41:42 2003] [error] Magic number checking on storable string failed at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 364, at /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Serialize/Storable.pm line 27 Can anyone provide any clues as to why this might be happening? Is it implying the db data is corrupt? probably most likely unrelated to mod_perl, the error normally happens when you upgrade Storable and you try to read files that were created with older Storable version. perl users list/newsgroups is probably more appropriate for this issue. FYI, a cronjob deletes sessions that are more than 30 minutes old, but creating a session and then manually deleting it did not reproduce this error. Software specs: Apache 1.3.27 mod_perl 1.27 Apache::Session 1.54 MySQL 4.0.13 Thanks, Dan -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
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
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 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
Apache::Session::Lock::File hangs under Windows
Hello,
This may be OT, but may be not though Apache::Session is widely used under
mod_perl.
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.
I wrote to Jeffrey Baker a while ago but has no answer.
Possible patch is:
*** File.old Fri Sep 01 21:21:18 2000
--- File.pm Tue Apr 01 16:40:52 2003
***
*** 65,70
--- 65,72
$self->{opened} = 1;
}
+ if ($^O eq 'MSWin32' && $self->{read}){flock($self->{fh}, LOCK_UN)}
+
flock($self->{fh}, LOCK_EX);
$self->{write} = 1;
}
aa29
Re: [error] Insecure dependency in unlink while running with-Tswitch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pmline106
Thanks mate, Will re-examine the drawing board.. Marty - Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "Martin Moss" <[EMAIL PROTECTED]> Cc: "Cees Hek" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, February 28, 2003 2:52 PM Subject: Re: [error] Insecure dependency in unlink while running with-Tswitch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pmline106 > On Fri, 2003-02-28 at 09:10, Martin Moss wrote: > > I can't use Apache::DBI. > > I have multiple database connections.which are authenticated for different > > users. > > You're pretty much screwed then on the database front. > > > I just wanted to > > reduce the database lookups. > > If you just want to cache data, don't use Apache::Session for that. Use > IPC::MM, Cache::Mmap, Cache::FileCache, or MLDBM::Sync. > > - Perrin > >
Re: [error] Insecure dependency in unlink while running with-Tswitch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pmline106
On Fri, 2003-02-28 at 09:10, Martin Moss wrote: > I can't use Apache::DBI. > I have multiple database connections.which are authenticated for different > users. You're pretty much screwed then on the database front. > I just wanted to > reduce the database lookups. If you just want to cache data, don't use Apache::Session for that. Use IPC::MM, Cache::Mmap, Cache::FileCache, or MLDBM::Sync. - Perrin
Re: [error] Insecure dependency in unlink while running with -Tswitch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line106
heheheh, I can't use Apache::DBI. I have multiple database connections.which are authenticated for different users. Am wondering whether to bother with the persistance at all, I can retrieve all the data I need out of the database anyway, I just wanted to reduce the database lookups. Especially as I could be operating on 100's of records. I was using Apache::Session to generate session IDs and allow me to timeout users etc... Marty - Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "Martin Moss" <[EMAIL PROTECTED]> Cc: "Cees Hek" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, February 28, 2003 2:03 PM Subject: Re: [error] Insecure dependency in unlink while running with -Tswitch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line106 > On Fri, 2003-02-28 at 08:47, Martin Moss wrote: > > Is Apache::Session::DB_type Faster than Apache::Session::File? > > It depends on your disk, OS, and filesystem. It stores all the files in > one directory, which is quite slow on some systems and not a problem on > others. > > > I already use a lot of DB connections and I used Apache::Session::File to > > reduce this, > > Apache::Session::MySQL (or Oracle, etc.) do not require separate > database connections. If you already have a connection (which you would > if you use Apache::DBI), you just pass it to Apache::Session. > > - Perrin > >
Re: [error] Insecure dependency in unlink while running with -Tswitch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line106
On Fri, 2003-02-28 at 08:47, Martin Moss wrote: > Is Apache::Session::DB_type Faster than Apache::Session::File? It depends on your disk, OS, and filesystem. It stores all the files in one directory, which is quite slow on some systems and not a problem on others. > I already use a lot of DB connections and I used Apache::Session::File to > reduce this, Apache::Session::MySQL (or Oracle, etc.) do not require separate database connections. If you already have a connection (which you would if you use Apache::DBI), you just pass it to Apache::Session. - Perrin
Re: [error] Insecure dependency in unlink while running with -T switch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106
Is Apache::Session::DB_type Faster than Apache::Session::File?
I already use a lot of DB connections and I used Apache::Session::File to
reduce this,
Marty
- Original Message -
From: "Cees Hek" <[EMAIL PROTECTED]>
To: "Martin Moss" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, February 28, 2003 5:39 AM
Subject: Re: [error] Insecure dependency in unlink while running with -T
switch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line
106
> Quoting Martin Moss <[EMAIL PROTECTED]>:
>
> > All,
> > Can Anybody see what I'm doing wrong here?
> >
> > I have the following error :-
> > [error] Insecure dependency in unlink while running with -T switch at
> > /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106.
>
> The problem is not with your code, it is that Apache::Session::File
does
> not work in Taint mode. Apache::Session::Store::File gets the session ID
from a
> file (which means session_is is tainted), and then uses the tainted
session_id
> to delete a file (hence the unlink error).
>
> A quick fix for this is for you to untaint the session ID yourself
after
> the session has been unserialized. Put the following two lines right after
you
> tie the session:
>
> $session{_session_id} =~ /^([a-zA-Z0-9]+)$/;
> $session{_session_id} = $1;
>
> This probably should be fixed in Apache::Session itself as I am sure
other
> people will run into it.
>
> By the way, you really shouldn't be using Apache::Session::File
anyway for
> performance reasons. At least use Apache::Session::DB_File which most
likely
> doesn't suffer from this taint problem and will be much quicker.
>
> Cees
>
>
>
> >
> > When I run the following subroutine:-
> >
> > sub delete_session
> > {
> > my $self=shift;
> > my $session_id=shift;
> >
> > if ($session_id =~ /^(\w\w*)$/)
> > {
> > $session_id = $1; # $data now untainted
> > }
> > else
> > {
> > die "Bad Tainted data in $session_id";# log this somewhere
> > }
> >
> > die $self->{lh}->maketext("No Session_id given") unless ($session_id);
> >
> > my $t=time;
> > my %session;
> >
> > my $Directory = My::Conf::APACHE_SESSIONS_TMPDIR;
> > my $LockDirectory = My::Conf::APACHE_SESSIONS_LOCKDIR;
> >
> > $Directory="XX_GR_XX$Directory"."XX_GR_XX"; #e.g.
> > '/path/to/dir/'
> > $LockDirectory="XX_GR_XX$LockDirectory"."XX_GR_XX"; #e.g.
> > '/path/to/dir/'
> >
> > if ($Directory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
> > {
> > $Directory = $1; # $data now untainted
> > }
> > else
> > {
> > die "Bad Tainted data in $Directory";# log this somewhere
> > }
> >
> > if ($LockDirectory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
> > {
> > $LockDirectory = $1; # $data now untainted
> > }
> > else
> > {
> > die "Bad Tainted data in $LockDirectory";# log this
somewhere
> > }
> >
> > #Load an existing session
> > eval
> > {
> > tie %session, 'Apache::Session::File',$session_id,
> > {
> > Directory => Bficient::Conf::APACHE_SESSIONS_TMPDIR,
> > LockDirectory =>
Bficient::Conf::APACHE_SESSIONS_LOCKDIR,
> > };
> > };
> > if ($@)
> > {
> >die $self->{lh}->maketext("Couldn't Load Apache::Session -
\"[_1]\"
> > For '\"[_2]\"'",$@,$self->UserName);
> > }
> >
> > print STDERR "Just about to unlink\n";
> > tied(%session)->delete;
> > return 1;
> > }
> >
> >
>
>
>
Re: [error] Insecure dependency in unlink while running with -T switchat /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106
Quoting Martin Moss <[EMAIL PROTECTED]>: just a minor comment regarding untainting techniques. If do /(.*)/ to launder tainted vars as you did in: if ($Directory =~ /^XX_GR_XX(.*)XX_GR_XX$/) you can as well turn the taint mode off. For more info see: http://www.gunther.web66.com/FAQS/taintmode.html#clear_taint __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [error] Insecure dependency in unlink while running with -T switch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106
Quoting Martin Moss <[EMAIL PROTECTED]>:
> All,
> Can Anybody see what I'm doing wrong here?
>
> I have the following error :-
> [error] Insecure dependency in unlink while running with -T switch at
> /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106.
The problem is not with your code, it is that Apache::Session::File does
not work in Taint mode. Apache::Session::Store::File gets the session ID from a
file (which means session_is is tainted), and then uses the tainted session_id
to delete a file (hence the unlink error).
A quick fix for this is for you to untaint the session ID yourself after
the session has been unserialized. Put the following two lines right after you
tie the session:
$session{_session_id} =~ /^([a-zA-Z0-9]+)$/;
$session{_session_id} = $1;
This probably should be fixed in Apache::Session itself as I am sure other
people will run into it.
By the way, you really shouldn't be using Apache::Session::File anyway for
performance reasons. At least use Apache::Session::DB_File which most likely
doesn't suffer from this taint problem and will be much quicker.
Cees
>
> When I run the following subroutine:-
>
> sub delete_session
> {
> my $self=shift;
> my $session_id=shift;
>
> if ($session_id =~ /^(\w\w*)$/)
> {
> $session_id = $1; # $data now untainted
> }
> else
> {
> die "Bad Tainted data in $session_id";# log this somewhere
> }
>
> die $self->{lh}->maketext("No Session_id given") unless ($session_id);
>
> my $t=time;
> my %session;
>
> my $Directory = My::Conf::APACHE_SESSIONS_TMPDIR;
> my $LockDirectory = My::Conf::APACHE_SESSIONS_LOCKDIR;
>
> $Directory="XX_GR_XX$Directory"."XX_GR_XX"; #e.g.
> '/path/to/dir/'
> $LockDirectory="XX_GR_XX$LockDirectory"."XX_GR_XX"; #e.g.
> '/path/to/dir/'
>
> if ($Directory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
> {
> $Directory = $1; # $data now untainted
> }
> else
> {
> die "Bad Tainted data in $Directory";# log this somewhere
> }
>
> if ($LockDirectory =~ /^XX_GR_XX(.*)XX_GRRRRR_XX$/)
> {
> $LockDirectory = $1; # $data now untainted
> }
> else
> {
> die "Bad Tainted data in $LockDirectory";# log this somewhere
> }
>
> #Load an existing session
> eval
> {
> tie %session, 'Apache::Session::File',$session_id,
> {
> Directory => Bficient::Conf::APACHE_SESSIONS_TMPDIR,
> LockDirectory => Bficient::Conf::APACHE_SESSIONS_LOCKDIR,
> };
> };
> if ($@)
> {
>die $self->{lh}->maketext("Couldn't Load Apache::Session - \"[_1]\"
> For '\"[_2]\"'",$@,$self->UserName);
> }
>
> print STDERR "Just about to unlink\n";
> tied(%session)->delete;
> return 1;
> }
>
>
[error] Insecure dependency in unlink while running with -T switch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106
All,
Can Anybody see what I'm doing wrong here?
I have the following error :-
[error] Insecure dependency in unlink while running with -T switch at
/usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106.
When I run the following subroutine:-
sub delete_session
{
my $self=shift;
my $session_id=shift;
if ($session_id =~ /^(\w\w*)$/)
{
$session_id = $1; # $data now untainted
}
else
{
die "Bad Tainted data in $session_id";# log this somewhere
}
die $self->{lh}->maketext("No Session_id given") unless ($session_id);
my $t=time;
my %session;
my $Directory = My::Conf::APACHE_SESSIONS_TMPDIR;
my $LockDirectory = My::Conf::APACHE_SESSIONS_LOCKDIR;
$Directory="XX_GR_XX$Directory"."XX_GR_XX"; #e.g.
'/path/to/dir/'
$LockDirectory="XX_GR_XX$LockDirectory"."XX_GR_XX"; #e.g.
'/path/to/dir/'
if ($Directory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
{
$Directory = $1; # $data now untainted
}
else
{
die "Bad Tainted data in $Directory";# log this somewhere
}
if ($LockDirectory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
{
$LockDirectory = $1; # $data now untainted
}
else
{
die "Bad Tainted data in $LockDirectory";# log this somewhere
}
#Load an existing session
eval
{
tie %session, 'Apache::Session::File',$session_id,
{
Directory => Bficient::Conf::APACHE_SESSIONS_TMPDIR,
LockDirectory => Bficient::Conf::APACHE_SESSIONS_LOCKDIR,
};
};
if ($@)
{
die $self->{lh}->maketext("Couldn't Load Apache::Session - \"[_1]\"
For '\"[_2]\"'",$@,$self->UserName);
}
print STDERR "Just about to unlink\n";
tied(%session)->delete;
return 1;
}
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
md wrote: --- md <[EMAIL PROTECTED]> wrote: Is it possible to have row-level locking (as opposed to table-level or null locker) with MySQL 4.x and Apache::Session? You effectively have that already, since the MySQL locker only locks an individual session. Check the code. Looks like I get that with InnoDB automatically... You can use actual transactions there. Try starting with the Apache::Session::Store::Postgres module and hacking it a bit. There is no module available that was designed for use with Innodb MySQL tables. - Perrin
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
--- md <[EMAIL PROTECTED]> wrote: > Is it possible to have row-level locking (as opposed > to table-level or null locker) with MySQL 4.x and > Apache::Session? Looks like I get that with InnoDB automatically... __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
--- Perrin Harkins <[EMAIL PROTECTED]> wrote: > If you look at the actual contents of > Apache::Session::MySQL, you'll see > that it's essentially just a config file. There's > no need to be > concerned about using Flex, but you could easilly > code up your own > Apache::Session::MySQLNoLocks by changing a line in > the current module. Is it possible to have row-level locking (as opposed to table-level or null locker) with MySQL 4.x and Apache::Session? -- md __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
--- Perrin Harkins <[EMAIL PROTECTED]> wrote: > It would be. Frankly, there is no value to the kind > of mutual exclusion > that the Apache::Session locking provides in a > typical web application. > If you use the null locker you will still get > atomic updates, but you > will have the possibility of someone opening up two > browser windows, > hitting submit in both, and having the last save > overwrite the values > from the first one, possibly losing some changes. > In most web apps, > that is not a big problem. We talked about this, but in our case, I don't believe this will be an issue. > Note that this could become a problem if you use > sessions incorrectly by > putting tons of data in them. Most of your data > should have its own > normalized tables and persistence code. Sessions > are for storing tiny > little bits of data like the user's ID or some form > data that from a > multi-page form that hasn't been committed yet. We put almost nothing in the session other than the user id. There are three apps sharing the same session table, and I believe one app may put two or three other things other than the user id (like current page id and affiliate id...both which I should be able to remove someday:)...but never-the-less, very little data in the session. I've gotten most of my sessioning information from this list (and you), so I believe we are session correctly :) > If you look at the actual contents of > Apache::Session::MySQL, you'll see > that it's essentially just a config file. There's > no need to be > concerned about using Flex, but you could easilly > code up your own > Apache::Session::MySQLNoLocks by changing a line in > the current module. That's what I figured and that's what I'm going to do. Thanks again, -- md __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
md wrote: Also, we'll soon be adding a substantial number of users to our system and I wonder if it would be wise to move away from the table locking that is currently being used with Apache::Session::MySQL. It would be. Frankly, there is no value to the kind of mutual exclusion that the Apache::Session locking provides in a typical web application. If you use the null locker you will still get atomic updates, but you will have the possibility of someone opening up two browser windows, hitting submit in both, and having the last save overwrite the values from the first one, possibly losing some changes. In most web apps, that is not a big problem. Note that this could become a problem if you use sessions incorrectly by putting tons of data in them. Most of your data should have its own normalized tables and persistence code. Sessions are for storing tiny little bits of data like the user's ID or some form data that from a multi-page form that hasn't been committed yet. I'm looking at Apache::Session::Flex and setting "Lock=>'Null'"...however, I get the impression from an old email (see below) that Flex is for debugging only. If you look at the actual contents of Apache::Session::MySQL, you'll see that it's essentially just a config file. There's no need to be concerned about using Flex, but you could easilly code up your own Apache::Session::MySQLNoLocks by changing a line in the current module. First, any benchmarks on what kind of load I can realistically use with Apache::Session::MySQL? It all depends on how much data you put in (lots of data in the session will slow things down) and how fast your database is. At eToys we used a slightly hacked version of Apache::Session::DBI with Oracle and it handled more traffic than most sites will ever see. - Perrin
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
On Tuesday, February 25, 2003, at 11:55 AM, md wrote: We're using Apache::Session::MySQL (Apache::Session 1.54) and occassionaly see long lock times. I had a similar problem a few months ago with Apache::Session::Postgres. I occasionally had Apache processes hang, and a quick ps aux shows a stalled query on the sessions table. I ended up dropping it for Apache::Session::File. I'm looking at Apache::Session::Flex and setting "Lock=>'Null'"...however, I get the impression from an old email (see below) that Flex is for debugging only. I've not seen the problems since I switched to Apache::Session::File, but I would much prefer using the Postgres module, as it complicates my user's installation. Could the MySQL and Pg implementations have the same problem? Cory 'G' Watson http://gcdb.spleck.net
Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
We're using Apache::Session::MySQL (Apache::Session 1.54) and occassionaly see long lock times. Also, we'll soon be adding a substantial number of users to our system and I wonder if it would be wise to move away from the table locking that is currently being used with Apache::Session::MySQL. I'm looking at Apache::Session::Flex and setting "Lock=>'Null'"...however, I get the impression from an old email (see below) that Flex is for debugging only. First, any benchmarks on what kind of load I can realistically use with Apache::Session::MySQL? Is moving to Apache::Session::Flex a good choice (and then we could also change the session table to INNODB), or should I create my own Apache::Session::MySQL-type module by changing Lock => 'Null'? I didn't see much discussion on this in the archives, so if it is there, please point me to the thread... Thanks... -- > On Thu, 11 Oct 2001, Jeffrey W. Baker wrote: > >Regarding Flex, nobody uses it. It is for debugging. >If you have a >particular variant of Flex that you use all the time >(very likely), you >can code up a 6-line module to make a real >implementation like all the >other session modules. > >Flex is for debugging, period. __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
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
Apache::Session and Postgres
I'm trying to use Apache::Session::Postgres and not having much luck.
When I try to create a new session like this:
use Apache::Session::Postgres;
tie %sess, 'Apache::Session::Postgres', undef, {
Handle => $self->dbh, Commit => 1
};
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 tried defining the method
like this:
sub get_lock_manager {
my $self = shift;
return $self->{lock_manager};
}
and the error message changed to:
Can't call method "acquire_read_lock" on an undefined value
So then I tried:
sub get_lock_manager {
my $self = shift;
return(new Apache::Session::Lock::Null $self)
}
but got:
Can't locate object method "get_object_store"
I'm wondering if Apache::Session::Postgres is not actively maintained
and has fallen out of sync with the core Apache::Session API.
The reason I selected Apache::Session::Postgres was twofold, I happened
to be using Postgres and whereas Apache::Session::DBI requires a
DataSource + UserName + Password, Apache::Session::Postgres will
accept an open database handle (according to the docs). Would I be
better off trying to hack that facility into Apache::Session::DBI?
or is there likely to be some good reason why it doesn't support it
already?
Regards
Grant
RE: mod_perl 2 apache::session and "or die"
Thanks Perrin, Yes I am using Apache::Registry and you were right, it was just a scoping problem - I can't believe I didn't see it before. Everything is finally working as it should!!! -Chris >> -Original Message- >> From: Perrin Harkins [mailto:[EMAIL PROTECTED] >> Sent: Friday, February 21, 2003 12:02 PM >> To: Chris Faust >> Cc: Modperl >> Subject: Re: mod_perl 2 apache::session and "or die" >> >> >> Chris Faust wrote: >> > I think it is in the locking as if I let things hang long >> enough and then >> > shut down Apache, I get a error of: >> > >> > Can't call method "disconnect" on an undefined value at >> > /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm >> line 89 during >> > global destruction. >> >> That's a good sign. It is trying to cleanly disconnect from the >> database when you shut down the server. >> >> I think my initial guess was wrong. This is probably just a scoping >> problem in your code. I suspect you are either putting the session >> object in a global or using it in a closure. Try to reduce the section >> of code that uses Apache::Session to a very small example that >> reproduces this problem and post it here. Also, are you using >> Apache::Registry? >> >> - Perrin
Re: mod_perl 2 apache::session and "or die"
Chris Faust wrote: I think it is in the locking as if I let things hang long enough and then shut down Apache, I get a error of: Can't call method "disconnect" on an undefined value at /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 89 during global destruction. That's a good sign. It is trying to cleanly disconnect from the database when you shut down the server. I think my initial guess was wrong. This is probably just a scoping problem in your code. I suspect you are either putting the session object in a global or using it in a closure. Try to reduce the section of code that uses Apache::Session to a very small example that reproduces this problem and post it here. Also, are you using Apache::Registry? - Perrin
RE: mod_perl 2 apache::session and "or die"
Thanks Perrin, I've been trying to use Apache::DB to track down the problem, but I'm not having a lot of luck. I think it is in the locking as if I let things hang long enough and then shut down Apache, I get a error of: Can't call method "disconnect" on an undefined value at /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 89 during global destruction. Which is Apache::Session::Lock:MySQL I'm still no closer as to figuring out why though. -Chris >> -Original Message- >> From: Perrin Harkins [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, February 19, 2003 11:55 AM >> To: Chris Faust >> Cc: Modperl >> Subject: Re: mod_perl 2 apache::session and "or die" >> >> >> Chris Faust wrote: >> > All works well except when there is any kind of problem in the >> script where >> > the condition will die.. >> [...] >> > When this happens everything to do with that script is >> unresponsive - I know >> > that is a little vague but that is the best way I can describe it. What >> > happens is the error comes up (standard server error) and that >> is the last >> > thing that is logged, if you try to go back and refresh the >> hourglass will >> > go for hours and nothing happens and nothing is ever logged >> >> It sounds like a locking problem to me. I'm guessing that mod_perl 2 is >> not calling the right hooks when it traps a die() to trigger the DESTROY >> method in Apache::Session which releases all locks. You can find out >> exactly what's going on if you run it in the debugger (Apache::DB) or >> throw some debug logging into Apache::Session to find out where it gets >> stuck. This is the beauty of having the source code. >> >> - Perrin >>
Re: mod_perl 2 apache::session and "or die"
Perrin Harkins wrote: Chris Faust wrote: All works well except when there is any kind of problem in the script where the condition will die.. [...] When this happens everything to do with that script is unresponsive - I know that is a little vague but that is the best way I can describe it. What happens is the error comes up (standard server error) and that is the last thing that is logged, if you try to go back and refresh the hourglass will go for hours and nothing happens and nothing is ever logged It sounds like a locking problem to me. I'm guessing that mod_perl 2 is not calling the right hooks when it traps a die() to trigger the DESTROY method in Apache::Session which releases all locks. You can find out exactly what's going on if you run it in the debugger (Apache::DB) or throw some debug logging into Apache::Session to find out where it gets stuck. This is the beauty of having the source code. I've noticed that there are several issues with END blocks with the current cvs, when the used perl is threaded. Could be that DESTROY misbehaves too. I've planned to investigate these issues, but didn't have a chance to yet. Hopefully someone will beat me to it. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl 2 apache::session and "or die"
Chris Faust wrote: All works well except when there is any kind of problem in the script where the condition will die.. [...] When this happens everything to do with that script is unresponsive - I know that is a little vague but that is the best way I can describe it. What happens is the error comes up (standard server error) and that is the last thing that is logged, if you try to go back and refresh the hourglass will go for hours and nothing happens and nothing is ever logged It sounds like a locking problem to me. I'm guessing that mod_perl 2 is not calling the right hooks when it traps a die() to trigger the DESTROY method in Apache::Session which releases all locks. You can find out exactly what's going on if you run it in the debugger (Apache::DB) or throw some debug logging into Apache::Session to find out where it gets stuck. This is the beauty of having the source code. - Perrin
mod_perl 2 apache::session and "or die"
I'm having a problem since installing Apache::Session All works well except when there is any kind of problem in the script where the condition will die.. For example: $db->execute() or die... open yadda or die.. $db->prepare() or die... etc. When this happens everything to do with that script is unresponsive - I know that is a little vague but that is the best way I can describe it. What happens is the error comes up (standard server error) and that is the last thing that is logged, if you try to go back and refresh the hourglass will go for hours and nothing happens and nothing is ever logged - if you close all windows and try again then the same thing just happens, it goes forever and nothing happens or is logged. It doesn't seem to matter where the die is, if I'm using another module (for example) HTML::Template and it dies on bad params because I didn't define something some temple var then that is it.. I can't get to that script again until I reload Apache. This only happens when I'm using Apache::Session::MySQL and I'm not doing anything strange with it, I grab the cookie if its there and authenticate them. There is nothing I'm doing in the session that relates to the errors so I don't understand why everything just dies as it does. This happens on my RH7.3/1.3 install and on my RH8/2.0 install. One other thing I should mention, when this happens it only kills the script in that specific location that is defined in the httpd.conf, in otherword something running in /cgi-bin1/ has died and crashed, I can't get to it or do anything with it - during this time everything running in /cgi-bin2/ is running along just fine without a issue (although what is in /cgi-bin2/ isn't using Apache::Session but it is using the same mySql DB). Any ideas? Thanks -Chris
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
Apache::Session::File hangs
Hi!
The following code hangs after reloading and the try to tie again the
previously created session! WHY?
package Loop;
use strict;
use Apache;
use Apache::Session::File;
use CGI qw(:cgi);
use Devel::Symdump;
use Data::Dumper;
use vars qw(
$id $sID
$lockDir
%session $sessionDir
);
sub handler{
if(defined ($id = param("sID")) && -f
"/usr/local/httpd/htdocs/action/sessions/$id"){
print STDERR "found $id :-}\n";
$sID =1;
eval{
tie %session, 'Apache::Session::File', $id,{
Directory => '/usr/local/httpd/htdocs/action/sessions',
LockDirectory => '/usr/local/httpd/htdocs/action/lock'
};
};
}
else{
eval{
tie %session, 'Apache::Session::File', undef,{
Directory => '/usr/local/httpd/htdocs/action/sessions',
LockDirectory => '/usr/local/httpd/htdocs/action/lock'
};
};
$id = $session{_session_id};
}
if($@){print STDERR "oops $@\n";}
untie %session;
print STDERR "$id redirecting2:
http://$ENV{'HTTP_HOST'}$ENV{'SCRIPT_NAME'}?sID=$id\n";
print redirect "http://$ENV{'HTTP_HOST'}$ENV{'SCRIPT_NAME'}?sID=$id";
}
1;
on STDERR I get:
c838622a5e5ec2b39a26c67b6731188f redirecting2:
http://localhost/action/leer.html?sID=c838622a5e5ec2b39a26c67b6731188f
found c838622a5e5ec2b39a26c67b6731188f :-}
my .htaccess :
SetHandler perl-script
PerlHandler Loop
Thanks,
Axel
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
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.
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]
Re: Anyone ever have Apache::Session::File files getting corrupted?
> I think most people don't use Apache::Session::File in production. It's
> more of a testing thing. In your situation, you would probably get
> great performance from MLDBM::Sync with SDBM_File. I'd suggest trying
> that if you can't determine the cause of the Apache::Session::File issues.
Not to say that the other options won't work, but we're using
Apache::Session::File in production with no issues, handling in excess of
30 hits per second. It works fine, and it's easy to keep old session
files cleaned up with a simple cron job that finds and deletes session
files older than some limit.
During development we also noticed race conditions with near-simultaneous
pageloads into framesets. Try the 'Transaction' option when you tie to
the session - here is how that part of our mod_perl handler looks:
# NOTE:
# At this point, $session_id is either set to some
# value from a cookie (for an existing session)
# or it is "undef"
my %session = ();
my $opts = {
Directory => "$SESSIONFILEROOT/$site",
LockDirectory => "$SESSIONLOCKROOT/$site",
Transaction => 1,
};
eval {
tie %session, 'Apache::Session::File', $session_id, $opts;
};
if ( $@ ) {
# Session tie failed for some reason. If it was because
# an existing session is invalid, create a new session:
if ( $@ =~ /^Object does not exist in the data store/ ) {
$session_id = undef;
eval {
tie %session, 'Apache::Session::File', $session_id, $opts;
};
}
if ( $@ ) {
# Totally failed to create the session - bail out:
$r->log_error( "Tie failed: $@");
return SERVER_ERROR;
}
}
HTH,
Larry Leszczynski
[EMAIL PROTECTED]
Re: Anyone ever have Apache::Session::File files getting corrupted?
[EMAIL PROTECTED] wrote: Anyway, my question for now is whether anyone has seen corruption like this with Apache::Session::File in your typical multi-user mod_perl web app environment? I think most people don't use Apache::Session::File in production. It's more of a testing thing. In your situation, you would probably get great performance from MLDBM::Sync with SDBM_File. I'd suggest trying that if you can't determine the cause of the Apache::Session::File issues. - Perrin
Anyone ever have Apache::Session::File files getting corrupted?
This is going to be a somewhat preliminary "feeler" post because we are not yet able to fully describe or recreate the bug we're seeing, but I'm hoping some of you have seen something similar. We use Apache::Session::File as the storage module for our Apache::Session sessions. I have written an object (RMS::Session where RMS is our app) that basically is just a wrapper class for the Apache::Sessions. When I instantiate a new RMS::Session, it goes and ties to the actual Apache::Session, gets a hold of the session hash, populates it's member variables with values from the session hash, and unties/undefs the session hash. Thus we end up with a perl object representing our session with a friendly OO interface for our developers that they are used to, and the real session is freed for use by other requests. Everytime I instantiate a new RMS::Session, I timestamp the Apache::Session and I increment a 'retrievals' variable. Pretty much every request into our app needs to look at the session for something, so the end result is that sessions are being tied and written a lot. In some cases, a user will click into an area of our application that has say three frames, and the content of all three frames will go and look at the session, so three requests for the same session could come in at the same time, so it's probably exercising the locking mechanism fairly well. Here's the basic problem we're seeing...our sessions have a very well defined set of variables in them so the size of the session file is very predictable - in our case, they all are between 320-360 bytes at all times. What seems to be happening is that sometimes (more on this later) the files get written out in a corrupted state, and I've noticed it's a well-defined "corruption" to where the session file will shrink to a size of either 150 bytes or 63 bytes. Once this happens, the session is corrupted, in that I can no longer successfully retrieve any information from it. The session is still there, but the contents have been completely garbled. Unfortunately, it's neither predictable nor easy to reproduce. First, it only happens occasionally. we haven't yet found one set of actions that we can take and cause it to happen every time. One test we use to demonstrate it is to simply log in and out several times. Sometimes, 7 or 8 logins will go by without incident, and then the 9th will cause a corrupted session. Other times, 10 logins in a row will lead to a corrupted session. Secondly, it happens far more frequently on our production server than our development server (same exact code and versions of perl and all modules). I've begun to suspect that perhaps it only happens after a certain period of latency. Since our production server has a lot more data in it's database, operations tend to take much longer than they would during development. Perhaps this means that there's more opportunity in production for a request to ask for a session that's still held/locked by another child request. Like I said, it's still very preliminary. Anyway, my question for now is whether anyone has seen corruption like this with Apache::Session::File in your typical multi-user mod_perl web app environment? We're just trying to narrow down the possibilities since it's been two days of four engineers trying to come up with any sort of recipe for reliable reproduction or pattern to the bug with no luck so far. Thanks, Fran
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 > 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
> So by user nobody, you mean in the httpd.conf file in the 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
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 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
> 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
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
> 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
Apache::Session::MySQL
Is this the correct list for help with Apache::Session::MySQL? Thanks, Richard.
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
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
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
--- 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: New module : Apache::Session::Manager
Hi Enrico After posting, I looked at Apache::AuthCookie for the first time - don't why I hadn't looked at it before - to find that I was, indeed, duplicating a lot of work that has been done before. Didn't I feel foolish! It looks like Perrin may have to write a "...why not to write your own session manager article..." to compliment his Templating article. Apologies for this. I'll haul my sorry ass back to my machine now. Clint
Re: New module : Apache::Session::Manager
On 16 Nov 2002 13:24:13 +0200 Clinton Gormley <[EMAIL PROTECTED]> wrote: > I've written a new module as a wrapper around Apache::Session which > provides short term (ie session) tracking (which is something that > Apache::SessionManager and Apache::SessionX provide), but this adds long > term user tracking, and methods to aid login, logout etc. > > > I would appreciate feedback, not least of all, what it should be > called! Apache::SessionManager exists already, and I realise that > calling this module Apache::Session::Manager will cause confusion, so > please... Dear Clinton, I think that the name you've chosen (Apache::Session::Manager) is wrong :-( not because it will cause confusion with my Apache::SessionManager module, but because Apache::Session::* namespace is informally reserved to Apache::Session sub components like data storage, serializers or ID generators. Your (and my, of course) session manager module hasn't any relationships with these. This name adds only a little bit of confusion on wrong (historically) Apache::Session namespace - there is a direct tie between Apache::Session and mod_perl? ;-) When I started with my little project I've first searched on CPAN and the most similar module I founded was the AxKit-XSP-Session. Unfortunately this is a session manager plugin for AxKit and my goal was to develope a module with no glue with other applications server that the mod_perl itself. Then I've chosen Apache::SessionManager (I've discarded Apache::Session::Manager name, of course) but before putting the first line of code on CPAN, I have sended various RFCs to mod_perl and [EMAIL PROTECTED] mailing lists, to comp.lang.perl.misc and comp.lang.perl.modules: this is the standard way to contribute to CPAN. See ml/news archives for the complete threads [...] I have done a (very) quick look to your code and I've seen some likeness with Apache::AuthCookie and/or Apache-AxKit-Plugin-Session. If you were doing something like this, you could probably start with one of the Auth* modules, which already do a good job of handling things. I am also working to add this features not to my module but adding session management in Apache::AuthCookie! Moreover, I agree about a possibility of the integration with your additional features into my Apache::SessionManager. Regards - Enrico
New module : Apache::Session::Manager
I've written a new module as a wrapper around Apache::Session which provides short term (ie session) tracking (which is something that Apache::SessionManager and Apache::SessionX provide), but this adds long term user tracking, and methods to aid login, logout etc. It is meant to be subclassed, so that you can add your own database access methods to the module - full examples included! I would appreciate feedback, not least of all, what it should be called! Apache::SessionManager exists already, and I realise that calling this module Apache::Session::Manager will cause confusion, so please... README is below. The module is available from : http://cpan.perl.org/modules/by-authors/id/D/DR/DRTECH/Apache-Session-Manager-0.02.tar.gz thanks Clinton Apache/Session/Manager version 0.02 === Apache::Session::Manager provides a wrapper around Apache::Session which adds the following : * Short term session tracking using cookies or URLs (query string / POST data rather than URL munging) * Long term user tracking with cookies and query string * User recognition through query string (eg from an emailed link) * Login, logout, create new account, remove cookies - all operating with your favourite database and schema! It needs to be subclassed by your own module, which provides the methods to interact with your database - ie you can integrate this module into you own database schema. Apache::Session::Manager is not a "drop in" module - it requires a bit of work on your part to make it work - but once that work is done, it makes a lot of user and session management easy. Any website that wants to have any sort of long term relationship with a user needs to be able to track a user through a session, allow the user to register, and issue them with a password challenge before allowing them to view restricted pages... which is exactly what this module does. All you need to provide is 6 subroutines which speak to your database to perform a few simple functions (looking up a username etc).
[PATCH] Apache::Session
Hi Jeffrey,
I've found a little bug in clean method of Apache::Session::Lock::File when
it checks lockfiles last access time.
In effects the result of the expression (file ./Session/Lock/File.pm, line 136)
(stat($dir.'/'.$file))[8] - $now
is always negative and lock dir cleanup isn't done.
The patch simply inverts the check (also I've attached it)
Bye,
Enrico
PS: Sorry for this re-post, but I've submitted this patch also a few months
ago with no response ;-)
-
--- File.pm Sat Sep 2 00:21:17 2000
+++ File.pm-patched Sat Mar 30 10:38:54 2002
@@ -133,7 +133,7 @@
my @files = readdir(DIR);
foreach my $file (@files) {
if ($file =~ /^Apache-Session.*\.lock$/) {
-if ((stat($dir.'/'.$file))[8] - $now >= $time) {
+if ($now - (stat($dir.'/'.$file))[8] >= $time) {
open(FH, "+>$dir/".$file) || next;
flock(FH, LOCK_EX) || next;
unlink($dir.'/'.$file) || next;
Apache-Session-1.54-patch
Description: Binary data
Apache::Session - suggestion for man page
1)I am using Apache::Session::File to maintain state information (just a user_id and a few small items). 2)The man page for Apache::Session indicates that the following regexp should be used to find the session cookie. $cookie =~ s/SESSION_ID=(\w*)/$1/; 3)This $cookie value is then used in a tie statement. I was having intermittant trouble with MD5.pm dying and giving me internal server errors. The log file looked like this: [Wed Oct 16 21:45:47 2002] [error] Died at /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Generate/MD5.pm line 40. 4)I found that when I had multiple cookies MD5 would always bomb out because the regexp was just stripping out the words SESSION_ID= 5)I added a few print STDERR statements and the log file looked like this: in common_session_utility 0 cookie is laptop=P&admin&Hash&9fa0065cd19a168c598a6ada6ec11917&U&Administrator; SESSION_ID=d1a16efb540ac0cb16236f7782183c12 cookie is laptop=P&admin&Hash&9fa0065cd19a168c598a6ada6ec11917&U&Administrator; d1a16efb540ac0cb16236f7782183c12 after regexp in common_session_utility 1 IN GENERATE MD5 session date is laptop=P&admin&Hash&9fa0065cd19a168c598a6ada6ec11917&U&Administrator; d1a16efb540ac0cb16236f7782183c12 [Wed Oct 16 21:45:47 2002] [error] Died at /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Generate/MD5.pm line 40. 6)After I changed the regexp, things started working well enough. $cookie =~ s/^.*SESSION_ID=(\w*).*$/$1/; 7)I suggest that the man page for Apache::Session so that the regexp example accomodates sites with multiple cookies being set. I hope this makes some sense. Regards, Rodney Hampton
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
Apache::Session and user sessions
Im looking at Apache::Session and trying to figure out what it does. What I
want
to do is tie sessions to a particular record in a database table. 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.
I have a table with some basic user information (first name, last name,
address,
phone number, etc...). Apache::Session says I have to have a column named id
and one called a_session. It says that the id column must be primary key,
but
my table already has a primary key, an auto-increment column for the userid.
What i did was created the two columns, and hoped it would work without the
id
column being the primary key. I stuck a 32 character string I got from
Sys::UniqueID in the id column and tried to do:
...
my($dbh) = DBI->connect( MISANet::Util::DatabaseOpts::getOpts() );
my($id) = '3D898BE8C0A80125229B0001';
my(%hash);
tie %hash, 'Apache::Session::MySQL', $id, {
Handle => $dbh,
LockHandle => $dbh
};
$r->content_type('text/html');
$r->send_http_header();
$r->print( "DummyHello,
$hash{firstName} $hash{lastname}" );
...
in a perlHandler where firstName and lastName are columns in the database.
%hash
never gets defined and $! dosent report anything.
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) What do
you guys think? Am I using Apache::Session wrong, or are there better
alternatives than what Ive came up with?
Thanks in advance for the input.
Todd W.
_
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
HTML::Mason + Apache::Session problem
Hi I am running a RedHat 7.3 server with kernel 2.4.18, Apache 1.3.26, mod_perl 1.26-5 and Apache::Session and HTML:Mason-1.05 modules. When I try to start apache i get the error message Starting httpd: Subroutine status_mason redefined at /usr/lib/perl5/vendor_perl/5.6.1/i386-linux/Apache/Status.pm line 50. But the server starts and operates. This bug is said to be fixed in Mason-0.85 but as you can see I still get it. I have the same components and code piece running on RedHat 7.0. The other problem is, on the same system I have an authentication/session information structure on my website built using Apache::Session. I manage to log on with the right username and password and the Apache-Session file is created under /tmp with owner as apache:apache and file rights as 644. When I try to access the submenus after the initial login process, the server acts as if it cannot read the session files and does not grant me access. Well the the strangest thing is I can access the submenus after clicking on the link for 2-3 times. The first 1 or 2 does not grant access, but the last one always seems to work. This seems to me that apache cannot or does not read from the same Session file each time. Can anyone please help? Thanks.
Mason 1.05 + Apache::Session problem!
HiI am running a RedHat 7.3 server with kernel 2.4.18, Apache 1.3-26, mod_perl 1.26-5 and Apache::Session 1.53 and HTML::Mason-1.05 modules. When I try to start apache i get the error message:Starting httpd: Subroutine status_mason redefined at /usr/lib/perl5/vendor_perl/5.6.1/i386-linux/Apache/Status.pm line 50.But the server starts and operates. This bug is said to be fixed in HTML::Mason-0.85 but as you can see I still get it. BTW I have the same components and code piece running on RedHat 7.0, apache 1.3-2x, mod_perl and Apache::Session 1.53 an HTML::Mason-1.05 modules.The other problem (and the main) is, on the same system I have an authentication/session information structure on my website built using Apache::Session. I manage to log on with the right username and password. Apache-Session file for the session is created under /tmp with owner as apache:apache and file rights as 644. But when I try to access the submenus from the main one, after the initial login process, the server acts as if it cannot read the session files and does not grant me access. The strangest thing is that I can access the submenus after clicking on the link for 2-3 times. The first 1 or 2 does not grant access, but the last one always seems to work. This seems to me that apache cannot or does not read from the same Session file each time.Can anyone please help? Thanks.UY
RE: [OT] Apache::Session and Win32
Greetings. [...] > > > Rob Bloodgood wrote: > > >I tried Apache::Session::File, but after MUCH hair-pulling > it seems that the > >Lock mechanism is COMPLETELY hosed (things are either never > locked or never > >unlocked, or something...) > > > > > > AFAIK, Win32 has no flock. > I once ran into the same problem - and my (superficial) analysis was that locks are not released for a reason that appears related to the multithreaded nature of the server...(for me, it was Apache). However, perlopentut says: "Perl's most portable locking interface is via the flock function, whose simplicity is emulated on systems that don't directly support it, such as SysV or WindowsNT. The underlying semantics may affect how it all works, so you should learn how flock is implemented on your system's port of Perl." And perl's flock certainly appear to work between different processes on NT. FOr the record, I eventually resorted to null locking as well. Cheers, alf
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?
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?
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?
"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 A&M CIS Operating Systems Group, Unix
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?
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?
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?
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?
Jie Gao wrote: > There are cases in which it is desirable to expire an entry which > hasn't been used for a certain period of time; authenticated sessions > data, for example. Okay, so you're looking for a session module rather than a cache. Apache::Session doesn't handle expiration, but you could add it, as many here have. You could also just use one of the general-purpose storage modules like MLDBM::Sync, BerkeleyDB, or the storage modules in Cache::Cache (like Cache::FileBackend) and then add expiration. Those are all generic storage modules with no cache-specific stuff in their APIs. - Perrin
Re: Apache::Session - What goes in session?
On Tue, 20 Aug 2002, Perrin Harkins wrote: > Jie Gao wrote: > > I wish some of these modules would be able to "touch" cached data so that > > it would expire cache entries on "last-accessed" rather than on the time > > the entries were created. > > Why? People used to do that with cached because they had limited space > and wanted to purge the cache with an LRU algorithm to keep size down, > but disk space is too cheap to worry about now. > > If an item in the cache is okay to stay there as long as people are > accessing it, you are essentially saying that cached items never become > invalid. In that case, why bother ever deleting any of them? There are cases in which it is desirable to expire an entry which hasn't been used for a certain period of time; authenticated sessions data, for example. Absolute expiration is indeed needed, as well. Regards, Jie
Re: Apache::Session - What goes in session?
Jie Gao wrote: > I wish some of these modules would be able to "touch" cached data so that > it would expire cache entries on "last-accessed" rather than on the time > the entries were created. Why? People used to do that with cached because they had limited space and wanted to purge the cache with an LRU algorithm to keep size down, but disk space is too cheap to worry about now. If an item in the cache is okay to stay there as long as people are accessing it, you are essentially saying that cached items never become invalid. In that case, why bother ever deleting any of them? - Perrin
Re: Apache::Session - What goes in session?
On Tue, 20 Aug 2002, Perrin Harkins wrote: > Date: Tue, 20 Aug 2002 13:12:29 -0400 > From: Perrin Harkins <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Dave Rolsky <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: 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 wish some of these modules would be able to "touch" cached data so that it would expire cache entries on "last-accessed" rather than on the time the entries were created. Regards, Jie
