Re: Session managing using PerlTransHandler

[Enrico Sorcinelli]

On Fri, 22 Nov 2002 19:09:25 +0200
[EMAIL PROTECTED] wrote:

> How I Can redirect to page http://foo.bar/ses1/index.html from  PerlTransHandler 
>Module?

Hi,
the description of your problem is very... short.
The chapter 5 of 'eagle' book explain how to put and strip session ID
on the left to the left of the URI.

Moreover, the Apache::SessionManager module does things transparently for you.
It works in PerlTransHandler phase.
(http://www.cpan.org/modules/by-module/Apache/Apache-SessionManager-0.04.tar.gz)

Bye

- Enrico
 

Re: Session

[Ernest Lergon]

Burak Gursoy wrote:
> 
> can someone point me to an address about, sessions: usage and logic? or
> something like that... like a definition of sessions...
>

On http://www.zdnetindia.com/techzone/coding/stories/36385.html it
reads:

While it might take heavy programming to turn a purchase history into a
recommendation, it is pretty simple to associate each request to your
Web server with an individual user. The HTTP protocol itself is no help
because it was designed to be stateless, requiring no information from
one request to the next. So without something extra, a server cannot
know which requests come from the same person. In this article, we'll
look at how to associate multiple requests with a single session and how
to store information specific to that session on the server.

More over try:

http://www.google.com/search?q=perl+session+stateless&hl=en

Ernest 



-- 

*
* VIRTUALITAS Inc.   *  *
**  *
* European Consultant Office *  http://www.virtualitas.net  *
* Internationales Handelszentrum *   contact:Ernest Lergon  *
* Friedrichstraße 95 *mailto:[EMAIL PROTECTED] *
* 10117 Berlin / Germany *   ums:+49180528132130266 *
*

RE: Session

[Burak Gursoy]

not an answer to this question and a little OT, but...

can someone point me to an address about, sessions: usage and logic? or
something like that... like a definition of sessions...

-Original Message-
From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 22, 2002 8:19 AM
To: Murugan K
Cc: [EMAIL PROTECTED]
Subject: Re: Session


At 22:46 21.03.2002 -0700, Murugan K wrote:
>Hi
>Thanks in advance for your reply.
>
>How can i  maintain session informations  without cookie , hidden
>variables  through forms  in Perl.
>
>Is there any separate Apache module is available?


You should look at Apache::Session. There are different ways to keep
session, but most go with atleast a cookie to keep the session ID, and then
keeps all the information in a database or other storage method. Of course,
the session ID can be passed along in whatever way you want, through the
query string, or as a hidden form value.


--
Per Einar Ellefsen
[EMAIL PROTECTED]


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: Session

[Per Einar Ellefsen]

At 22:46 21.03.2002 -0700, Murugan K wrote:
>Hi
>Thanks in advance for your reply.
>
>How can i  maintain session informations  without cookie , hidden
>variables  through forms  in Perl.
>
>Is there any separate Apache module is available?


You should look at Apache::Session. There are different ways to keep 
session, but most go with atleast a cookie to keep the session ID, and then 
keeps all the information in a database or other storage method. Of course, 
the session ID can be passed along in whatever way you want, through the 
query string, or as a hidden form value.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Session refresh philosophy

[Rob Nagler]

Perrin Harkins writes:
> Actually, even this stuff could be put into a normalized "sessions" table
> rather than serialized to a blob with Storable.  It just means more work if
> you ever change what's stored in the session.

This is a tough question.  If you store it in a blob, you can't query
it with an ad hoc SQL query.  If you store it in a table, you have to
deal with data evolution.  On the whole, I vote for tables over blobs.
My reasoning is that you have to deal with data evolution anyway.  We
have had about 200 schema changes in the last two years, and very few
of them have had anything to do with user/visitor state.

Rob

Re: Session refresh philosophy

[Perrin Harkins]

> In that the general idea of expiration is to discard
> information that hasn't been accessed in a while, some feel that updating
the
> timestamp is best done during both loading and storing.

If you don't always store the session (Apache::Session doesn't store unless
you modify data in the session) then you have to update the timestamp on
load to be accurate.  If you want to be frugal, you might make the store
operation update the timestamp, and then install a cleanup handler that will
update the timestamp only if the session was not stored.

- Perrin

Re: Session refresh philosophy

[Perrin Harkins]

> As I understand it, the session data is "state" which is committed to
> the database on each request (possibly).  It would seem to me that
> instead of denormalizing the state into a separate session table, you
> should just store it in a normal table.

The typical breakdown I use for this is to put simple state information that
connects this browser to long-term data in the session, and everything else
in normal database tables.  So, I put the user's ID (if this session belongs
to an identified user), a flag telling whether or not this user has given a
secure login so far in this session, and not much else in the session.

Actually, even this stuff could be put into a normalized "sessions" table
rather than serialized to a blob with Storable.  It just means more work if
you ever change what's stored in the session.

- Perrin

Re: Session refresh philosophy

[Rob Nagler]

Milo Hyson writes:
> shopping-cart-style application (whereby someone selects/configures multiple 
> items before they're ultimately committed to a database) how else would you 
> do it? There has to be some semi-persistent (i.e. inter-request) data where 
> selections are stored before they're confirmed.

As I understand it, the session data is "state" which is committed to
the database on each request (possibly).  It would seem to me that
instead of denomalizing the state into a separate session table, you
should just store it in a normal table.  If the data needs to be
expired, then it can be time stamped when it is written.

The point is that it's always simpler to use the existing tables
directly rather than making a copy and storing it in the database
somewhere else.  This usually reduces the code by half or more,
because you don't have to worry about making the copy in the first
place.  Simpler code is more reliable and usually runs faster.

To me, sessions are negativist.  My expectation is that users will end
up clicking OK (making the purchase).  If that is the case, you are
much better off putting the data were belongs right from start.  You
may bind it to an ephemeral entity, such as a shopping cart, but when
the order is complete the only thing you have to do is free the cart
and replace it with an order.  The items, amounts, and special
considerations have already been stored.

If most of your users are filling shopping baskets and walking away
from them, it may be a problem with the software.  Checkout
http://www.useit.com for some ideas on how to improve the ratio.

Often you can avoid any server side persistence by using hidden fields
in the forms.  We use this technique extensively, and we have
encapsulated it so that it is easy to use.  For example, you might
have a sub form which asks the user to fill in an address.  When the
user clicks on the "fill in address" button, the server squirrels away
the context of the current form in the hidden fields of the address
form.  When the user clicks OK on the address form, the fields are
stuffed back into the original form including the new address.

If you have a performance problem, solve it when you can measure it.
Sessions can mitigate performance problems, but so can intelligent
caching, which avoids statefulness in the client-server protocol.

Rob

P.S. For sample sessionless sites, visit http://www.bivio.com and
 http://petshop.bivio.biz (which runs on a 3 year old 300mhz box
 running Apache and Postgres).

Re: Session refresh philosophy

[Milo Hyson]

On Monday 18 February 2002 07:29 pm, Rob Nagler wrote:
> I may be asking the wrong question: is there a need for sessions?
> This seems like a lot of work when, for most applications, sessions
> are unnecessary.

I don't see how they could be unnecessary for what we're doing. Then again, 
maybe I'm just approaching the problem incorrectly. If one is doing a 
shopping-cart-style application (whereby someone selects/configures multiple 
items before they're ultimately committed to a database) how else would you 
do it? There has to be some semi-persistent (i.e. inter-request) data where 
selections are stored before they're confirmed.

-- 
Milo Hyson
CyberLife Labs, LLC

Re: Session refresh philosophy

[Rob Nagler]

Milo Hyson writes:
> 1) A fix-up handler is called to extract the session ID from a cookie. 
[snip]
> 1a) If for some reason no session was found (e.g. no cookie) a new one is 
[snip]
> 2) During content-generation, the application obtains the session reference 
[snip]
> 3) A clean-up handler is called to re-serialize the session and stick it back

I may be asking the wrong question: is there a need for sessions?
This seems like a lot of work when, for most applications, sessions
are unnecessary.

Rob

Re: Session tracking with URLs

[Bill Moseley]

At 05:54 PM 02/20/01 -0800, Yann Ramin wrote:
>1. I was thinking of doing session tracking first by cookies (I have a
system 
>which works well), but some people don't like cookies/don't support 
>cookies/have broken cookies. I was thinking of running a mod_perl handler on 
>the output which does a little regexp game of adding a session variable to 
>the end of the URLs and forms. Has anyone done something like this? Is
this a 
>stupid idea?

Placing sessions into the URL is described in the Eagle book.  And I use a
modified version of Apache::AuthCookie called Apache::AuthCookieURL that
does this -- it can be configured to just generate sessions.  Should be on
CPAN.

>2. How do I deal with browsers which do not return a referer header? Some 
>parts of my web app depend heavily on it (goto page, page requires URL,
sends 
>to login page which captures referer of page where the user wants to go,
logs 
>in user, sends user back to the page seamlessly).

It's probably best not to base your design on a browser feature that may or
may not work.  If you use sessions, then track referrers in the session
records.



Bill Moseley
mailto:[EMAIL PROTECTED]

Re: session expiration

[Steve van der Burg]

>So basically I want to set a cookie that will allow them to enter the site
>under their userid, but I can't allow them to enter if they are currently
>logged in from elsewhere.
>
>Any ideas?

I use cookie-based auth in a few places, with a "can be logged in
only once" restriction, but I duck the "don't allow them to enter"
scenario by letting each new session supercede the old one. 
I use a database that maps logged-in user IDs to cookies, and once
authentication is done (which happens if the user doesn't send a
cookie, or doesn't send the right cookie), the new cookie simply
overwrites the old one, and the new session becomes the "allowed" one.

...Steve

-- 
Steve van der Burg
Information Services
London Health Sciences Centre
(519) 685-8300 ext 35559
[EMAIL PROTECTED]


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

Re: session expiration

[Trey Connell]

Yeah, big troubleI'm thinking the client's just retarded.  ;~)

Bill Moseley wrote:

> At 05:20 PM 11/20/00 -0600, Trey Connell wrote:
> >The latter will be accomplished with cookies and the first rule will be
> >enforced with a "loggedin" flag in the database.  My problem lies in the user
> >not explicitly clicking logout when they leave the site.  If they explicitly
> >click logout, i can change the "loggedin" flag to false so that they can
> enter
> >again the next time they try.
> >
> >However, if they do not explicitly logout, I cannot fire the code to change
> >the flag in the database.
>
> That's where cron comes in.  Just make your flag a time, and update it each
> request.  cron then removes any that are older than some preset time and
> *poof* they are then logged out.  They try to access again and you see they
> have a cookie, yet are logged out and you say "Sorry, you session has
> expired".
>
> >So basically I want to set a cookie that will allow them to enter the site
> >under their userid, but I can't allow them to enter if they are currently
> >logged in from elsewhere.
>
> Why?  What if they want two windows open at the same time?  Is that
> allowed?  That design limitation sounds like it's going to make trouble.
>
> Bill Moseley
> mailto:[EMAIL PROTECTED]


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

Re: session expiration

[Michael Peppler]

Trey Connell writes:
 > Well, this is the basic scenario.
 > 
 > The same userid cannot be logged into the app more than once at any given
 > time.  Also, we want to use a cookie to keep the user from having to explicitly
 > login everytime.

Just some random ideas, not necessarily the ideal solution:

Create an MD5 hash (or some other unique key) when the user logs in,
set this key in the cookie and in the database.

Add a timeout value to the database entry (for example 3 hours, or
whatever).

When a user attempts to log in from a different location check the
timeout.
Alternatively, log the user out from the first session at that point.

Be careful of basing the client information on the IP address. AOL and 
a few other ISPs use rotating proxies so the client IP address can
change from one request to the next.

Michael
-- 
Michael Peppler - Data Migrations Inc. - [EMAIL PROTECTED]
http://www.mbay.net/~mpeppler - [EMAIL PROTECTED] - AIM MPpplr
International Sybase User Group - http://www.isug.com
Sybase on Linux mailing list: [EMAIL PROTECTED]

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

Re: session expiration

[Bill Moseley]

At 05:20 PM 11/20/00 -0600, Trey Connell wrote:
>The latter will be accomplished with cookies and the first rule will be
>enforced with a "loggedin" flag in the database.  My problem lies in the user
>not explicitly clicking logout when they leave the site.  If they explicitly
>click logout, i can change the "loggedin" flag to false so that they can
enter
>again the next time they try.
>
>However, if they do not explicitly logout, I cannot fire the code to change
>the flag in the database.

That's where cron comes in.  Just make your flag a time, and update it each
request.  cron then removes any that are older than some preset time and
*poof* they are then logged out.  They try to access again and you see they
have a cookie, yet are logged out and you say "Sorry, you session has
expired".

>So basically I want to set a cookie that will allow them to enter the site
>under their userid, but I can't allow them to enter if they are currently
>logged in from elsewhere.

Why?  What if they want two windows open at the same time?  Is that
allowed?  That design limitation sounds like it's going to make trouble.



Bill Moseley
mailto:[EMAIL PROTECTED]

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

Re: session expiration

[Trey Connell]

Well, this is the basic scenario.

The same userid cannot be logged into the app more than once at any given
time.  Also, we want to use a cookie to keep the user from having to explicitly
login everytime.

The latter will be accomplished with cookies and the first rule will be
enforced with a "loggedin" flag in the database.  My problem lies in the user
not explicitly clicking logout when they leave the site.  If they explicitly
click logout, i can change the "loggedin" flag to false so that they can enter
again the next time they try.

However, if they do not explicitly logout, I cannot fire the code to change the
flag in the database.

So basically I want to set a cookie that will allow them to enter the site
under their userid, but I can't allow them to enter if they are currently
logged in from elsewhere.

Any ideas?

Trey

Tim Bishop wrote:

> On Mon, 20 Nov 2000, Bill Moseley wrote:
>
> > At 03:00 PM 11/20/00 -0600, Trey Connell wrote:
> > >Is there anyway to know that a user has disconnected from their session
> > >through network failure, power off, or browser closure?
> >
> > How is that different from just going out for a cup of coffee or opening a
> > new browser window and looking at a different site?
> >
> > >I am logging
> > >information about the user to a database when they login to a site, and
> > >I need to clean up this data when they leave.
> >
> > Define "leave" and you will have the answer.
> >
> > All you can do is set an inactivity timeout, I'd suspect.  cron is your
> > friend in these cases.
>
> And spec out what you want when a user does happen to come back after you
> have expired their session with cron.  (they leave their browser open for
> awhile, or they bookmark a page).
>
> -Tim
>
> -
> 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]

Re: session expiration

[Tim Bishop]

On Mon, 20 Nov 2000, Bill Moseley wrote:

> At 03:00 PM 11/20/00 -0600, Trey Connell wrote:
> >Is there anyway to know that a user has disconnected from their session
> >through network failure, power off, or browser closure? 
> 
> How is that different from just going out for a cup of coffee or opening a
> new browser window and looking at a different site?
> 
> >I am logging
> >information about the user to a database when they login to a site, and
> >I need to clean up this data when they leave.
> 
> Define "leave" and you will have the answer.
> 
> All you can do is set an inactivity timeout, I'd suspect.  cron is your
> friend in these cases.

And spec out what you want when a user does happen to come back after you
have expired their session with cron.  (they leave their browser open for
awhile, or they bookmark a page).

-Tim


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

Re: session expiration

[Bill Moseley]

At 03:00 PM 11/20/00 -0600, Trey Connell wrote:
>Is there anyway to know that a user has disconnected from their session
>through network failure, power off, or browser closure? 

How is that different from just going out for a cup of coffee or opening a
new browser window and looking at a different site?

>I am logging
>information about the user to a database when they login to a site, and
>I need to clean up this data when they leave.

Define "leave" and you will have the answer.

All you can do is set an inactivity timeout, I'd suspect.  cron is your
friend in these cases.

Cheers,


Bill Moseley
mailto:[EMAIL PROTECTED]

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

Re: session expiration

[Trey Connell]

Yeah, thought about that, but that won't work if they are sitting behind a
firewall.

Trey

Craig E Ransom wrote:

> Hi Trey!
>
> > Is there anyway to know that a user has disconnected from their session
> > through network failure, power off, or browser closure?
> >
> How about extracting the user's IP address and then, if he hasn't sent
> anything over for a time period, ping him?
>
> -- Craig (The Data Ferret)
> http://www.pcferret.com/ for RARS, NetClip
> http://www.pcferret.com/teletools.html for Telephony
> http://www.pcferret.com/gps.html for GPS!
> Virtual Access 5.50 build 311 Win98
> http://counter.li.org ID #184149
> "Do not meddle in the affairs of FERRETS..."
>
> -
> 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]

Re: session expiration

[Craig E Ransom]

Hi Trey!

> Is there anyway to know that a user has disconnected from their session
> through network failure, power off, or browser closure?
>
How about extracting the user's IP address and then, if he hasn't sent 
anything over for a time period, ping him?

-- Craig (The Data Ferret) 
http://www.pcferret.com/ for RARS, NetClip
http://www.pcferret.com/teletools.html for Telephony
http://www.pcferret.com/gps.html for GPS!
Virtual Access 5.50 build 311 Win98
http://counter.li.org ID #184149
"Do not meddle in the affairs of FERRETS..."



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

Re: Session data disappearing

[Simon_Wilcox]

That should work as far as I know, it sounds like it is not being tied correctly
to your store.

  Can you post your code to the list ?

  SW






   From   cbell <[EMAIL PROTECTED]>  Date
   31 October 2000


To  
Simon Wilcox/BASE/WilliamsLea@WilliamsLea   Time  17:58 



  Copy to



  Bcc



  Fax to



  Subject       Re: Session data disappearing





I read that in the manual, but was a little unsure of what it meant.  I
understand
the concept just not how to implement it.

Right now I'm just storing a variable in the hash.. For example...

$hash{test} = "test";

Then if I look at the variable from another script (or the same script) it's
just
not there.

[EMAIL PROTECTED] wrote:

> Hi Chris, welcome on board !
>
>   Are you changing data structures e.g. a element in a hash of hashes ?
>
>   Apache::Session has documented behaviour where it only writes back
changes
>   if the top level variables have changed. If you are changing something
>   deeper it will not be _seen_ as a change.
>
>   The recommended approach is to use a timestamp at the top level to
ensure
>   that something always changes and forces a write.
>
>   Simon Wilcox.
>
>From   cbell <[EMAIL PROTECTED]>
Date
>31 October 2000
>
>
> To
> [EMAIL PROTECTED]  Time  17:30
>
>
>   Copy to (bcc: Simon Wilcox/BASE/WilliamsLea)
>
>   Bcc Simon Wilcox/BASE/WilliamsLea
>
>   Fax to
>
>   Subject   Session data disappearing
>
> Hi everyone, I'm sure this is a simple problem...
>
> Im using Session.pm to track information between httpd requests.
> However, when I store some information in the session, it is gone when I
> try to retrieve it later.  I've noticed the following things:
>
> when I tie to the session I use the command Commit = 1, but in my
> error_log, I get the following...
> Commit ineffective with AutoCommit enabled at
> /usr/lib/perl5/site_perl/5.005/Apache/Session/Store/Postgres.pm line 92
>
> Then I turned AutoCommit off on my database connection but then I could
> see in my error_log that the commands were being rolled back.
>
> I'll try committing the changes to the database next, but then what's
> the point of the Commit = 1 command in the Tie command?? The
> documentation states it has to be like this. Does anyone know what the
> proper way of doing this is?
>
> Also, thanks to all who replied to my last post!!!  As you can see I'm
> now up and running with Mod_perl
>
> Chris
>
>   
>   Name: att1.htm
>att1.htm   Type: Hypertext Markup Language (text/html)
>   Encoding: base64
>Description: Internet HTML
>
>   
>
> __
>
>This email contains proprietary information some or all of which may be
>legally privileged.  It is for the intended recipient only. If an
addressing
>or transmission error has misdirected this email, please notify the author
by
>replying to this email. If you are not the intended recipient you must not
>use, disclose, distribute, copy, print, or reply on this email.










__


   This email contains proprietary information some or all of which may be
   legally privileged.  It is for the intended recipient only. If an addressing
   or transmission error has misdirected this email, please notify the author by
   replying to this email. If you are not the intended recipient you must not
   use, disclose, distribute, copy, print, or reply on this email.

Re: Session data disappearing

[Gunther Birznieks]

By the way, as an alternative suggestion, don't use postgres... use 
Session::File. I seem to recall that Postgres isn't the zippiest medium for 
storing sessions. It turns out plain files are pretty fast for small sets 
of blob data.

At 04:35 PM 10/31/00 +, [EMAIL PROTECTED] wrote:

>Hi Chris, welcome on board !
>
>   Are you changing data structures e.g. a element in a hash of hashes ?
>
>   Apache::Session has documented behaviour where it only writes back 
> changes
>   if the top level variables have changed. If you are changing something
>   deeper it will not be _seen_ as a change.
>
>   The recommended approach is to use a timestamp at the top level to 
> ensure
>   that something always changes and forces a write.
>
>   Simon Wilcox.
>
>
>
>
>
>
>From   cbell 
> <[EMAIL PROTECTED]>  Date
>31 October 2000
>
>
> To
> [EMAIL PROTECTED]  Time  17:30
>
>
>
>   Copy to (bcc: Simon Wilcox/BASE/WilliamsLea)
>
>
>
>   Bcc Simon Wilcox/BASE/WilliamsLea
>
>
>
>   Fax to
>
>
>
>   Subject   Session data disappearing
>
>
>
>
>
>Hi everyone, I'm sure this is a simple problem...
>
>Im using Session.pm to track information between httpd requests.
>However, when I store some information in the session, it is gone when I
>try to retrieve it later.  I've noticed the following things:
>
>when I tie to the session I use the command Commit = 1, but in my
>error_log, I get the following...
>Commit ineffective with AutoCommit enabled at
>/usr/lib/perl5/site_perl/5.005/Apache/Session/Store/Postgres.pm line 92
>
>Then I turned AutoCommit off on my database connection but then I could
>see in my error_log that the commands were being rolled back.
>
>I'll try committing the changes to the database next, but then what's
>the point of the Commit = 1 command in the Tie command?? The
>documentation states it has to be like this. Does anyone know what the
>proper way of doing this is?
>
>Also, thanks to all who replied to my last post!!!  As you can see I'm
>now up and running with Mod_perl
>
>Chris
>
>
>
>
>
>
>
>
>
>
>
>
>__
>
>
>This email contains proprietary information some or all of which may be
>legally privileged.  It is for the intended recipient only. If an 
> addressing
>or transmission error has misdirected this email, please notify the 
> author by
>replying to this email. If you are not the intended recipient you must not
>use, disclose, distribute, copy, print, or reply on this email.

__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/

Re: Session data disappearing

[Simon_Wilcox]

Hi Chris, welcome on board !

  Are you changing data structures e.g. a element in a hash of hashes ?

  Apache::Session has documented behaviour where it only writes back changes
  if the top level variables have changed. If you are changing something
  deeper it will not be _seen_ as a change.

  The recommended approach is to use a timestamp at the top level to ensure
  that something always changes and forces a write.

  Simon Wilcox.






   From   cbell <[EMAIL PROTECTED]>  Date
   31 October 2000


To  
[EMAIL PROTECTED]  Time  17:30 



  Copy to (bcc: Simon Wilcox/BASE/WilliamsLea)



  Bcc Simon Wilcox/BASE/WilliamsLea



  Fax to



  Subject   Session data disappearing





Hi everyone, I'm sure this is a simple problem...

Im using Session.pm to track information between httpd requests.
However, when I store some information in the session, it is gone when I
try to retrieve it later.  I've noticed the following things:

when I tie to the session I use the command Commit = 1, but in my
error_log, I get the following...
Commit ineffective with AutoCommit enabled at
/usr/lib/perl5/site_perl/5.005/Apache/Session/Store/Postgres.pm line 92

Then I turned AutoCommit off on my database connection but then I could
see in my error_log that the commands were being rolled back.

I'll try committing the changes to the database next, but then what's
the point of the Commit = 1 command in the Tie command?? The
documentation states it has to be like this. Does anyone know what the
proper way of doing this is?

Also, thanks to all who replied to my last post!!!  As you can see I'm
now up and running with Mod_perl

Chris




Hi everyone, I'm sure this is a simple problem...
Im using Session.pm to track information between httpd requests. 
However, when I store some information in the session, it is gone
when I try to retrieve it later.  I've noticed the following things:
when I tie to the session I use the command Commit = 1, but in
my error_log, I get the following...
Commit ineffective with AutoCommit enabled at /usr/lib/perl5/site_perl/5.005/Apache/Session/Store/Postgres.pm
line 92
Then I turned AutoCommit off on my database connection but then I could
see in my error_log that the commands were being rolled back.
I'll try committing the changes to the database next, but then what's
the point of the Commit = 1 command in the Tie command?? The documentation
states it has to be like this. Does anyone know what the proper way of
doing this is?
Also, thanks to all who replied to my last post!!!  As you can
see I'm now up and running with Mod_perl
Chris












__


   This email contains proprietary information some or all of which may be
   legally privileged.  It is for the intended recipient only. If an addressing
   or transmission error has misdirected this email, please notify the author by
   replying to this email. If you are not the intended recipient you must not
   use, disclose, distribute, copy, print, or reply on this email.

Re: Session manager(s)-how to set an outbound session ?

[Ken Williams]

Bill Moseley wrote:
> FWIW -- I'm using a modified version of Ken Williams' Apache::AuthCookie to
> handle session control via cookies or munged URLs.  I originally wanted to
> use his custom login script instead of the pop-up browser login, but I had
> clients that don't have cookies enabled.  So I added the URL munge into
> AuthCookie.
[...]
> If anyone is interested, please let me know.  (Ken, are these features
> worth adding to AuthCookie?)

Quite possibly.  I'm away from my home turf now, but I'll take a look
when I get home.  Of course, having a module called AuthCookie that
doesn't necessarily use cookies might be a tad strange. =)


> BTW -- Why can't I use
> 
> PerlTransHandler  Sample::AuthCookieHandler
> 
> instead of
> 
> PerlTransHandler  Sample::AuthCookie
> 
> Shouldn't handler() be found in @ISA?

Probably because mod_perl is invoking your handler as a function and not
a method.  Does it work if you change it to
Sample::AuthCookieHandler->handler, or fix the prototype of the handler
subroutine to ($$)?

Re: Session manager(s)-how to set an outbound session ?

[Bill Moseley]

At 11:24 PM 08/14/00 +, Greg Cope wrote:

>I'm writing a Session-Manager (transhandler) i.e deals with getting a
>session id from cookies, uri, or query args, and sets one and redirects
>if neccessary.  This is meant to compliment Apache::Session - in that
>you use Apache::Session to store your session data.

FWIW -- I'm using a modified version of Ken Williams' Apache::AuthCookie to
handle session control via cookies or munged URLs.  I originally wanted to
use his custom login script instead of the pop-up browser login, but I had
clients that don't have cookies enabled.  So I added the URL munge into
AuthCookie.

I realized that bypassing the Apache::AuthCookie login script that
AuthCookie was perfect (at least for my needs) for simple session
management.  

The only changes needed to the AuthCookie config are:

# Enable URL munging
PerlTransHandler  Sample::AuthCookie

# Disable the login script requirement
PerlSetVar WhatEverLoginScript NONE

If anyone is interested, please let me know.  (Ken, are these features
worth adding to AuthCookie?)

BTW -- Why can't I use 

PerlTransHandler  Sample::AuthCookieHandler

instead of

PerlTransHandler  Sample::AuthCookie

Shouldn't handler() be found in @ISA?




Bill Moseley
mailto:[EMAIL PROTECTED]

Re: Session woes -Anyone Please help.????

[Perrin Harkins]

On Mon, 7 Aug 2000, Jitesh Kumar wrote:
> All I want is to store the generated key in the session variable so
> that I could retrieve the same on the subsequent page user visits for
> authentication purpose. I can't rely on client side cookies as they
> are not full proof.

If you don't want to use cookies, you'll need to put the session ID in the
URL somehow.  At the moment, there isn't a module on CPAN written for this
specific purpose, but Apache::ASP does have it built in and if that fits
your needs it's the easiest way to go.  You could also pick up a copy of
the book "Witing Apache Modules with Perl and C" (the Eagle book) and
refer to the example of session tracking using path_info.

- Perrin

Re: Session woes -Anyone Please help.????

[j e f f__s a e n z]

You could also pass it as the path_info for the url if you wanted to make it somewhat 
more discrete. The eagle book also has a good section on session ids.

Nigel Hamilton wrote:

> HI Jitesh,
>
> I do exactly the same thing ... but I pass session variables using a 
>combination of methods.
>
> Inserting a hidden field into subsequent pages:
>
> 
>
> Or you could append the sessionid to a URL:
>
> http://www.yoursite.com/cgi-bin/yourcgi.pl?sessionid=1232139102831
>
> Failing that, you could create a hidden frame (i.e., size = 0) and store the 
>sessionid in a Javascript variable:
>
> 
>
> The javascript will append the sessionid when the form is submitted.
>
> You might choose the third option if you wanted to keep the sessionid 
>semi-secret and you only need to access the session variable some of the time.
>
> NIge
>
>
> Nigel Hamilton
> __
> http://e1mail.come1mail - Encrypted 1st Class Maile1mail: 1001

--
Jeff Saenz
[EMAIL PROTECTED]

Re: Session woes -Anyone Please help.????

[Nigel Hamilton]

HI Jitesh,

I do exactly the same thing ... but I pass session variables using a 
combination of methods.

Inserting a hidden field into subsequent pages:



Or you could append the sessionid to a URL:

http://www.yoursite.com/cgi-bin/yourcgi.pl?sessionid=1232139102831

Failing that, you could create a hidden frame (i.e., size = 0) and store the 
sessionid in a Javascript variable:

 

The javascript will append the sessionid when the form is submitted.

You might choose the third option if you wanted to keep the sessionid 
semi-secret and you only need to access the session variable some of the time.

NIge


Nigel Hamilton
__
http://e1mail.come1mail - Encrypted 1st Class Maile1mail: 1001

RE: Session Cookies:cant retrieve value

[G.W. Haywood]

Hi all,

On Fri, 30 Jun 2000, Geoffrey Young wrote:

>> From: darren chamberlain
>> Maybe I stole it unconsciously... Sorry Geoff...
> feel free

Somebody once said "Imitation is the sincerest form of flattery".

Blessed if I can remember who it was.

73,
Ged.

RE: Session Cookies:cant retrieve value

[Geoffrey Young]

> -Original Message-
> From: darren chamberlain [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 30, 2000 9:29 AM
> To: Geoffrey Young
> Cc: [EMAIL PROTECTED]
> Subject: Re: Session Cookies:cant retrieve value
> 
> 
> Geoffrey Young ([EMAIL PROTECTED]) said something to this effect:
> > 
> > 
> > > -Original Message-
> > > From: darren chamberlain [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, June 30, 2000 8:48 AM
> > > To: Steven Wren
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Session Cookies:cant retrieve value
> > > 
> > > 
> > [snip]
> > 
> >   Apache::RequestNotes will parse the cookies and place 
> them in pnotes for
> > you during the init phase in case you don't feel like 
> writing your own
> > handler for it.  It also takes care of GET/POST requests 
> and file uploads
> > while it's at it.
> > 
> > 
> > --Geoff
> 
> It sure will. I downloaded it when it first came out, but 
> prefer the pure Perl
> version of cookie parsing that I showed because it also works 
> (if you change
> the $r->headers_in line to $ENV{HTTP_COOKIE}) in CGI. I took 
> the technique
> from a some cookie parsing I had originally done in bash. 
> It's simple, concise,
> and fast.
> 
> It's also ugly, and Apache::RequestNotes is not. 

:)

>Now that I 
> think of it, I
> started using the init handler technique *after* I read 
> through RequestNotes...
> Maybe I stole it unconsciously... Sorry Geoff...

so worries - this is open source, so feel free to do what you wish.  I would
hope that's what we're doing here - exchanging ideas, expertise, and, in
general, maximixing eachother's valuable time :)

As somebody mentioned recently in the browser identity thread, there are
lots of Apache:: modules out there - I was just trying to remind folks that
RequestNotes is around if they need it...

--Geoff



> 
> darren
> 
> -- 
> I'm not sure which upsets me more: that people are so 
> unwilling to accept
> responsibility for their own actions, or that they are so 
> eager to regulate
> everyone else's.
>   -- Kee Hinckley
> 

Re: Session Cookies:cant retrieve value

[darren chamberlain]

Geoffrey Young ([EMAIL PROTECTED]) said something to this effect:
> 
> 
> > -Original Message-
> > From: darren chamberlain [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, June 30, 2000 8:48 AM
> > To: Steven Wren
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Session Cookies:cant retrieve value
> > 
> > 
> [snip]
> 
>   Apache::RequestNotes will parse the cookies and place them in pnotes for
> you during the init phase in case you don't feel like writing your own
> handler for it.  It also takes care of GET/POST requests and file uploads
> while it's at it.
> 
> 
> --Geoff

It sure will. I downloaded it when it first came out, but prefer the pure Perl
version of cookie parsing that I showed because it also works (if you change
the $r->headers_in line to $ENV{HTTP_COOKIE}) in CGI. I took the technique
from a some cookie parsing I had originally done in bash. It's simple, concise,
and fast.

It's also ugly, and Apache::RequestNotes is not. Now that I think of it, I
started using the init handler technique *after* I read through RequestNotes...
Maybe I stole it unconsciously... Sorry Geoff...

darren

-- 
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-- Kee Hinckley

RE: Session Cookies:cant retrieve value

[Geoffrey Young]

> -Original Message-
> From: darren chamberlain [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 30, 2000 8:48 AM
> To: Steven Wren
> Cc: [EMAIL PROTECTED]
> Subject: Re: Session Cookies:cant retrieve value
> 
> 
[snip]
> 
> Try setting the cookie in an early phase of the request 
> (PerlInitHandler or,
> PerlHeaderParserHandler, for example) and set the cookie 
> there. In addition,
> stick the value of the cookie into pnotes and retrieve it 
> during the same
> request from pnotes, and from future requests from the headers.
> 
> I do this pretty often; my PerlInitHandler parses the cookies 
> and puts them
> into pnotes, and in all other request phases I always access 
> them from pnotes,
> for consistency. That way, I know that there is always a cookie there.
> 


  Apache::RequestNotes will parse the cookies and place them in pnotes for
you during the init phase in case you don't feel like writing your own
handler for it.  It also takes care of GET/POST requests and file uploads
while it's at it.
<\plug>

--Geoff

> An example:
> 
> package InitHandler;
> sub handler {
> my ($r) = @_;
> 
> # I use this line to grab cookies everywhere -- CGI::Cookie and
> # and Apache::Cookie are too much overhead for me when this is
> # so much simpler.
> my %cookies = map { $1 => $2 if (/([^=]+)=(.*)/) }
>   grep !/^$/, split /;\s*/,$r->header_in('cookie');
> 
> # the sub generate_a_cookie creates ithe cookie
> $cookies{'My-Cookie-Name'} ||= generate_a_cookie();
> 
> # Set the cookie to go into the outgoing headers:
> $r->push_handlers(PerlFixupHandler =>
>   sub {
> my ($r) = @_;
> my $cookies = $r->pnotes('cookies');
> my $expires = time + 60*60*24; # 24 hours from now
> $r->headers_out->add('Set-Cookie' => join ('; ',
>  
> ((sprintf("My-Cookie-Name=%s",$cookies{'My-Cookie-Name'}))
>   (sprintf("expires=%s",$expires)),
>   ("path=/"),
>   
> (sprintf("domain=%s",$r->get_server_name);
> return OK;
>   });
> 
> # Put the cookie into pnotes for retrieval later in the 
> same request!
> $r->pnotes('cookies' => \%cookies);
> 
> return DECLINED; # So any other init handlers get to run
> }
> 
> And then, in a later content handler, I do something like:
> 
> package ContentHandler;
> sub handler {
> my ($r) = @_;
> 
> # note this is a hashref!
> my $cookies = $r->pnotes('cookies');
> 
> # ... as usual.
> 
> return OK;
> }
> 
> # In you httpd.conf:
> 
> PerlInitHandler InitHandler
> PerlHandler ContentHandler
> # Other stuff
> 
> 
> The nice thing about this way of doing it is that %cookies in 
> the other
> handler (or whatever later phase) is a reference to the value 
> in pnotes,
> so it is automatically updated if you modifiy it, and will be 
> sent with
> the current values (i.e., any changes made up to the headers 
> actually being
> sent will be preserved).
> 
> Hope this helps.
> 
> darren
> 
> -- 
> Absence is to love what wind is to fire. It extinguishes the small, it
> enkindles the great..
> 

Re: Session Cookies:cant retrieve value

[darren chamberlain]

Steven Wren ([EMAIL PROTECTED]) said something to this effect:
> Hey
> 
> I am setting up shopping facilities for an online purchases and thought I
> would try modperl.  Problem is I am trying to set a cookie and then read
> from it in the same handler, by setting the cookie then redirecting to the
> same page.  This is because the script will need to be called from many
> different places, just passing different store_ids and product_ids.
> 
> Currently it sets the cookie and appears to redirects but i can then not
> read the cookie value.
> 
> This might be a stoopid question but your help is appreciated.
> 
> The "logic":-) of my program goes like this...
> Handler runs routine which checks if cookie exists - if it does it returns
> the value, if cookie not set - it sets up the cookie(name,md5 value etc)
> then redirects to itself.  Then when it reloads it will check for a
> cookie, which should be now set, then return the value.
> 
> Surely there is a modperl shopping cart already??!!  Where does one go to
> find it, I have been searching the net for a few days now.
> 
> Thanks Heaps!!
> 
> P.S. Please reply directly as I am not in the list yet.
> 
> [EMAIL PROTECTED]
> 
> A genius makes no errors,
> his mistakes are portals of discovery - James Joyce

Why are you redirecting? That is a very CGI-ish thing to do, and unnecessary
if you use the full Apache API.

Try setting the cookie in an early phase of the request (PerlInitHandler or,
PerlHeaderParserHandler, for example) and set the cookie there. In addition,
stick the value of the cookie into pnotes and retrieve it during the same
request from pnotes, and from future requests from the headers.

I do this pretty often; my PerlInitHandler parses the cookies and puts them
into pnotes, and in all other request phases I always access them from pnotes,
for consistency. That way, I know that there is always a cookie there.

An example:

package InitHandler;
sub handler {
my ($r) = @_;

# I use this line to grab cookies everywhere -- CGI::Cookie and
# and Apache::Cookie are too much overhead for me when this is
# so much simpler.
my %cookies = map { $1 => $2 if (/([^=]+)=(.*)/) }
  grep !/^$/, split /;\s*/,$r->header_in('cookie');

# the sub generate_a_cookie creates ithe cookie
$cookies{'My-Cookie-Name'} ||= generate_a_cookie();

# Set the cookie to go into the outgoing headers:
$r->push_handlers(PerlFixupHandler =>
  sub {
my ($r) = @_;
my $cookies = $r->pnotes('cookies');
my $expires = time + 60*60*24; # 24 hours from now
$r->headers_out->add('Set-Cookie' => join ('; ',
 ((sprintf("My-Cookie-Name=%s",$cookies{'My-Cookie-Name'}))
  (sprintf("expires=%s",$expires)),
  ("path=/"),
  (sprintf("domain=%s",$r->get_server_name);
return OK;
  });

# Put the cookie into pnotes for retrieval later in the same request!
$r->pnotes('cookies' => \%cookies);

return DECLINED; # So any other init handlers get to run
}

And then, in a later content handler, I do something like:

package ContentHandler;
sub handler {
my ($r) = @_;

# note this is a hashref!
my $cookies = $r->pnotes('cookies');

# ... as usual.

return OK;
}

# In you httpd.conf:

PerlInitHandler InitHandler
PerlHandler ContentHandler
# Other stuff


The nice thing about this way of doing it is that %cookies in the other
handler (or whatever later phase) is a reference to the value in pnotes,
so it is automatically updated if you modifiy it, and will be sent with
the current values (i.e., any changes made up to the headers actually being
sent will be preserved).

Hope this helps.

darren

-- 
Absence is to love what wind is to fire. It extinguishes the small, it
enkindles the great.

Re: Session-handling and multiple browser windows

[Perrin Harkins]

On Mon, 12 Jun 2000, Dylan Weed wrote:
> Option three (removing all page-specific state from the session hash)
> seems like the right thing to do.

It is.  I don't know any other way to handle this situation correctly.

> I'd like to avoid it if possible, however, because it means passing
> more information through URLs and having to secure it.

Securing it isn't that tough.  If you just want to be sure it wasn't
tampered with, an MD5 token can take care of it, like Apache::TicketAccess
uses.  If you don't want people to read it, you can use one of the
Crypt:: modules from CPAN.  The O'Reilly "Algorithms in Perl" book has a
nice discussion of them.

- Perrin

Re: Session-handling and multiple browser windows

[shane]

> 1.  Stop the user from ever having the site open in more than one
> window.

Pretty inconvenient, no?  Unless this is something that's supposed to
be really tight security I would opt against this.  (I'm sure it's a
bear to implement too.)

> 2.  Somehow allocate the new window it's own session.

Same as 1

> 3.  Don't store any page-specific state in the session hash; limit the
> information that the session hash contains to state that applies to the
> entire session.

This seems to be the "right" solution.  Here's how I usually deal with
this:

Three classes of data:
1) Long Term
2) Session Term
3) Page Term

1:
Stored in database that is refered to by keys in the hash from the
session data once a person has "logged" in.
2:
Stored in session space, this is only a pointer to data that's used on
almost EVERY page.  Store this in a fast database program, mysql,
where as long term data is stored in Oracle, or some other "true RDBS"
(read slow :-)
3:
This data is ephemeral, therefore it seems awkward to store it in your
database, and awkward to store it in your session (Basically same as
storing in database, but it has to be looked up every go round, so you
need to be carefull to keep this data stack small).  So what I usually
do is "store" it in POSTs, or GETs, Get's being better because they're
more likely to "transfer" to the next page when a user clicks on open
in link in a new browser window or something like that.

But there are no hard and fast rules on this obviously.  The one key
thing is to keep your session really small..., the reason for this is
that you can't do incremental updates of session data, it has to
update the entire hash.  Also it has to be read everytime from the
DB... this is a pretty slow process.  So what I try to emphasize is
keep the session data down to stuff that's only used on every page.
(The 80% rule I suppose)  Of course if your only planning on having a
site that is used by a few hundred/thousand people total, then do
whatever you want :), but if you want it to be scalable, you need to
think long and hard about how you're using your sessions.

Shane.

> 
> Option three (removing all page-specific state from the session hash)
> seems like the right thing to do.  I'd like to avoid it if possible,
> however, because it means passing more information through URLs and having
> to secure it.  Have other people encountered this problem, and are there
> smart ways to do option 1 or option 2?
> 
> (If it matters, I'm using HTML::Mason as my templating engine.)
> 
>   -- Dylan
> 

Re: Session-handling and multiple browser windows

[siberian]

We store page specific information in the session hash, however we
allocate each 'section' of the site its own sub section of the hash, a
cocnept we sometimes extend to pages that do a lot of session work( using 
session->section->page  but we do not do that very often, its to much to 
monitor ). This
way we avoid conflicts. The FAQ engine uses session{ FAQ } and the search
system uses session{ GlobalSearch } ( in this case to allow the user to
build out their queries progressively ) etc etc etc.

It works well. We maintain pretty tight documentation on our session
hashes which works great as well. When you have multiple developers
futzing with the session it can get ugly. Fast..

John-

On Mon, 12 Jun 2000, Dylan Weed wrote:

> 
> I've run across a problem in the way I'm managing sessions, and I'm hoping
> that someone else has encountered the same thing and come up with a smart
> way to deal with it.  
> 
> I use Apache::Session and I associate each user with their respective
> session hash by giving them a cookie.  The problem shows up because, in a
> few places, I use the session hash to store page-specific state
> information (the current page the user is on, for example).
> 
> When a user opens a second copy of the site in another browser window,
> they still publish the same cookie.  Both the windows are then associated
> with the same session.  This means that the two windows can trash each
> other's page-specific state and cause all sorts of undefined behavior.
> 
> It seems to me like there are several possible solutions:
> 
> 1.  Stop the user from ever having the site open in more than one
> window.
> 
> 2.  Somehow allocate the new window it's own session.
> 
> 3.  Don't store any page-specific state in the session hash; limit the
> information that the session hash contains to state that applies to the
> entire session.
> 
> Option three (removing all page-specific state from the session hash)
> seems like the right thing to do.  I'd like to avoid it if possible,
> however, because it means passing more information through URLs and having
> to secure it.  Have other people encountered this problem, and are there
> smart ways to do option 1 or option 2?
> 
> (If it matters, I'm using HTML::Mason as my templating engine.)
> 
>   -- Dylan
> 
> 

Re: Session management moudle suggestions?

[Francesc Guasch]

Stephen Zander wrote:
> 
> I've avoided session management like the plague until now (intranets
> let you get away with that sort of thing :)) but rolling out web-based
> LDAP is forcing session management upon me.
> 
> Other than Apache::Session what are my choices?  How well do any of
> these play with templating (Embperl, Mason et al)?
> 
I'm a very happy user of Apache::Session::DBI that works
very well with HTML::Mason

-- 
 - frankie -

Re: Session management moudle suggestions?

[Paul Lindner]

On Mon, May 08, 2000 at 11:41:39AM -0700, Stephen Zander wrote:
> 
> I've avoided session management like the plague until now (intranets
> let you get away with that sort of thing :)) but rolling out web-based
> LDAP is forcing session management upon me.
> 
> Other than Apache::Session what are my choices?  How well do any of
> these play with templating (Embperl, Mason et al)?

Apache::ASP has very nice session management capabilities.  IMHO The
best feature is the Session_OnEnd handler (you can define code that is
executed when the Session finishes.)  And it's templating is superb.

-- 
Paul Lindner
[EMAIL PROTECTED]
Red Hat Inc.

Re: Session management moudle suggestions?

[John Armstrong]

We are using HTML::Mason and Apache::Session with great results. 
Apache::Session::DBI was killing us for some reason but moving it to 
our network appliance box and Apache::Session:File has really pumped 
up our performance. When you really start using sessions you can get 
some cool stuff out of them, we use them for all sorts of read only 
data now, not just users. Using Mason and Apache::Session has really 
increased our speed of development.

John-

At 11:41 AM -0700 5/8/00, Stephen Zander wrote:
>I've avoided session management like the plague until now (intranets
>let you get away with that sort of thing :)) but rolling out web-based
>LDAP is forcing session management upon me.
>
>Other than Apache::Session what are my choices?  How well do any of
>these play with templating (Embperl, Mason et al)?
>
>--
>Stephen
>
>"So.. if she weighs the same as a duck.. she's made of wood."  "And
>therefore?"  "A witch!"

RE: Session management moudle suggestions?

[Gerald Richter]

> I've avoided session management like the plague until now (intranets
> let you get away with that sort of thing :)) but rolling out web-based
> LDAP is forcing session management upon me.
>
> Other than Apache::Session what are my choices?

Build your own...

> How well do any of
> these play with templating (Embperl, Mason et al)?
>

Embperl has build in support for session management via Apache::Session. The
only thing you need to do is to put your data in a special hash and Embperl
does the rest for you.

Gerald

-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-

Re: Session

[Francesc Guasch]

raptor wrote:
> 
> hi,
> 
> Is there Session module that has capability more like ASP::Session
> rather than Apache::Session.(I mean hanlidng the cookies too, Joshua is
> it easy to extract Session functionality from ASP as a standalone module
> :")).
> OR
> what mostly the MASON people use to handle Sessions.
put this inside your handler.pl

my %session;
my $cookie_rec = $r->header_in('Cookie');
my ($cookie) = $cookie_rec=~/SESSION_ID=(\w+)/;
tie %session, 'Apache::Session::DBI', $cookie,
{DataSource => 'dbi:mysql:sessions',
UserName   => 'the username',
   Password   => 'the password'
};
$r->header_out("Set-Cookie" =>
"SESSION_ID=".$session{_session_id}.
";
expires=".HTTP::Date::time2str(time+180*24*60*60) )
if ( !$cookie or $cookie ne $session{_session_id});
my $result=$ah->handle_request($r);
untie %HTML::Mason::Commands::session if $SESSION;
return $result;


Just cutted and pasted from mine, I removed some code not important
for the example. Take it easy.

-- 
 ^-^,-. mailto:[EMAIL PROTECTED]
 o o   )http://www.etsetb.upc.es/~frankie
  Y (_ (__(OOOo

Re: Session

[Joshua Chamas]

raptor wrote:
> 
> hi,
> 
> Is there Session module that has capability more like ASP::Session
> rather than Apache::Session.(I mean hanlidng the cookies too, Joshua is
> it easy to extract Session functionality from ASP as a standalone module
> :")).
> OR
> what mostly the MASON people use to handle Sessions.
> 

There is no nice way to lift the Apache::ASP::Session
out of the ASP framework, since the event handling is 
all held outside of the module.  If you want the $Session
without the events, just use Apache::Session.  Below is
some init code that may help with your cookie issues, but 
you will have to undo the ASP dependent code obvi.

I don't know how using Apache::Session plugs into Mason
to make the $Session available in any script, but if
you have a pre-content handler init the Session, you could
set $main::Session, and have that available from anywhere
in perl.

-- Joshua
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks >> free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

## use Secret to generate your MD5 hexhash
$MD5 = new MD5();
sub Secret {
my $self = shift;

my $md5 = $Apache::ASP::MD5;
$md5->reset;
$md5->add($self . $self->{remote_ip} . rand() . time() . 
  $md5 . $self->{global} . $self->{'r'} . $self->{'mtime'});

$md5->hexdigest();  
}

# combo get / set
$SessionCookieName = 'session-id';
$SessionIDLength = 32;
sub SessionId {
my($self, $id) = @_;

if($id) {
$self->{session_id} = $id;
my $secure = $self->{secure_session} ? '; secure' : '';
$self->{r}->header_out
('Set-Cookie', 
 "$Apache::ASP::SessionCookieName=$id; path=$self->{cookie_path}".$secure
 );
} else {
# if we have already parsed it out, return now
# quick session_id caching, mostly for use with 
# cookie less url building
$self->{session_id} && return $self->{session_id};

my $cookie = $self->{r}->header_in("Cookie") || '';
my(@parts) = split(/\;\s*/, $cookie);
for(@parts) {   
my($name, $value) = split(/\=/, $_, 2);
if($name eq $SessionCookieName) {
$id = $value;
$self->{dbg} && $self->Debug("session id from cookie: $id");
last;
}
}
if(! $id && $self->{session_url}) {
$id = delete $self->{Request}{QueryString}{$SessionCookieName}; 
# if there was more than one session id in the query string, then just
# take the first one
ref($id) =~ /ARRAY/ and ($id) = @$id;
$id && $self->{dbg} && $self->Debug("session id from query string: $id");
}

# SANTIZE the id against hacking
if($id) {
if(length($id) == $SessionIDLength and $id =~ /^[0-9a-z]+$/) {
$self->{session_id} = $id;
} else {
$self->Log("passed in session id $id failed checks sanity checks");
$id = undef;
}
} 

if($id) {
$self->{session_id} = $id;
}
}

$id;
}

Re: session handling...

[panpipi]

 
Hi,
tied(%udat)->cleanup works! And for some unknown reason the performance
of redirection is better (possibly because most of time now the 2nd Apache
request from redirection is served by the same httpd without forking another
httpd) and Embperl is stabler now without any complaint such as 'panic:
popstack..callback called exit..." mentioned in my last email.
also my Session::DBIStore works now. Thanks.
By the way, how to return value from a subroutine defined with [$sub$][$endsub$].
It seems returning nothing now.
Huang-Ming
Gerald Richter ¼g¹D¡G
ok,
this could be a possible problem. I will take a look at it. Inbetween you
can call 
tied(%udat)
-> cleanup ; 
to
make sure all data is written to the File/DB. But be aware, after this
call you can't access %udat anymore!

What do I need to do with my database to work
with Apache::Session? I mean what tables or database schema are necessary
for this session handling to work?

perldoc
Apache::Session::DBIStore describes the tables 


PS. Besides, what's CVS version?

CVS
version is my current developemt version. perldoc CVS.pod in the Embperl
directory give you more information about it, but for the fix you need
you can upgrade to 1.2b11. (Note setup for session handling has slightly
changed, read the docs)
Gerald
---
Gerald Richter 
ecos electronic communication services gmbh
Internet - Infodatenbanken
- Apache - Perl - mod_perl - Embperl
E-Mail:
[EMAIL PROTECTED] Tel:   
+49-6133/925151
WWW: 

http://www.ecos.de 
Fax:    +49-6133/925152
---
 

Re: session handling...S.O.S...S.O.S...

[panpipi]

 
Hi,
I think I also need to detail more about the problem i met with %udat
using Apache::Session::File before jump to Apache::Session::DBI because
the latter might also expose the same 'unsync %udat' problem.
Let me use these script segments to describe the odd output i met using
%udat with Apache::Session::File:
script#1:
...
[+ $udat{any} +]
[- $udat{any}=99 -]
...display a form with action='script#2'
...
script#2:
...before here, $udat{any} should be 99 ...
delete $udat{any};
$req_rec->header_out(Location=>'script#1');  (please ignore #
here)
$req_rec->status(REDIRECT);
exit;
My Embperl is 1.2b9.
My Apache::Session is 1.02.
The odd i saw is:
'Sometimes' the script#1 wrongly displays 99 when the form in
script#1 is submitted. But it should display a empty string. The error
rate is about 50%. So I guess it is a problem of race condition, something
like this (i guess): Before %udat is saved to FileStore, shortly after
the httpd serving script#2 sends HTTP Location header to browser and request
back to run script1, the new request to run script#1 is served by another
httpd and this second httpd is forked before the first httpd exits. The
Session module in 2nd httpd fetchs the wrong 'obsoleted' version of %udat
because the new %udat is not yet saved in time by 1-st httpd's Session
module.
I guess it's kind of race condition because if I remove the location
redirection code and manually fetch script#1 immediately after script#2
ends, everything is OK all the time. But that makes my web
page very unfriendly and unacceptable. In my web, I heavily use %udat and
redirection to pass big fields among scripts of the same session.
I have no time to wait for patch (if any). Is there any method I can
call to "sync" %udat before I call $req_rec->status(REDIRECT)? I think
this is the fastest remedy to me.
Looking forward to any advance on this. Hoping my problem description
here is clear enough.
Thanks.
Huang-Ming
[EMAIL PROTECTED] ¼g¹D¡G
 
Hi,
Thanks to Embperl I almost done my web. But then I found serious abnormality
on session handling (%udat) when used with HTTP redirection (ie. $req_rec->status(REDIRECT)).
Sometimes %udat works OK, sometimes it still remains old data, especially
after redirection is processed by another httpd. (race condition?)
I'm tired of Apache::Session::FIle. Besides I need to use %mdat as well.
So as advised I turn to Apache::Session::DBI. But it is worse. The first
access of %udat caused httpd to crash with panic message as follows:
[183] SES: Embperl Session Management enabled (1.xx)
panic restartop
panic: POPSTACK
Callback called exit.
Callback called exit.
What's wrong?
I'm using Embperl 1.2b9 and Apache::Session 1.02.
My httpd.conf looks like:
#...(my old setting)...
#PerlSetEnv  EMBPERL_SESSION_CLASSES "FileStore SysVSemaphoreLocker"
#PerlSetEnv  EMBPERL_SESSION_ARGS "Directory=/tmp"
#PerlModule  Apache::Session::File
#...new setting...it never works but panic...
PerlSetEnv  EMBPERL_SESSION_CLASSES "DBIStore SysVSemaphoreLocker"
PerlSetEnv  EMBPERL_SESSION_ARGS "DataSource=DBI:mysql:mydb
UserName=panpipi Password=helpme"
PerlModule  Apache::Session::DBI (Apache::Session
neither works)
#...this neither works. why?...
PerlSetEnv EMBPERL_COOKIE_DOMAIN ".myxxx.com"
PerlSetEnv EMBPERL_COOKIE_PATH "/"
PerlSetEnv EMBPERL_COOKIE_EXPIRES "+1Y"
What do I need to do with my database to work with Apache::Session?
I mean what tables or database schema are necessary for this session handling
to work?
PS. Besides, what's CVS version?
Huang-Ming
 

RE: session handling...S.O.S...S.O.S...

[Gerald Richter]

  The odd i saw is: 
  'Sometimes' the script#1 wrongly displays 99 when the form in 
  script#1 is submitted. But it should display a empty string. The error rate 
  is about 50%. So I guess it is a problem of race condition, something like 
  this (i guess): Before %udat is saved to FileStore, shortly after the httpd 
  serving script#2 sends HTTP Location header to browser and request back to run 
  script1, the new request to run script#1 is served by another httpd and this 
  second httpd is forked before the first httpd exits. The Session module in 2nd 
  httpd fetchs the wrong 'obsoleted' version of %udat because the new %udat is 
  not yet saved in time by 1-st httpd's Session module. 
  I guess it's kind of race condition because if I remove the location 
  redirection code and manually fetch script#1 immediately after script#2 
  ends, everything is OK all the time. But that makes my web page 
  very unfriendly and unacceptable. In my web, I heavily use %udat and 
  redirection to pass big fields among scripts of the same session. 
  I have no time to wait for patch (if any). Is there any method I can call 
  to "sync" %udat before I call $req_rec->status(REDIRECT)? I think this is 
  the fastest remedy to me. 
ok, this 
could be a possible problem. I will take a look at it. Inbetween you can call 

tied(%udat) -> cleanup ; 
to make 
sure all data is written to the File/DB. But be aware, after this call you can't 
access %udat anymore!

  
What do I need to do with my database to work with Apache::Session? I 
mean what tables or database schema are necessary for this session handling 
to work? 
perldoc 
Apache::Session::DBIStore describes the tables 

  
 
 PS. Besides, what's CVS 
version? 
CVS 
version is my current developemt version. perldoc CVS.pod in the Embperl 
directory give you more information about it, but for the fix you need you can 
upgrade to 1.2b11. (Note setup for session handling has slightly changed, read 
the docs)
Gerald
---Gerald 
Richter  ecos electronic communication services 
gmbhInternet - Infodatenbanken - Apache - Perl - mod_perl - 
EmbperlE-Mail: 
[EMAIL PROTECTED] 
Tel:    
+49-6133/925151WWW:    http://www.ecos.de  
Fax:    
+49-6133/925152---  


  
 
 

Re: Session state without cookies

[Ask Bjoern Hansen]

On Sun, 31 Oct 1999, Trei B. wrote:

[...] 
> Couldn't we do some regex on the environment variable HTTP_REFERER to grab
> the session id from a request?

That only works for one "click". (the next click won't have the id
anymore, except maybe if you do a redirect every time - very ugly).

If possible by far the easiest way to do "sessions" is to say "turn on
cookies or go away".

We do some "sessions" with storing ip addresses, user agents (both not too
reliable) plus some specific data from our application and trying to match
them again.

It works but when possible, we use cookies or url mangling, much easier
and much more reliable.

 - ask

-- 
ask bjoern hansen - 
more than 50M impressions per day, 

Re: Session state without cookies

[Matt Sergeant]

On Mon, 01 Nov 1999, Randal L. Schwartz wrote:
> Uh, you still had to use one of the THREE METHODS I keep talking about:
> 
> 1) cookies
> 2) mangled URLs
> 3) hidden fields

And in some cases:

4) User authentication

--


Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.

Re: Session state without cookies

[Randal L. Schwartz]

> "Trei" == Trei B <[EMAIL PROTECTED]> writes:

Trei> Indeed there are no "sessions" with HTTP. I did not assume that
Trei> there is some magical "session ID" environment variable that
Trei> Apache provides the developer. Instead I was expressing a desire
Trei> for that type of functionality so that I could develop an
Trei> application with perl which can maintain session state with or
Trei> without cookies.  It's impossible for me to tell my boss that
Trei> I'm developing an application that will only work with
Trei> cookies. I've taken this script on from a previous developer so
Trei> it's time consuming to modify it to append a session id to the
Trei> URI that way.

Trei> What I did assume is that someone in the mod_perl community had
Trei> already solved the problem with a module - and they did
Trei> (Apache::StripSession). It makes sense to handle this in the URI
Trei> translation phase of the request loop.  And I think that there
Trei> are still ways to improve upon this concept.  If we want
Trei> mod_perl to provide us the best possible web development
Trei> environment we need to contend with issues like session state
Trei> without cookies just as ASP and now JSP have.

Uh, you still had to use one of the THREE METHODS I keep talking about:

1) cookies
2) mangled URLs
3) hidden fields

I'm not sure, but it sounds like you're talking about a module that
strips a mangled URL session ID, which is all of five lines in a Trans
handler, and has to be very customized.  And that doesn't make sense
in light of your statement:

Trei> I've taken this script on from a previous developer so it's time
Trei> consuming to modify it to append a session id to the URI that
Trei> way.

So now I'm baffled.  It still seems like you want a magical "session"
variable.  That's NOT POSSIBLE.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Session state without cookies

[Trei B.]

On 1 Nov 1999, Randal L. Schwartz wrote:
> There is no "session ID".  You get one of the above.
> 
> HTTP doesn't have "sessions".  It has individual requests.

Indeed there are no "sessions" with HTTP. I did not assume that there is
some magical "session ID" environment variable that Apache provides the
developer. Instead I was expressing a desire for that type of
functionality so that I could develop an application with perl which can
maintain session state with or without cookies. It's impossible for me to
tell my boss that I'm developing an application that will only work with
cookies. I've taken this script on from a previous developer so it's time
consuming to modify it to append a session id to the URI that way. 

What I did assume is that someone in the mod_perl community had already
solved the problem with a module - and they did (Apache::StripSession). It
makes sense to handle this in the URI translation phase of the request
loop. And I think that there are still ways to improve upon this concept.
If we want mod_perl to provide us the best possible web development
environment we need to contend with issues like session state without
cookies just as ASP and now JSP have.

thanks,
Trei B.

Re: Session state without cookies

[Randal L. Schwartz]

> "Trei" == Trei B <[EMAIL PROTECTED]> writes:

Trei> On 30 Oct 1999, Randal L. Schwartz wrote:

>> You have three main choices for maintaining a "session":
>> 
>> 1) cookies
>> 2) mangled URLs
>> 3) hidden fields in forms
>> 
>> If "static HTML" can't do #2 or #3, you are stuck with #1.
>> 
>> No amount of module help can work. :)

Trei> I may be wrong, but it seems that mod_perl gives us enough access to the
Trei> request loop that we could handle this problem. Couldn't we parse out and
Trei> append the session id somehow in the URI translation phase?

There is no "session ID".  You get one of the above.

HTTP doesn't have "sessions".  It has individual requests.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Session state without cookies

[Trei B.]

On 30 Oct 1999, Randal L. Schwartz wrote:

> You have three main choices for maintaining a "session":
> 
> 1) cookies
> 2) mangled URLs
> 3) hidden fields in forms
> 
> If "static HTML" can't do #2 or #3, you are stuck with #1.
> 
> No amount of module help can work. :)

I may be wrong, but it seems that mod_perl gives us enough access to the
request loop that we could handle this problem. Couldn't we parse out and
append the session id somehow in the URI translation phase?

Basically I'm looking for something similar to the Cookie Munger
functionality:
(http://msdn.microsoft.com/workshop/server/toolbox/cookie.asp)

Although, I'm not sure you need to parse the response document for URLs so
that you can append the session id to every one of them as MS does. I
heard a rumor that this type of non-cookie session state was going to be
possible with some JSP implementations as well.

Couldn't we do some regex on the environment variable HTTP_REFERER to grab
the session id from a request?

thanks,
Trei Brundrett

Re: Session state with/without cookies

[Joseph R. Junkin]

This is not a simple answer, but here is my take:
This is only My Opinion.

Rule #1: Design your 'working part' of the app to minimize the
dependence on stored session.

This means to place common actions in the URL.
Some people would say that's messy, but I disagree.
This is because you can 'Walk in' to any part of the app in ANY stage of
the game.
Here is an example, the following views are all based on one record,
Question #14 in a survey.

Here is a complete view of all of the hierarchy:
http://www.datafree.com/demo/dc?s=156-157&p=3&m=n&db=survey&d=f&k=3&a=er

Now I want to isolate that question with it's answers
http://www.datafree.com/demo/dc?s=156-157-158&p=3&m=n&db=survey&d=f&k=197&sn=156-157-158&a=er

Now, just view the question itself:
http://www.datafree.com/demo/dc?s=156-157-158&p=3&m=d&db=survey&d=f&k=197&sn=156-157-158&a=cr

Add a new record?
http://www.datafree.com/demo/dc?s=156-157-158&p=3&m=d&db=survey&d=f&sn=156-157-158&a=cr

Split the screen:
http://www.datafree.com/demo/dc?s=156-157-158&p=3&m=d&db=survey&d=f&k=197&a=er&sw=on

In all of these examples, you are 'Walking In'. The system assigns you
as a guest. As soon as you continue you will notice a UID (u=)
being assigned. What happens if you blow it away? Nothing.
 
Now if you have a 'shopping cart' type of app, you will need to track
session, because you don't want to be passing every product and other
info the User has ordered. I would not store all that crap in cookies
either, but one certainly could.
So you assign each User a session ID.

So now,
You want to track a session,
You need a unique identifier for each session,

Solution:
You must somehow pass a session identifier UID

Popular choices:
1) Part of the URL ie "sessionid=12234"
Drawbacks: 
A) Could be hijacked if someone guesses what it is
Like this:
http://www.datafree.com/demo/dc?s=156-157-158&u=202118935938223051&p=3&m=n&db=survey&d=f&k=204&a=er
Notice that if you continue with the app, you have hijacked that UID.
This is allowed becuse the session is unsecure.

B) Session is lost when the User leaves the site, unless they hit the
back button.


2) Stored in the users browser as a cookie
You can automatically restore the users last session (most people want
this) and anything else about them you want to retain.
You only need to send the UID once, and the user will hand it back every
time.

3) (my choice) Combine the two. 
If the settings permit guest access, the system instantly adapts and
handles the User.
But to update, you must create and account and login.
When you log in, I toss a cookie. If that cookie ain't there bub, you
ain't continuing on (except as a guest). Once logged in, if you disable
cookies I will detect it and switch you back to a guest.
Finally, a combination of URL UID and cookie UID is the only way (I know
of) to allow multiple secure sessions for a single user. A use for this
is for developers to develop online web applications, pause and switch
to an End User view to test, and quickly switch back. In each case, my
system remembers your exact session (last URL, personal settings for
that user) and instantly throws you back where you were. 

Here is a rough flowchart of the process, a bit out of date:
http://www.datacrawler.com/images/main_user_mode.gif

> You have three main choices for maintaining a "session":
> 1) cookies
> 2) mangled URLs
> 3) hidden fields in forms
> If "static HTML" can't do #2 or #3, you are stuck with #1.

I don't understand these answers. What is a mangled URL? I don't
understand the conclusion about static HTML.

Re: Session state without cookies

[Randal L. Schwartz]

> "Trei" == Trei B <[EMAIL PROTECTED]> writes:

Trei> I appreciate your suggestions. I may be missing something in the
Trei> documentation for these modules, but they seem to rely on cookies. I need
Trei> to maintain session state WITHOUT cookies. As I said before this would be
Trei> easy if I only needed the user's session id when they were in the CGI
Trei> application, but I need to maintain that state when they visit static HTML
Trei> and then come back. It seems like an Apache module would be up for this
Trei> task.

You have three main choices for maintaining a "session":

1) cookies
2) mangled URLs
3) hidden fields in forms

If "static HTML" can't do #2 or #3, you are stuck with #1.

No amount of module help can work. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Session state without cookies

[Trei B.]

On Sat, 30 Oct 1999, Stas Bekman wrote:

> On Thu, 28 Oct 1999, Trei Brundrett wrote:
>
> > The only issue I've encountered is the distinct possibility of users without
> > cookies. I've searched the list archive for solutions to this problem, but
> > came up with no definitive answer. The Apache::Session documentation states
> > that this issue is left up to the developer. Are there any existing modules
> > which puts the session id on the query string across both static and dynamic
> > pages and gives you easy access to that value so you can utilize it in a
> > CGI? If there isn't an existing module - does anyone have anything in
> > development?
> 
> CGI::Cookie
> Apache::Cookie

I appreciate your suggestions. I may be missing something in the
documentation for these modules, but they seem to rely on cookies. I need
to maintain session state WITHOUT cookies. As I said before this would be
easy if I only needed the user's session id when they were in the CGI
application, but I need to maintain that state when they visit static HTML
and then come back. It seems like an Apache module would be up for this
task.

thanks,
Trei Brundrett

Re: Session state without cookies

[Stas Bekman]

On Thu, 28 Oct 1999, Trei Brundrett wrote:

> I'm reworking an existing web store CGI script to better handle shopping
> carts. I'm going to use Apache::Session to manage these shopper sessions.
> The store is a mixture of static HTML and CGI generated pages and I want to
> maintain the session across the entire site.
> 
> The only issue I've encountered is the distinct possibility of users without
> cookies. I've searched the list archive for solutions to this problem, but
> came up with no definitive answer. The Apache::Session documentation states
> that this issue is left up to the developer. Are there any existing modules
> which puts the session id on the query string across both static and dynamic
> pages and gives you easy access to that value so you can utilize it in a
> CGI? If there isn't an existing module - does anyone have anything in
> development?

CGI::Cookie
Apache::Cookie

> 
> thanks,
> Trei Brundrett
> -
> [EMAIL PROTECTED]
> http://www.mediatruck.com
> Mediatruck, Inc.
> -
> 
> 



___
Stas Bekman  mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas  
Perl,CGI,Apache,Linux,Web,Java,PC at  www.singlesheaven.com/stas/TULARC
www.apache.org  & www.perl.com  == www.modperl.com  ||  perl.apache.org
single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com