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 t
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
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 sepa
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 diffe
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
> 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 sessi
> 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
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 co
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'
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 c
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
>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
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
> >
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 solut
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
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 "lo
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
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 differe
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 use
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
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 jus
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 Chri
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 _see
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
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 you
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 us
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 metho
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
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.
> -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]) sa
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]
> > Subjec
> -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
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 th
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 i
> 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.
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 ).
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 pl
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
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
> 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 wi
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 han
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 han
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 'pa
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 Apac
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
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 poss
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 Perfor
> "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 s
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 prov
> "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.
>>
>
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 se
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
> "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
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:
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 ac
55 matches
Mail list logo
