"Quinton McCombs" <[EMAIL PROTECTED]> writes:
>There are actually two access counters. One is for the session and it
>is stores in the temp hashtable in the user object. The other is stored
>in the perm hashtable. I am not sure if it is actually updated or not.
>I have not looked at that part of the code. I guess I need to....
Yes, it is. That is the problem you're seeing with the password. If it
wasn't, then the user object wouldn't be touched at logout time.
Imagine the fun you have, if your database is read-only... Even if you
don't allow any changes to the fields, Turbine still wants to _write_
data in the tables...
Regards
Henning
>> -----Original Message-----
>> From: Rodney Schneider [mailto:[EMAIL PROTECTED]]
>> Sent: Sunday, January 05, 2003 8:07 PM
>> To: Turbine Developers List
>> Subject: Re: Discussion on TTWS30 - Session unbind causes
>> TURBINE_USER to be updated
>>
>>
>> On Sat, 4 Jan 2003 09:58, you wrote:
>>
>> > > i think the OBJECT_DATA column should be removed ... it's easy to
>> > > extend the user object ..
>> > >
>> > > martin
>> >
>> > Do we need to keep the access counter? I can't imagine why
>> this would
>> > even be of use to anyone.... If we do (and I suppose it can't hurt
>> > anything), it should get its own column.
>>
>> Hi Quinton,
>>
>> The problem the access counter was designed to solve is that when a
>> user hits refresh, an action could be performed twice.
>>
>> From John McNally:
>> -----------
>> To use this you keep a session counter and embed the current count in
>> the form. Then check the request count parameter with the session
>> counter to see if it is stale. There is code in the default session
>> validators that does this and a session counter is
>> incremented in $data.User.AccessCounterForSession.
>>
>> This can be used to internally redirect the user to an error
>> screen asking them to refrain from using the back/reload
>> button and does not require a redirect for every action that
>> is requested.
>> -----------
>>
>> Regards,
>>
>> -- Rodney
>>
>> > We should change the storage of the persistent pull tools to a new
>> > column or simply drop support for persistent pull tools. The only
>> > benefit that you would get out of a persistent pull tool is
>> that its
>> > state would be automatically saved between sessions. It
>> seems that a
>> > better implementaion would be to store the state
>> information from the
>> > pull tool into additional columns either in TURBINE_USER (by
>> > extending) or a separate table altogether.
>> >
>> > If those two issues are addressed, we can deprecate the methods to
>> > access it in 2.3. It could disappear altogether in a later version.
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:turbine-dev-> [EMAIL PROTECTED]>
>> For
>> additional commands,
>> e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
