Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Fixes for sessions in r268

Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

current
Discussion topic

Hide all messages in topic

All messages in topic

Re: Fixes for sessions in r268

Reply

Author Jared Greenwald <greenwaldjared at gmail dot com>
Full name Jared Greenwald <greenwaldjared at gmail dot com>
Date 2006-08-30 19:56:46 PDT
Message Why is there even a need for logger.py anyway? Why not just
initialize the logging module in the global current/__init__.py? Then
there's no wrapper logger.log anymore, just call directly into
logging.log - that would make things a whole lot simpler.

(Again, I'm a bit of a python n00b, so I might be totally wrong.)

-Jared

On 8/30/06, Jack Neely <jjneely at gmail dot com> wrote:
> > Oh, one remark about the log code in user.py, either I'm getting
> > dumb, or you have placed the level in the wrong position.
> > (short pauze) no, i'm right. grep agrees with me.
> >
>
> But they both work ;-)
>
> You know I find it next to impossible to make things consistant.
> Hunter's logger.py code had stuff so you did log("message", level)
> while every other logging code on the face of the planet it seems does
> log(level, "message"). Which caused me no end of confusion while
> trying to remember how to log something.
>
> I'd like to make everything log(level, message). I *should* just say
> screw it and make everything log(message, level).
>
> > Another, slightly feature request: it might be handy to invalidate
>
> Indeed.
>
> Jack
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
> For additional commands, e-mail: dev-help at current dot tigris dot org
>
>

Re: Fixes for sessions in r268

Reply

Author theslack
Full name Jack Neely
Date 2006-08-30 18:54:10 PDT
Message > Oh, one remark about the log code in user.py, either I'm getting
> dumb, or you have placed the level in the wrong position.
> (short pauze) no, i'm right. grep agrees with me.
>

But they both work ;-)

You know I find it next to impossible to make things consistant.
Hunter's logger.py code had stuff so you did log("message", level)
while every other logging code on the face of the planet it seems does
log(level, "message"). Which caused me no end of confusion while
trying to remember how to log something.

I'd like to make everything log(level, message). I *should* just say
screw it and make everything log(message, level).

> Another, slightly feature request: it might be handy to invalidate

Indeed.

Jack

Re: Fixes for sessions in r268

Reply

Author Pauline Middelink <middelink at polyware dot nl>
Full name Pauline Middelink <middelink at polyware dot nl>
Date 2006-08-30 10:09:42 PDT
Message On Wed, 30 Aug 2006 around 10:09:15 -0400, Jack Neely wrote:
> On 8/30/06, Pauline Middelink <middelink at polyware dot nl> wrote:
> >Hi Jack,
> >
> >Wow, taken by suprise by the login changes. Slightly not
> >happy about the change in passwd crypting, since my existing
> >userbase now has a problem :(
> >
>
> I figured you'd say something. :-)

Nah :)

Oh, one remark about the log code in user.py, either I'm getting
dumb, or you have placed the level in the wrong position.
(short pauze) no, i'm right. grep agrees with me.

Another, slightly feature request: it might be handy to invalidate
a session for real. SessionUser.delete does not exists and
Session.invalidate sets the timeout, but save() overrides that time out :(

> >PS. Not sure about the table name, PROFILE_QUEUE or just QUEUE?
> > PROFILE_QUEUE indicates neatly it belongs to PROFILE, but
> > HARDWARE and INSTALLED should be changed too than.
> >
>
> *shrug* I'd go for QUEUE. I've used ACTIONQUEUE in stateengine, and
> there's code there that implements multiple queues (one per client) in
> SQL.

QUEUE it is.

    Met vriendelijke groet,
        Pauline Middelink
--
GPG Key fingerprint = 2D5B 87A7 DDA6 0378 5DEA BD3B 9A50 B416 E2D0 C3C2
For more details look at my website http://www.polyware.​nl/~middelink
Attachments

Re: Fixes for sessions in r268

Reply

Author theslack
Full name Jack Neely
Date 2006-08-30 07:09:15 PDT
Message On 8/30/06, Pauline Middelink <middelink at polyware dot nl> wrote:
> Hi Jack,
>
> Wow, taken by suprise by the login changes. Slightly not
> happy about the change in passwd crypting, since my existing
> userbase now has a problem :(
>

I figured you'd say something. :-)

> But no worries, I switched to XML_RPC to login and get a
> session id, with which I can't do anything with (yet)
>
> Attached some minor fixes to get the session stuff working.
>
> The changes in the tables already include my queueing stuff, but
> more essential is the change in SESSIONS.sid, since a sha digest
> is 40 chars wide, not 32. It took a while to see why my website
> could not login.

Oops..yeah the session code was originally written a few years back
with MD5 was all the rage. Now that MD5 hashes are easily brute
forced... :-)

>
> Could not get the self.__load to work in SessionUser.login, so
> I put the code right in. (all 2 lines)
>

You think I test things before I commit them! Methods with 2
underscores are considered private and python mangles the name. I
just made it unprivate.

> Oh, and very important, when the session is ok, lets save it...
>

Thanks.

> I noticed there is no deletion of expired sessions, nor checking
> if the session is expired? We might want to do that before the
> SESSIONS table explodes :)
>

The sessions are cleaned everytime save() is called.

> (when this is added the svn, I will sent the hardware/queue stuff,
> it works and might help other ppl to fill their hardware/installed
> tables)
>
> PS. Not sure about the table name, PROFILE_QUEUE or just QUEUE?
> PROFILE_QUEUE indicates neatly it belongs to PROFILE, but
> HARDWARE and INSTALLED should be changed too than.
>

*shrug* I'd go for QUEUE. I've used ACTIONQUEUE in stateengine, and
there's code there that implements multiple queues (one per client) in
SQL.

Jack

> Met vriendelijke groet,
> Pauline Middelink
> --
> GPG Key fingerprint = 2D5B 87A7 DDA6 0378 5DEA BD3B 9A50 B416 E2D0 C3C2
> For more details look at my website http://www.polyware.​nl/~middelink
>
>
>

Fixes for sessions in r268

Reply

Author Pauline Middelink <middelink at polyware dot nl>
Full name Pauline Middelink <middelink at polyware dot nl>
Date 2006-08-30 02:06:22 PDT
Message Hi Jack,

Wow, taken by suprise by the login changes. Slightly not
happy about the change in passwd crypting, since my existing
userbase now has a problem :(

But no worries, I switched to XML_RPC to login and get a
session id, with which I can't do anything with (yet)

Attached some minor fixes to get the session stuff working.

The changes in the tables already include my queueing stuff, but
more essential is the change in SESSIONS.sid, since a sha digest
is 40 chars wide, not 32. It took a while to see why my website
could not login.

Could not get the self.__load to work in SessionUser.login, so
I put the code right in. (all 2 lines)

Oh, and very important, when the session is ok, lets save it...

I noticed there is no deletion of expired sessions, nor checking
if the session is expired? We might want to do that before the
SESSIONS table explodes :)

(when this is added the svn, I will sent the hardware/queue stuff,
it works and might help other ppl to fill their hardware/installed
tables)

PS. Not sure about the table name, PROFILE_QUEUE or just QUEUE?
    PROFILE_QUEUE indicates neatly it belongs to PROFILE, but
    HARDWARE and INSTALLED should be changed too than.

    Met vriendelijke groet,
        Pauline Middelink
--
GPG Key fingerprint = 2D5B 87A7 DDA6 0378 5DEA BD3B 9A50 B416 E2D0 C3C2
For more details look at my website http://www.polyware.​nl/~middelink
Attachments
Messages per page: