ok - u can convince me that u are having problems with sessions.
u are not necessarily convincing me that there would be no problems if
sessions were somehow written into embperl. unless, however, u are saying that
Gerald is just a much better programmer than Jeffrey. if that were the case, then
Gerald would have ignored Apache::Session and written sessions himself.
if one box is having problems, and the other box is not, we should focus
our attention on figuring out what the problem with the development box is,
and how it is different, or the environment or usage is different from the
production box. if it is a problem with Apache::Session, then it can be
patched and a notice sent to the Jeffrey for inclusion in the next release. this
process wouldn't be any different if there were no Apache::Session and all of its
functionality were included in Embperl, unless it turns out to be an Embperl <=>
Apache Session interfacing problem.
Joe Lauer wrote:
> I've been using Embperl for over 1 and 1/2 years and have had very mixed
> results regarding sessions.
>
> They seemed to run okay on RedHat, but FreeBSD has given me problems. Try
> explaining this one:
>
> I had two servers - both FreeBSD and both fresh installs. I installed the
> production, setup Embperl, installed modules, etc... I then setup the
> development with the same steps I did on the first one. The production runs
> great, but the development's sessions get messed up all the time. I can't
> explain why since everything as far as I know is exactly the same. But then
> again, it goes back to the fact that I'm running Embperl 1.2.1 and stuff
> like Apache::Session 1.53 doesn't work with it. Or at least that is what
> Gerald explained. So, oh well, for backwards compatability with
> improvements in packages like Apache::Session. Sometimes mission critical
> pieces like sessions might necessitate its own code if many others are
> having similiar problems to me. I'm not a lone person with session
> problems, the traffic flow on this list typically is in regards to sessions.
>
> -joe
>
> -----Original Message-----
> From: ___cliff rayman___ [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 09, 2000 4:01 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Embperl and Sessions
>
> i've been using embperl with Apache::Session on my site for over a year with
> very few problems. makes more sense to utilize a standard package then it
> does
> to have a proprietary one, given that it is effective and efficient, which i
> believe it is.
> the improvements to Apache::Session benefit embperl as well as everyone
> else. if sessions are difficult to get up and running, it is because of the
> flexibility
> that Apache::Session provides. remove the flexibility, and it is easier to
> install
> and run, but now, it may not be the best solution for your use.
>
> Joe Lauer wrote:
>
> > Gerald,
> >
> > With constant flow on this list about session problems, have you
> considered
> > just having Embperl handle everything for sessions? I'm not even sure if
> > this is possible since sessions are out of my experience, but my ONLY
> > problem with Embperl were sessions and how difficult they were to get up
> and
> > running. Additionally, I have had many "weird" experiences even when I
> > think the sessions are working correctly. I have also had the problem of
> > other users seeing my session after I login. This is very scary and does
> > not bode well for a robust scripting language. I believe PHP does its own
> > session handling, why not do something similiar and get rid of reliance on
> > perl modules like Apache::Session.
> >
> > My thoughts,
> > joe
> >
> > ______________________________________________________
> > joe lauer rootlevel
> > product developer 743 beaubien, suite 300
> > p.313.961.4407 x302 detroit, mi 48226
> > f.313.961.4568 www.rootlevel.com
> >
> > -----Original Message-----
> > From: Gerald Richter [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, November 09, 2000 3:19 PM
> > To: Angus Lees; Embperl list
> > Subject: Re: trying to DeleteSession (security bug?)
> >
> > >
> > > currently it sends the cookie every time, but (as gerald and i
> > > discussed privately) i have a feeling thats a modperl 1.24 issue.
> > >
> > > if you write to %udat after calling DeleteSession, then it creates the
> > > session in the database (or on disk, etc), but still deletes the
> > > cookie. if you do this, you probably deserve to leak sessions tho ;)
> > > (reading after deleting is fine)
> > >
> >
> > Now delete, read after delete and write after delte should work. Also the
> > cookie resending logic is enhanced. Maybe this work also for you.
> >
> > >
> > > my point was that it tries to create whatever session the browser asks
> > > for. imo, if the browser has a cookie for which no session exists, the
> > > browser should get given a new randomly generated session, just as if
> > > it had no existing cookie.
> > >
> > > if it wasn't for taint, it'd be a real security issue. consider what
> > > would happen using FileStore and a session id of "../../bin/httpd" (or
> > > some path that exists).
> > >
> >
> > Ok, Embperl has relied on Apache::Session to validate session id, but
> actual
> > it doesn't do this correctly.
> >
> > I have added a session id validation (if Apache::Session 1.53+ is
> installed,
> > it uses the validate method of the Generate class), if the session id is
> > invalid or the session id doesn't exists Embperl now generates a new id
> and
> > send a new cookie with this id.
> >
> > I also have made a lot of enhancement to make test, to better test all
> these
> > situations, but this is not totaly finished yet, so a few of the tests in
> > the current CVS version fails, but Embperl seems to do the right thing.
> >
> > Gerald
> >
> > -------------------------------------------------------------
> > Gerald Richter ecos electronic communication services gmbh
> > Internetconnect * Webserver/-design/-datenbanken * Consulting
> >
> > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> > E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925151
> > WWW: http://www.ecos.de Fax: +49 6133 925152
> > -------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> ___cliff [EMAIL PROTECTED]http://www.genwax.com/
--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
