Re: Client-side hashing of passwords before logging in
Oh what the heck, here's the patch: http://code.djangoproject.com/ticket/1534. I'd still like to hear some comments. :) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Client-side hashing of passwords before logging in
I wrote a working solution today for a challenge, I just wanted throw around some ideas before submitting a patch - even though it's probably a pointless gesture this close to a major merge. Here's a summary: First of all, none of this requires client side encryption but it's used if Javascript is on. A new password encryption method using psuedo-random salt based on username was required. This way the salt can be calculated client-side before login. Every login attempt, a unique key is stored in the user's session and sent with the login form as a hidden form item. JS works out the hash - sha1(pw + username_salt). Then rather than sending the hash stored in the database, the hash is hashed for extra security: - random_salt created - sha1(pw+onetime_login_salt+random_salt) - random_salt+'$'+hashed_hash stored back in the hidden form item - password set to '' So, thoughts? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: additional Admin option for fieldsets
On 3/21/06, Luke Plant <[EMAIL PROTECTED]> wrote: > What do people think about the attached patch? It adds an optional > 'description' item to the Admin fieldset options. This text is then > added verbatim at the top of a fieldset, underneath the 'h2' heading, > and above the form fields in that fieldset. > > I think this is a generally useful addition, and it doesn't disturb > anything existing as far as I can see. To make it more useful, I > haven't escaped the text in the template, so that you could use it to > put HTML in. If there are no objections, should I add it to > magic-removal or do submit a patch against trunk first? That patch looks fine to me -- go ahead and roll it into magic-removal. -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: additional Admin option for fieldsets
Too crufty to wrap it in a div class="description" so I can set it off somehow in the styles? On 3/23/06, Luke Plant <[EMAIL PROTECTED]> wrote: > > On Thursday 23 March 2006 17:31, wiz wrote: > > > http://files.lukeplant.fastmail.fm/public/admin_with_description.pn > > >g > > > > oops... 500: infernal server error > > Bizarre - I'm sure I checked the link, but now for some reason it > doesn't like that file. Thanks for letting me know. Try this: > > http://files.lukeplant.fastmail.fm/public/admin_with_description.jpg > > Luke > > -- > I went to the Missing Persons Bureau. No one was there. > > Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: additional Admin option for fieldsets
On Thursday 23 March 2006 17:31, wiz wrote: > > http://files.lukeplant.fastmail.fm/public/admin_with_description.pn > >g > > oops... 500: infernal server error Bizarre - I'm sure I checked the link, but now for some reason it doesn't like that file. Thanks for letting me know. Try this: http://files.lukeplant.fastmail.fm/public/admin_with_description.jpg Luke -- I went to the Missing Persons Bureau. No one was there. Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: MySQL 4.1.x charset support
http://code.djangoproject.com/ticket/952 On 22-mrt-2006, at 6:54, ak wrote: > > Thanks, posted: http://code.djangoproject.com/ticket/1528 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: MySQL 4.1.x charset support
I file a much broader patch for thus about a few months ago. Check out the tickets. On 22-mrt-2006, at 6:54, ak wrote: > > Thanks, posted: http://code.djangoproject.com/ticket/1528 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: additional Admin option for fieldsets
> http://files.lukeplant.fastmail.fm/public/admin_with_description.png oops... 500: infernal server error --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: also: multiple databases
>However, I don't like it if it's going to be introduced as a scaling >solution; I'd rather have the various tiers of infrastructure (load >balancing at the front, application in the middle, database in the >back) remain as loosely coupled as possible. Absolutly, scaling is the last reason to introduce it and is not in anyway why it a such feature gap. As mentioned, there are dozens of scenarios in modern cororations where you have access multiple databases. I could a several tens. Take the company I work at now. We have an ERP system in oracle. The ERP system itself splits its data in 3 seperate instances (SYSTEM/CONTROL/DATA). We then have business intellgence system. We have EDI systems. We have a zillion dodgy access databases. We have home grown maintaince systems. A lot of the requirements for building websites is to show data from multiple of these systems. While this can be done with pure SQL now, it would be nicer if it could done through the ORM because of all the benefits that brings in Django. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
