ct: Re: mod_perl/passing session 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
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
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
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 us
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 co
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
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
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 th
- 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
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,
> N
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
> Sent: 12 June 2002 18:15
> Right, which is why you shouldn't try to store server-side state
> for anything that could be different in multiple browser windows.
> Only store global browser information on the server-side. Everything
> else h
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 insi
> 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 f
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
>>
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
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
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,
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 contex
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 don't see any reliable way to
> 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, al
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 don't see any reliable way to
do it. The only way to maintain state for a window
Perrin Harkins <[EMAIL PROTECTED]> wrote:
>Jeff AA wrote:
>> Don't mix transient query sessions with a User Session that stores info
>> about the user's logged in state etc. It would be normal for one user to
>> have multiple queries in a login session
>
>Hold on, I think we actually agree, but yo
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
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 searc
> 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
> 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 tr
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]>
> Subje
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 anythin
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
29 matches
Mail list logo
