You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Greg Cope <gj...@rubberplant.freeserve.co.uk> on 2000/07/29 15:07:20 UTC
was Re: template kit..... - now session handling
Gerald Richter wrote:
>
> > I sure think that this template discussion is
> > intresting, forms autofill is one thing but another
> > thing that i think would be neat is if the kit could
> > do session handling, like the Apache::ASP. Can embperl
> > or mason do this fancy stuff.
> >
>
> Embperl can do session handling. It uses Apache::Session for storage and
> cares about the rest for you. You simply put the values for the user session
> in the hash %udat and they will be automaticly restored when the same user
> does the next request. Currently Embperl uses Cookies to store a session id
> witht in the browser. For Embperl 2.0 I plan to support also URL rewriting.
I posted about a generic URL mangeler / cookie session handler a few
days ago.
Allthough this is not rocket science - I've writen a URI transhandler
that will put the session id into pnotes, and if cookies are off will do
a redirect to itself with a munged URL
(www.foo.com/id_here/original_bit_here). A quick uri rewrite and bob's
one of your parents sister. The only major issue is that I cannot
appear to use posted values as they appear to get lost in the redirect
(Clues wanted !).
It appears that a few other people would want a session handler that can
do this transparent and then they can use Apache::Session to do the
rest.
Can I recommend you write a simple, standalone module that everyone can
use and not just an embperl solution - I'd be willing to help (or write
it) if people send me their wants / ideas, and then flame my code when I
think its ready!
Greg
> Gerald
>
> -------------------------------------------------------------
> Gerald Richter ecos electronic communication services gmbh
> Internetconnect * Webserver/-design/-datenbanken * Consulting
>
> Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> E-Mail: richter@ecos.de Voice: +49 6133 925151
> WWW: http://www.ecos.de Fax: +49 6133 925152
> -------------------------------------------------------------
Re: was Re: template kit..... - now session handling
Posted by Drew Taylor <dt...@vialogix.com>.
Greg Cope wrote:
>
> I posted about a generic URL mangeler / cookie session handler a few
> days ago.
>
> Allthough this is not rocket science - I've writen a URI transhandler
> that will put the session id into pnotes, and if cookies are off will do
> a redirect to itself with a munged URL
> (www.foo.com/id_here/original_bit_here). A quick uri rewrite and bob's
> one of your parents sister. The only major issue is that I cannot
> appear to use posted values as they appear to get lost in the redirect
> (Clues wanted !).
>
> It appears that a few other people would want a session handler that can
> do this transparent and then they can use Apache::Session to do the
> rest.
At the risk of sounding like an AOL'er - Me Too! :-)
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Re: was Re: template kit..... - now session handling
Posted by Leon Brocard <ac...@astray.com>.
Gerald Richter sent the following bits through the ether:
> Jeffery don't want to build something like this into Apache::Session. He
> always expressed that Apache::Session is just a framework for storing
> session data!
If this is still the case then I think a name change is in order...
Leon
--
Leon Brocard.............................http://www.astray.com/
yapc::Europe - September 22-24 London - http://yapc.org/Europe/
... Error 404: .signature generator ran out of tuits
RE: was Re: template kit..... - now session handling
Posted by Perrin Harkins <pe...@primenet.com>.
On Wed, 2 Aug 2000, Jeffrey W. Baker wrote:
> 2) The name change should happen. However, there is already a
> Persistent:: set of classes, that is somewhat similar to Apache::Session.
> For example, it implements LDAP, MySQL, Oracle, Sybase, mSQL, and File
> storage. These classes use all object calls
> e.g. $persistent->add_attribute(). So the chief difference seems to be
> the flexibility of the tied interface of Apache::Session (also mine is
> faster :) So how does Persistent::TiedHash sound?
I was about to say Tie::Persistent, but that's taken too...
Personally I use the object methods, but I think Persistent::TiedHash is
fine.
- Perrin
RE: was Re: template kit..... - now session handling
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On Mon, 31 Jul 2000, brian moseley wrote:
> On Mon, 31 Jul 2000, Perrin Harkins wrote:
>
> > Since it isn't really tied to HTTP or sessions, that
> > would be kind of a misnomer as well. Jeff already
> > suggested Persistent::Hash at once point, but changing
> > namespace on CPAN always confuses some people. There
> > are still people who get confused about the original
> > Apache::Session module that was replaced by Jeff's.
>
> people who get confused by name changes should not be
> catered to.
I wasn't following this thread, because the subject was "template
kit." Now I shall reply all in one shot.
1) A cookie/token management module will *not* be built into
Apache::Session. The functionality is orthogonal. (i.e. Gerald is
right).
2) The name change should happen. However, there is already a
Persistent:: set of classes, that is somewhat similar to Apache::Session.
For example, it implements LDAP, MySQL, Oracle, Sybase, mSQL, and File
storage. These classes use all object calls
e.g. $persistent->add_attribute(). So the chief difference seems to be
the flexibility of the tied interface of Apache::Session (also mine is
faster :) So how does Persistent::TiedHash sound?
3) The Apache::Session name whould be used for a module that actually
manages the interaction between mod_perl and the browser. The only
problem I can see is that this module would have to start out at 2.0 or
something, to avoid confusing CPAN. ALternately, it could be called
Apache::SessionManager instead.
-jwb
RE: was Re: template kit..... - now session handling
Posted by brian moseley <bc...@maz.org>.
On Mon, 31 Jul 2000, Perrin Harkins wrote:
> Since it isn't really tied to HTTP or sessions, that
> would be kind of a misnomer as well. Jeff already
> suggested Persistent::Hash at once point, but changing
> namespace on CPAN always confuses some people. There
> are still people who get confused about the original
> Apache::Session module that was replaced by Jeff's.
people who get confused by name changes should not be
catered to.
RE: was Re: template kit..... - now session handling
Posted by Perrin Harkins <pe...@primenet.com>.
On Sun, 30 Jul 2000, brian moseley wrote:
> using this vocabulary, i'd like to suggest that jeff's
> module be renamed HTTP::SessionPersistence.
Since it isn't really tied to HTTP or sessions, that would be kind of a
misnomer as well. Jeff already suggested Persistent::Hash at once point,
but changing namespace on CPAN always confuses some people. There are
still people who get confused about the original Apache::Session module
that was replaced by Jeff's.
- Perrin
RE: was Re: template kit..... - now session handling
Posted by brian moseley <bc...@maz.org>.
On Sun, 30 Jul 2000, Gerald Richter wrote:
> Jeffery don't want to build something like this into
> Apache::Session. He always expressed that
> Apache::Session is just a framework for storing session
> data!
it would be nice if we could agree on some vocabulary
relating to 'session management', which is an altogether too
vague phrase.
personally i like to use 'session tracking' to describe
encoding/decoding session tokens in http requests/responses,
and 'session persistence' to describe materializing and
storing session data in a persistent store.
using this vocabulary, i'd like to suggest that jeff's
module be renamed HTTP::SessionPersistence. ok ok, that's a
bit tongue in cheek, but you get my drift. people would stop
a) assuming you have to use mod_perl to get any benefit from
the module and b) wondering why it doesn't do session
tracking.
on a related note, i really like the way that sessions are
handled in in my tomcat port. take a look when i make it
available, maybe you'll see what i mean.
RE: was Re: template kit..... - now session handling
Posted by Gerald Richter <ri...@ecos.de>.
> >
> > If you do this, build it into Apache::Session! Leverage the existing
> > storage mechanisms built in there already (file, DBI, etc). My only
> > other feature requests for this:
>
Jeffery don't want to build something like this into Apache::Session. He
always expressed that Apache::Session is just a framework for storing
session data!
> Why not have something that is generic that can work with
> Apache::Session, and on its own.
Yes
Gerald
Re: was Re: template kit..... - now session handling
Posted by Greg Cope <gj...@rubberplant.freeserve.co.uk>.
Ian Kallen wrote:
>
> Today, Greg Cope <gj...@rubberplant.freeserve.co.uk> frothed and...:
> > I posted about a generic URL mangeler / cookie session handler a few
> > days ago.
> >
> > Allthough this is not rocket science - I've writen a URI transhandler
> > that will put the session id into pnotes, and if cookies are off will do
> > a redirect to itself with a munged URL
> > (www.foo.com/id_here/original_bit_here). A quick uri rewrite and bob's
> > one of your parents sister. The only major issue is that I cannot
>
> Two separate issues, two separate replies :)
>
> If you do this, build it into Apache::Session! Leverage the existing
> storage mechanisms built in there already (file, DBI, etc). My only
> other feature requests for this:
Why not have something that is generic that can work with
Apache::Session, and on its own. Why - well some people may not like a
monothic session system, and may just wish to use one or the other. For
example I am presently only using sessions to store a Database ID, and
that stores any data I like. I am presently not using Apache::Session
(but thinking about it!)
>
> 1) include a %no_url_munging hash with user agents for known
> indexing spider storage. You don't want inktomi or altavista returing
> munged URL's in search results!
I'm already including an option that will do a URI match and only
session bit that match a simple REGEX - so certain areas of a domain /
site can be non-sessioned.
Including a hash that has indexers in is no big deal - Joshua from
Apache::ASP fame has a different spin and suggests using the query args
instead of URI rewriting which could help to solve this issue.
> 2) Have it configurable so that the url munger session pnote'ing can be
> turned off or on.
So if cookies are on then put the session id into pnotes else do not do
the redirect / url_munling bit - is that what you mean ?
Thanks for the pointers
Greg Cope
>
> I think without these features, url munging session mgt is pretty
> worthless.
>
> --
> Salon Internet http://www.salon.com/
> Manager, Software and Systems "Livin' La Vida Unix!"
> Ian Kallen <id...@salon.com> / AIM: iankallen / Fax: (415) 354-3326
Re: was Re: template kit..... - now session handling
Posted by Ian Kallen <sp...@salon.com>.
Today, Greg Cope <gj...@rubberplant.freeserve.co.uk> frothed and...:
> I posted about a generic URL mangeler / cookie session handler a few
> days ago.
>
> Allthough this is not rocket science - I've writen a URI transhandler
> that will put the session id into pnotes, and if cookies are off will do
> a redirect to itself with a munged URL
> (www.foo.com/id_here/original_bit_here). A quick uri rewrite and bob's
> one of your parents sister. The only major issue is that I cannot
Two separate issues, two separate replies :)
If you do this, build it into Apache::Session! Leverage the existing
storage mechanisms built in there already (file, DBI, etc). My only
other feature requests for this:
1) include a %no_url_munging hash with user agents for known
indexing spider storage. You don't want inktomi or altavista returing
munged URL's in search results!
2) Have it configurable so that the url munger session pnote'ing can be
turned off or on.
I think without these features, url munging session mgt is pretty
worthless.
--
Salon Internet http://www.salon.com/
Manager, Software and Systems "Livin' La Vida Unix!"
Ian Kallen <id...@salon.com> / AIM: iankallen / Fax: (415) 354-3326
RE: was Re: template kit..... - now session handling
Posted by Ian Kallen <sp...@salon.com>.
Today, Gerald Richter <ri...@ecos.de> frothed and gesticulated about RE:...:
> > Ian Kallen suggested a hash of know indexers - which is a good idea -
>
> Yes
>
> > but has one problem of how to keep this upto date.
> >
>
> Everybody could contribute and there could some (CPAN) where you can
> download an uptodate list
My thoughts along that line were more for a general browsercap -- I think
the PHP community has already broke some ground down that road. A basic
list of user agent ID's and some of their characteristics. This is
actually much broader than these needs for a URI based session mgt,
broader than the Perl community's needs so it should probably be
spearheaded separately and be implemented as XML (no, I don't have the
time to do this myself, I do wish for more free time though...) I don't
think ASP and PHP browsercap data is in XML now (haven't checked lately)
but it should be ;)
Someone on this list probably has more time on their hands than me to make
this happen. In lieu of a DTD (not needed here really) I'd be happy to
provide an XML model of what data would be needed :)
-Ian
--
Salon Internet http://www.salon.com/
Manager, Software and Systems "Livin' La Vida Unix!"
Ian Kallen <id...@salon.com> / AIM: iankallen / Fax: (415) 354-3326
RE: was Re: template kit..... - now session handling
Posted by Gerald Richter <ri...@ecos.de>.
>
> I've looked thorugh Apache::Asp session code and saw your args method.
>
We should of course use anything that Joshua already has figured out. Maybe
the module could be written in a way that Apache::ASP can take use of it.
That would be the best thing from my point of view!
> Ian Kallen suggested a hash of know indexers - which is a good idea -
Yes
> but has one problem of how to keep this upto date.
>
Everybody could contribute and there could some (CPAN) where you can
download an uptodate list
> A few issues that have been brought to my attention are:
>
> 1 - Wherethere to use URI rewriting - and hence the indexer issue - or
> to rewrite query args (i.e remove a session arg and place it into a
> pnotes entry). So that hopefully clever indexers will ignore the last
> bit.
>
I am not sure, but I think most search eniges will not index pages with
query_strings at all
I would most love to make it configurable, so that the user can choose,
which way he/she prefers.
> 2 - The HTTP_REFERER leaking is an issue that people need to be aware of
> - I could make a quick redirect filter that could remove the session
> id. This can also help with click throughs etc. I am not aiming to do
> any checking of the session id - thats left to something else.
>
Such a filter would be a helpfull thing
> 3 - When to redirect to check for cookies etc. i.e. when a client comes
> in without any session info do we imediately redirect to try and set a
> cookie, and then use that or else do something else. Or only check
> after the secound request.
>
Make it configurable
> 4 - Defining what a session is may be helpfull. What I call a session
> others may disagree. I need to scope what I'm going to write -
> otherwise I be redoing it every 5 minutes! My spin on a session is
> something that needs to be tracked - and I usually only do this when I
> have to.
I would agree to that
Gerald
Re: was Re: template kit..... - now session handling
Posted by Greg Cope <gj...@rubberplant.freeserve.co.uk>.
Joshua Chamas wrote:
>
> Greg & Gerald,
>
> I wanted to bring an important issue that came up with
> Apache::ASP, how will you deal with search engines indexing
> the session-ids in the URL?
>
> In Apache::ASP, this is handled a couple of ways, first the
> session-id is stored as a query string param, not in the path
> to give a hint at its dynamic nature for smarter search engines
> that respect this, but more important, there is detection that if
> the incoming session is not active, a new session id will
> be assigned to the end user. This will prevent users that come
> from a search engine to all have the same session id.
>
> I don't know how this latter might be dealt with in this case
> except by perhaps some runtime checking with Apache::Session
> for existence, and then a redirect at that time to a new URL
> with the right session-id? The Apache::ASP query string
> SessionQueryParse implementation makes changing the id without
> redirection possible, but at the expense of runtime buffer
> URL parsing for those without cookies.
>
> Also note that a developer should be made aware of the security
> implications associated with off site HTTP_REFERER logging
> of one's session id, so that a developer can work around this
> accordingly. In Apache::ASP, I just am careful to warn about
> this issue in the docs and give a appropriate workaround:
>
> http://www.nodeworks.com/asp/sessions.html
Thanks Joshua
I've looked thorugh Apache::Asp session code and saw your args method.
Ian Kallen suggested a hash of know indexers - which is a good idea -
but has one problem of how to keep this upto date.
A few issues that have been brought to my attention are:
1 - Wherethere to use URI rewriting - and hence the indexer issue - or
to rewrite query args (i.e remove a session arg and place it into a
pnotes entry). So that hopefully clever indexers will ignore the last
bit.
2 - The HTTP_REFERER leaking is an issue that people need to be aware of
- I could make a quick redirect filter that could remove the session
id. This can also help with click throughs etc. I am not aiming to do
any checking of the session id - thats left to something else.
3 - When to redirect to check for cookies etc. i.e. when a client comes
in without any session info do we imediately redirect to try and set a
cookie, and then use that or else do something else. Or only check
after the secound request.
4 - Defining what a session is may be helpfull. What I call a session
others may disagree. I need to scope what I'm going to write -
otherwise I be redoing it every 5 minutes! My spin on a session is
something that needs to be tracked - and I usually only do this when I
have to. Others may define a session as any user interaction within a
small time frame on thier site so that they can track a users click
though (TMTOWTDI on this front I know).
Please send me any comments.
Thanks again Joshua
Greg Cope
>
> Its a nice feature to get right when its finally working. Enjoy!
>
> --Joshua
>
<snippage>
Re: was Re: template kit..... - now session handling
Posted by Joshua Chamas <jo...@chamas.com>.
Greg & Gerald,
I wanted to bring an important issue that came up with
Apache::ASP, how will you deal with search engines indexing
the session-ids in the URL?
In Apache::ASP, this is handled a couple of ways, first the
session-id is stored as a query string param, not in the path
to give a hint at its dynamic nature for smarter search engines
that respect this, but more important, there is detection that if
the incoming session is not active, a new session id will
be assigned to the end user. This will prevent users that come
from a search engine to all have the same session id.
I don't know how this latter might be dealt with in this case
except by perhaps some runtime checking with Apache::Session
for existence, and then a redirect at that time to a new URL
with the right session-id? The Apache::ASP query string
SessionQueryParse implementation makes changing the id without
redirection possible, but at the expense of runtime buffer
URL parsing for those without cookies.
Also note that a developer should be made aware of the security
implications associated with off site HTTP_REFERER logging
of one's session id, so that a developer can work around this
accordingly. In Apache::ASP, I just am careful to warn about
this issue in the docs and give a appropriate workaround:
http://www.nodeworks.com/asp/sessions.html
Its a nice feature to get right when its finally working. Enjoy!
--Joshua
Greg Cope wrote:
>
> Gerald Richter wrote:
> >
> > Hi Greg,
> > >
> > > As far as I am aware (please someone prove me wrong!) the does not
> > > appear to be such a module.
> > >
> >
> > I meant the module your are about to write :-)
> >
> > >
> > > Please send me ideas / thoughs and I'll have a go.
> > >
> >
> > Embperl currently goes the way that it sets up a tied hash at load time (so
> > it only has to be done once) and monitor wherever somebody is writing to
> > this hash. Only in the case that a element of the hash is modified, Embperl
> > generates a session id (actually Apache::Session does it) and sends the
> > cookie to the browser. Therefore I don't have to configure anything to use
> > session management (of course you can configure several parameteress, like
> > cookie domain etc.), because if the page stores some data in the hash,
> > session management is enabled in all other cases it isn't used. That make
> > session management as transparanet as possible for the programmer. When a
> > new request starts, Embperl checks if there is a session id send in a cookie
>
> So therefore would it not be easy to modify your code to check for a
> pnotes entry called session and cookies ?
>
> If session is set then use that.
>
> If cookie is set (ie 1) then assume cookies are on! else if you have a
> session and cookies are off then rewrite your urls to include the
> session ID ?
>
> > from the browser and tells Apache::Session to restore the data in the
> > session hash.
> >
> > This shema may not work, with session id in the url, because you need to do
> > the redirect before the page is executed. Because Embperl anyways parses the
> > page, it would be no overhead to rewrite all hrefs (and other urls) on the
> > fly. I have not thought very much about, what is the best way to go here.
>
> Ok - remeber that the URI transhandler stage is before nearly all the
> others - hence a redirect should work.
>
> If the session ID is in the uri I rewrite the uri to exclude it thus:
>
> www.foo.com/123234345356/index.pl
>
> would get rewritten to:
>
> www.foo.com/index.pl
>
> and
>
> 123234345356 would get put into a pnotes entry called session and
> cookie_on would be set to O!
>
> If the redirect needs to happen then the emb perl page would never be
> executed until after the redirect as the embperl handler is after the
> transhandler stage - or have I got emb perl completely wrong ?
> >
> > This should give you a short impression what Embperl does, now we have to
> > think about how we can bring this together with a general module.
>
> Unless you can see nothing wrong with the above I should be able to put
> something basic together over the next few days ... documentation may be
> a bit lacking mind ...
>
> Is the pnotes issue OK ? or should we use an Environment Variable to
> transfere the data between handlers ?
>
> What other issue do you have ?
>
> Greg
>
> >
> > Gerald
> >
> > -------------------------------------------------------------
> > Gerald Richter ecos electronic communication services gmbh
> > Internetconnect * Webserver/-design/-datenbanken * Consulting
> >
> > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> > E-Mail: richter@ecos.de Voice: +49 6133 925151
> > WWW: http://www.ecos.de Fax: +49 6133 925152
> > -------------------------------------------------------------
RE: was Re: template kit..... - now session handling
Posted by Gerald Richter <ri...@ecos.de>.
>
> So therefore would it not be easy to modify your code to check for a
> pnotes entry called session and cookies ?
>
Yes, of course this would be very easy
> If session is set then use that.
>
> If cookie is set (ie 1) then assume cookies are on! else if you have a
> session and cookies are off then rewrite your urls to include the
> session ID ?
ok so far
>
> Ok - remeber that the URI transhandler stage is before nearly all the
> others - hence a redirect should work.
>
Exactly this is the problem. Not for the second request, because you already
know (by cookie or session id in the url) that you are has a page that
useses sessions, but for the first request.
In your case you need something that tells your TransHandler that it should
generate a session id (and cookie or a redirect), while it shouldn't do this
for other pages. As far as I understand you do this by the use of a REGEX
that must be somewhere configured. In oppostite to that aproach, Embperl
simply looks at his session hash and see if something is modify and only if
somethings is written into this hash, the session id is generated and the
cookie is send. In this way, I don't need to configure which page useses
session handling and which not.
>
> Is the pnotes issue OK ? or should we use an Environment Variable to
> transfere the data between handlers ?
>
pnotes is ok for mod_perl, Embperl session handling also works when running
as CGI, where we don't have pnotes. Maybe we can simply use some globals to
pass the data, additional to the pnotes. The globals will work under
mod_perl (also under 2.0) and CGI
Gerald
Re: was Re: template kit..... - now session handling
Posted by Greg Cope <gj...@rubberplant.freeserve.co.uk>.
Gerald Richter wrote:
>
> Hi Greg,
> >
> > As far as I am aware (please someone prove me wrong!) the does not
> > appear to be such a module.
> >
>
> I meant the module your are about to write :-)
>
> >
> > Please send me ideas / thoughs and I'll have a go.
> >
>
> Embperl currently goes the way that it sets up a tied hash at load time (so
> it only has to be done once) and monitor wherever somebody is writing to
> this hash. Only in the case that a element of the hash is modified, Embperl
> generates a session id (actually Apache::Session does it) and sends the
> cookie to the browser. Therefore I don't have to configure anything to use
> session management (of course you can configure several parameteress, like
> cookie domain etc.), because if the page stores some data in the hash,
> session management is enabled in all other cases it isn't used. That make
> session management as transparanet as possible for the programmer. When a
> new request starts, Embperl checks if there is a session id send in a cookie
So therefore would it not be easy to modify your code to check for a
pnotes entry called session and cookies ?
If session is set then use that.
If cookie is set (ie 1) then assume cookies are on! else if you have a
session and cookies are off then rewrite your urls to include the
session ID ?
> from the browser and tells Apache::Session to restore the data in the
> session hash.
>
> This shema may not work, with session id in the url, because you need to do
> the redirect before the page is executed. Because Embperl anyways parses the
> page, it would be no overhead to rewrite all hrefs (and other urls) on the
> fly. I have not thought very much about, what is the best way to go here.
Ok - remeber that the URI transhandler stage is before nearly all the
others - hence a redirect should work.
If the session ID is in the uri I rewrite the uri to exclude it thus:
www.foo.com/123234345356/index.pl
would get rewritten to:
www.foo.com/index.pl
and
123234345356 would get put into a pnotes entry called session and
cookie_on would be set to O!
If the redirect needs to happen then the emb perl page would never be
executed until after the redirect as the embperl handler is after the
transhandler stage - or have I got emb perl completely wrong ?
>
> This should give you a short impression what Embperl does, now we have to
> think about how we can bring this together with a general module.
Unless you can see nothing wrong with the above I should be able to put
something basic together over the next few days ... documentation may be
a bit lacking mind ...
Is the pnotes issue OK ? or should we use an Environment Variable to
transfere the data between handlers ?
What other issue do you have ?
Greg
>
> Gerald
>
> -------------------------------------------------------------
> Gerald Richter ecos electronic communication services gmbh
> Internetconnect * Webserver/-design/-datenbanken * Consulting
>
> Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> E-Mail: richter@ecos.de Voice: +49 6133 925151
> WWW: http://www.ecos.de Fax: +49 6133 925152
> -------------------------------------------------------------
RE: was Re: template kit..... - now session handling
Posted by Gerald Richter <ri...@ecos.de>.
Hi Greg,
>
> As far as I am aware (please someone prove me wrong!) the does not
> appear to be such a module.
>
I meant the module your are about to write :-)
>
> Please send me ideas / thoughs and I'll have a go.
>
Embperl currently goes the way that it sets up a tied hash at load time (so
it only has to be done once) and monitor wherever somebody is writing to
this hash. Only in the case that a element of the hash is modified, Embperl
generates a session id (actually Apache::Session does it) and sends the
cookie to the browser. Therefore I don't have to configure anything to use
session management (of course you can configure several parameteress, like
cookie domain etc.), because if the page stores some data in the hash,
session management is enabled in all other cases it isn't used. That make
session management as transparanet as possible for the programmer. When a
new request starts, Embperl checks if there is a session id send in a cookie
from the browser and tells Apache::Session to restore the data in the
session hash.
This shema may not work, with session id in the url, because you need to do
the redirect before the page is executed. Because Embperl anyways parses the
page, it would be no overhead to rewrite all hrefs (and other urls) on the
fly. I have not thought very much about, what is the best way to go here.
This should give you a short impression what Embperl does, now we have to
think about how we can bring this together with a general module.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: was Re: template kit..... - now session handling
Posted by Greg Cope <gj...@rubberplant.freeserve.co.uk>.
Gerald Richter wrote:
>
> Hi Greg,
>
> >
> > Can I recommend you write a simple, standalone module that everyone can
> > use and not just an embperl solution - I'd be willing to help (or write
> > it) if people send me their wants / ideas, and then flame my code when I
> > think its ready!
> >
>
> I would be happy if there is an standalone module that handles uri
> translation and cookie checking and so on. I always like more to use
> existing solution, then reinventing the wheel (that's one reason why I use
> Apache::Session in Embperl).
As far as I am aware (please someone prove me wrong!) the does not
appear to be such a module.
> Embperl has some special needs, because it makes the session handling totaly
> transparent to the programmer (he has just to put his values in a hash), but
> if you create such a module (or extent the already existing one), I would be
> happy to take a look at it and make it work with Embperl.
I would be more than happy to rewrite what I have based on what you /
others want.
My module needs alot of tydying to be anything like the standard of the
code found here, mine also includes session checking code (DB lookups).
Can you and any others please post ideas of what you/they want ? Some
people have already done such a module so if they can chirp up with
thier wish lists then that would be great.
So far I have something that:
a) Checks the URI (simple regex) to see if its a URI that needs
"Sessioning"
b) Checks for cookies first
c) puts data into pnotes (name anyone ? (I used UID, SID and
COOKIES_ON)) or we could use sub env variables
d) then checks for a session id in a URI.
e) redirects to session id uri if non present.
>
> Gerald
>
> P.S. Could you resend me your module, because I have missed it on the list
You did not miss anything I never sent anything - too embarassed!
Please send me ideas / thoughs and I'll have a go.
Greg
>
> -------------------------------------------------------------
> Gerald Richter ecos electronic communication services gmbh
> Internetconnect * Webserver/-design/-datenbanken * Consulting
>
> Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> E-Mail: richter@ecos.de Voice: +49 6133 925151
> WWW: http://www.ecos.de Fax: +49 6133 925152
> -------------------------------------------------------------
RE: was Re: template kit..... - now session handling
Posted by Gerald Richter <ri...@ecos.de>.
Hi Greg,
>
> Can I recommend you write a simple, standalone module that everyone can
> use and not just an embperl solution - I'd be willing to help (or write
> it) if people send me their wants / ideas, and then flame my code when I
> think its ready!
>
I would be happy if there is an standalone module that handles uri
translation and cookie checking and so on. I always like more to use
existing solution, then reinventing the wheel (that's one reason why I use
Apache::Session in Embperl).
Embperl has some special needs, because it makes the session handling totaly
transparent to the programmer (he has just to put his values in a hash), but
if you create such a module (or extent the already existing one), I would be
happy to take a look at it and make it work with Embperl.
Gerald
P.S. Could you resend me your module, because I have missed it on the list
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: was Re: template kit..... - now session handling
Posted by Ian Kallen <sp...@salon.com>.
Today, Greg Cope <gj...@rubberplant.freeserve.co.uk> frothed and...:
> one of your parents sister. The only major issue is that I cannot
> appear to use posted values as they appear to get lost in the redirect
> (Clues wanted !).
Redirecting a POST request? Yup, expediency often requires violating the
HTTP spec. Though your requests are probably hanging cause they want to
read STDIN again, this should probably get patched -- haven't looked at
the mod_perl source voodoo on this issue (Doug?). Meantime, see if this
remedies:
$r->method('GET');
$r->headers_in->unset('Content-length');
$r->header_out(Location => 'http://wwww.bletch.com');
--
Salon Internet http://www.salon.com/
Manager, Software and Systems "Livin' La Vida Unix!"
Ian Kallen <id...@salon.com> / AIM: iankallen / Fax: (415) 354-3326