Re: How many Django web pages does it take . . .

[Gabriel Hurley]

FWIF, the code that generates that message is here:

https://code.djangoproject.com/browser/django/trunk/docs/_ext/djangodocs.py#L84

Feel free to open a ticket if you like.

All the best,

- Gabriel

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/B_MkGZqmbDQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Logout user when they change their password.

[Gabriel Hurley]

Options 2 and 4 from that list both involve database-level changes, and 
thus aren't feasible (our lack of schema migration tools being the biggest 
problem).

Of those, I'd go for option 3 as well. We definitely don't want to store 
the full hash in the session for obvious security reasons, but a small 
portion of the hash is probably enough to do the checking, be secure and 
provide a high degree of confidence that collisions would be unlikely.

I'll leave it to PaulM or someone else better versed in hashing to comment 
on what the appropriate subset might be, or if that's just totally off base.

Lastly, I'll add that it'd really be pushing it to get this into 1.4 at 
this point. I, personally, would be willing to allow it on the basis of it 
being a security concern, but we'd need to have a really solid patch for it 
in the next week or so to have time to review it, test it, etc. Once we 
release the beta it's definitely not making it into 1.4.

All the best,

- Gabriel

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/2FvSlmAuVOIJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Logout user when they change their password.

[Jeremy Dunck]

On Sun, Jan 8, 2012 at 2:57 PM, Arnoud van Heuvelen
 wrote:
...
> 3) Save the password hash (or part of it) in the session and compare
> it against our data. If the hash is not the same, the user needs to be
> logged out. This wouldn't change the database, but the downside is
> that this causes overhead on every request.

+1.

1) We need a way to handle existing sessions when upgrading to the new
Django w/ this support.  I think the most natural support for the
validation is
auth.get_user:
https://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py?rev=16539#L94
to check the hash before returning.

2) I don't think the user should be logged out of their own session
when changing the password, and so we'd need to update the active
session on its way back to the user.

This is messier - we'd need to detect when the password changed
(User.set_password called?) and update the related request session, if
any.  That may be best accomplished through a signal fired when the
password is changed and handled in session.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: How many Django web pages does it take . . .

[Lachlan Musicman]

On Sat, Jan 7, 2012 at 16:10, Alec Taylor  wrote:
> What you are talking about is a form.
>
> Form: https://docs.djangoproject.com/en/dev/topics/forms/
> Autocomplete: https://code.djangoproject.com/wiki/AutoCompleteSolutions
> Unique fields: https://docs.djangoproject.com/en/1.3/ref/forms/validation/

This last page has what I consider an error/bug but I'm not sure how
to judge that, nor what to report against.

At the top of the page, under the heading, it states:

"Changed in Django 1.2: Please, see the release notes"

because it's the docs for django1.3.

As a native English speaker, I consider the comma incorrectly used - I
felt *compelled* ("Please, see...") to visit the documentation from
1.2 rather than merely advised ("Please see...").

The page in question in svn is here
https://code.djangoproject.com/browser/django/trunk/docs/ref/forms/validation.txt
which refers to the function versionchanged which happens to be search
for since it's on a lot of doc pages...

Anyway, FYI

cheers
L.



>
> On Sat, Jan 7, 2012 at 11:56 AM, Bill Beal  wrote:
>> Hi all,
>>
>> I've been doing Django and mostly backend Python for a few months, and
>> I don't really know the limits of what can be done without resorting
>> to JavaScript and Ajax. Here's what I need to do: the user wants to
>> pick an individual from one of a number of lists and have the detailed
>> information come up editable for the one picked. My top-level list is
>> [Lions, Tigers, Bears, All]. The user picks Tigers, and then I present
>> the second-level Tigers list: [Tony, Hobbes, Tigger, Rajah]. The user
>> picks Hobbes, and then I present the detailed information for Hobbes
>> in an editable form: name, address etc. How clunky does this have to
>> be, in terms of mouse clicks and pages downloaded? I've read in more
>> than one place that if you use JavaScript you'd better have a version
>> of your page that works OK without it.
>>
>> For extra credit, what high-powered tools would be needed to do
>> autocompletion, for example the user starts typing "Hobbes" into the
>> Name field and as soon as I find a unique match I present the details?
>> Or, show a list of possible matches when the partial field is not
>> unique?
>>
>> I've been reading books, but most of them just show me how to build a
>> particular kind of website using Django.
>>
>> Thanks for any help you can lend!
>>
>> Bill Beal
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To post to this group, send email to django-us...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-users?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Logout user when they change their password.

[Arnoud van Heuvelen]

Well, as far as I see it, we have a number of options. These are some
I could come up with, but maybe someone else has a better idea:

1) Save the user_id with the session. This is probably not convenient,
because it might conflict with other applications that use the session
package. Of course we could give the user_id a default of null, but
that seems a bit sloppy to me. Upside is that we could invalidate
sessions on password change.

2) Build a relation table that links the sessions to the users. (Or
use a CSV in the user object.) This could be done completely in the
auth package. Downside is that we have to create a new table. Upside
is again, that we could invalidate sessions on password change.

3) Save the password hash (or part of it) in the session and compare
it against our data. If the hash is not the same, the user needs to be
logged out. This wouldn't change the database, but the downside is
that this causes overhead on every request.

4) Save the last_password_change_date on the user object and save the
session_creation_time inside the session. Compare these and we know if
we should log the user out. This is just a different approach to 3.

My favourite is option 2 for now. It seems the most resource friendly,
even though we need to save more data. I don't know what Django's
policy on adding tables is though.

Besides that, I have to admit that I am fairly new to Django. I have
build some small sites with it, but have only skimmed through some
parts of the source code so far. I am not completely familiar with the
inner workings of the framework.

Arnoud

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django-nonrel patches

[Jonas H.]

On Sun 08 Jan 2012 05:39:02 PM CET, Emil Stenström wrote:



On Thursday, December 8, 2011 10:31:39 PM UTC+1, jo...@lophus.org wrote:


1.) I didn't write the code, I'm just submitting the patches in their
current state


Jonas: Do you have information on who wrote the code that you submitted? I
guess a good way forward would be to find those people, and have them
contribute a brief explanation of what problem their patch was trying to
solve. For a "solution" to be accepted, you need to know the problem.



Waldemar Kornewald wrote most of the code but he's pretty busy these 
days.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django-nonrel patches

[Emil Stenström]

On Thursday, December 8, 2011 10:31:39 PM UTC+1, jo...@lophus.org wrote:
>
> 1.) I didn't write the code, I'm just submitting the patches in their 
> current state
>
Jonas: Do you have information on who wrote the code that you submitted? I 
guess a good way forward would be to find those people, and have them 
contribute a brief explanation of what problem their patch was trying to 
solve. For a "solution" to be accepted, you need to know the problem.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/-tk4cJdRGMcJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.