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
flexibilitythat 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/





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to