Overriding returned contents of user objects - Django users

Message from discussion Overriding returned contents of user objects
Received-SPF: pass (google.com: domain of digitalspaghe...@googlemail.com designates 72.14.220.152 as permitted sender) client-ip=72.14.220.152;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=aGk913b6ZeYfrlGs8Ctx9CVK3u0TcX7q6Ko9VbJSkzpqg7Dni4/8H3S5HVo/FGdrcGTHY93E4/c0aPR30e6NiaQ12ermPZQt/WtHYEWbpuEuKns4Iqlxm7czaJMdBkXHnwzvO3mAmhhDhHTM9hrbq538xeBJBFwnWwmHs8BFrDw=
Message-ID: <eacff6d20804130456q4eefc258h4bc28f800e4c69a@mail.gmail.com>
Date: Sun, 13 Apr 2008 12:56:15 +0100
From: "Tane Piper" <digitalspaghe...@googlemail.com>
To: django-users@googlegroups.com
Subject: Re: Overriding returned contents of user objects
In-Reply-To: <1208084386.17060.19.ca...@counterweight.tredinnick.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <eacff6d20804130346j4a2b0e6ai9e9ea68de6523...@mail.gmail.com>
	 <1208084386.17060.19.ca...@counterweight.tredinnick.org>

Hi Malcolm,

values() seems to be the way to go for now.  I've extracted some of
the code back to a context variable, and anything within a view I'll
just have to try and make it as efficient as possible, while still
removing the user object from the context.

On Sun, Apr 13, 2008 at 11:59 AM, Malcolm Tredinnick
<malc...@pointy-stick.com> wrote:
>
>
>  On Sun, 2008-04-13 at 11:46 +0100, Tane Piper wrote:
>  [...]
>
> > What I want to
>  > know is there any way I could simplify the method and have it remove
>  > the password field any time a user object is being selected as part of
>  > a related query??
>
>  Not really, unless you use values(). For any model, if the Python object
>  is being constructed, it pulls back all the values it needs to populate
>  the attributes. The password hash is an attribute of the User model.
>
>
>  >  I'm sure there is a need for it when doing
>  > authorisation, but once a session has been confirmed, is it needed
>  > again?
>
>  Login isn't the only time when the password hash might be needed (for
>  example, it's displayed and editable in the admin screen) and it would
>  be quite hacky to introduce a special case for saying when that field
>  shouldn't be displayed. You're using the User object in public-readable
>  situations, which isn't really part of the design. So change your design
>  a bit so that you're not throwing around this information if you don't
>  want it displayed. Yes, anything can be serialised using json, but that
>  doesn't mean you should indiscriminately do so or that the framework
>  should accommodate that.
>
>  It might make sense in your situation to just pull back the values()
>  that you need for various objects and serialise that dictionary. Or you
>  could make another pass through the projects list and blank out the
>  attribute(s) you aren't interested in, such as _project_manager_cache.
>
>  Regards,
>  Malcolm
>
>  --
>  A clear conscience is usually the sign of a bad memory.
>  http://www.pointy-stick.com/blog/
>
>
>  >
>



-- 
Tane Piper
Blog - http://digitalspaghetti.me.uk
Skype: digitalspaghetti

This email is: [ ] blogable [ x ] ask first [ ] private