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: [EMAIL PROTECTED] Voice: +49 6133 925151
> > WWW: http://www.ecos.de Fax: +49 6133 925152
> > -------------------------------------------------------------
