information (MVC related, maybe...)
Perrin Harkins writes:
My preferred design for this is to set one cookie that lasts forever and
serves as a browser ID.
I like this. It's clean and simple. In this sense, a browser is not
really a session. The only thing I don't like is garbage collection
I am not sure if I follow completely. How do you verify that user who the
user says he/she is?
I log into your web-site as memberA. You kindly leave me a delicious cookie
with my username stored in it. Maybe even my password (I hope not!). Now,
I know that another member, memberB, has special
At 07:32 AM 6/13/02 -0700, Vuillemot, Ward W wrote:
I log into your web-site as memberA. You kindly leave me a delicious cookie
with my username stored in it. Maybe even my password (I hope not!). Now,
I know that another member, memberB, has special rights to your site. What
is stopping me
Vuillemot, Ward W writes:
I log into your web-site as memberA. You kindly leave me a delicious cookie
with my username stored in it. Maybe even my password (I hope not!). Now,
I know that another member, memberB, has special rights to your site. What
is stopping me from editting the
On 6/13/02 11:04 AM, Rob Nagler wrote:
With sessionID, you have an ID and information that is checksum'd.
Sessions and user IDs are equivalent. They are called credentials
which allow access to a system. There's no fundamental difference
between hijacking a session or stealing a user
Rob Nagler wrote:
A session is useful for very limited things, like remembering if this
user is logged in and linking him to a user_id.
We store this information in the cookie. I don't see how it could be
otherwise. It's the browser that maintains the login state.
My preferred design
Perrin Harkins writes:
My preferred design for this is to set one cookie that lasts forever and
serves as a browser ID.
I like this. It's clean and simple. In this sense, a browser is not
really a session. The only thing I don't like is garbage collection.
unique browser ID (or session
I was wondering how people are saving state between pages of a session.
There is a Apache::Session which is sufficient to check to see if they are
logged in, et cetera.
But I want to be able to remember the last query so that I can return
results into multple pages along with memory of where in
Vuillemot, Ward W wrote:
There is a Apache::Session which is sufficient to check to see if they are
logged in, et cetera.
But I want to be able to remember the last query so that I can return
results into multple pages along with memory of where in the stack I am at.
You can store anything
On Wed, 12 Jun 2002, Vuillemot, Ward W wrote:
Date: Wed, 12 Jun 2002 06:58:24 -0700
From: Vuillemot, Ward W [EMAIL PROTECTED]
To: 'Peter Bi' [EMAIL PROTECTED], [EMAIL PROTECTED],
Eric Frazier [EMAIL PROTECTED]
Subject: mod_perl/passing session information (MVC related, maybe...)
I
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: 12 June 2002 15:11
You can store anything in Apache::Session; it's just a persistent hash
table. However, storing query results based on a user's session is
not
a good idea! What if your users open up two browser windows and tries
From: Ken Y. Clark [mailto:[EMAIL PROTECTED]]
Sent: 12 June 2002 15:39
I've munged the query results in Perl and a couple template
packages to make each link contain everything necessary to
perform the query again (including every parameter from the
original request) and putting in
Jeff AA wrote:
Agreed, but he wasn't talking about storing the results, just the query
parameters and current offset / number of rows, which is a-ok for
putting into a session.
No, that's exactly what ISN'T okay for putting into a session. If a
user opens two browser windows, does a search
Hi,
I don't know this term query hijack can you put it in different words?
Thanks,
Eric
At 03:54 PM 2002-06-12 +0100, you wrote:
Do put the user_id into the query session and check it against the
user_id in the User session to prevent query hijack
From: Eric Frazier [mailto:[EMAIL PROTECTED]]
Sent: 12 June 2002 16:52
I don't know this term query hijack can you put it in different
words?
Lets say your user who is the boss makes a query
'show me everyone's salary'
and your system checks who he is, and because he is the boss,
John Siracusa [EMAIL PROTECTED] wrote:
On 6/12/02 12:17 PM, Perrin Harkins wrote:
James G Smith wrote:
The nice thing about the context then is that customers can have
multiple ones for multiple windows and they can have more than they
have windows.
How do you tie a context to a window? I
Jeff AA writes:
An advantage of the session/id is that you end up with stateful query
instances,
Stateful instances are also problematic. You have essentially two
paths through the code: first time and subsequent time. If you write
the code statelessly, there is only one path. Fewer bugs,
At 18:20 12.06.2002, John Siracusa wrote:
On 6/12/02 12:17 PM, Perrin Harkins wrote:
James G Smith wrote:
The nice thing about the context then is that customers can have
multiple ones for multiple windows and they can have more than they
have windows.
How do you tie a context to a
On 6/12/02 12:57 PM, Per Einar Ellefsen wrote:
But what if someone opens one of the links in a different window, and
continue on the same pages as in the original window, but with different
parameters? The session ID would be the same, the context id would be the
same, but the params would be
John Siracusa wrote:
On 6/12/02 12:57 PM, Per Einar Ellefsen wrote:
But what if someone opens one of the links in a different window, and
continue on the same pages as in the original window, but with different
parameters? The session ID would be the same, the context id would be the
same, but
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: 12 June 2002 16:29
Agreed, but he wasn't talking about storing the results, just the
query
parameters and current offset / number of rows, which is a-ok for
putting into a session.
No, that's exactly what ISN'T okay for
Rob Nagler wrote:
Stateful instances are also problematic. You have essentially two
paths through the code: first time and subsequent time. If you write
the code statelessly, there is only one path. Fewer bugs, smaller
code, less development.
I find you can tie this cache stuff up inside
Jeff AA wrote:
Interestingly MySQL and other DBs are often as fast as simple disk
access - contrary to popular wisdom, most DB engines actually cache in
memory, with more data access information and hence effective cache
memory usage than is available to external cache components. Yes,
- Original Message -
From: John Siracusa [EMAIL PROTECTED]
To: Mod Perl Mailing List [EMAIL PROTECTED]
Sent: Wednesday, June 12, 2002 8:06 PM
Subject: Re: mod_perl/passing session information (MVC related, maybe...)
On 6/12/02 12:57 PM, Per Einar Ellefsen wrote:
But what if someone
Perrin Harkins writes:
I find you can tie this cache stuff up inside of your data access
objects and make it all transparent to the other code.
Absolutely.
A session is useful for very limited things, like remembering if this
user is logged in and linking him to a user_id.
We store this
25 matches
Mail list logo
