Re: Can not read request.body from a POST request

[Gergely Polonkai]

Vijay: They are not the same thing. request.POST, .GET and .FILES are
exactly that, POST and GET data and the optional uploaded files. However,
in e.g. a RESTful environment it is possible to have something else in the
request body.

Mihai, what else do you do with the request before trying to read its body?

Best,
Gergely
They aree

[image: --]

Gergely Polonkai
[image: https://]about.me/gergely.polonkai





Gergely Polonkai
[image: https://]about.me/gergely.polonkai


2016-04-20 22:44 GMT+02:00 Vijay Khemlani :

> Why would you want to access request.body directly? You should use
> request.POST, request.GET, request.FILES.
>
> On Wed, Apr 20, 2016 at 5:27 PM, Mihai Corciu  wrote:
>
>> Is there a method to access request.body from a POST request in Django,
>> without disabling 'django.middleware.csrf.CsrfViewMiddleware' ?
>>
>> CsrfViewMiddleware is causing:
>>
>> Exception Type: RawPostDataException
>> Exception Value: You cannot access body after reading from request's
>> data stream
>>
>> which means request.body is impossible to acces without disabling
>> CsrfViewMiddleware.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/9e35deeb-5586-46ec-8d54-648acdafbb8d%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CALn3ei0%3DUx0euOS7XZ9Wb6cw9yMvKeqGwQO0cu37Y60broG%2Bvw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACczBULiJRUvHWiY0fXjs0eMbdsEW5r7-vWbzWZWGwaxMt5mjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any way to tolerate Unicode w/o changing '' to u''?...

[Fred Stluka]

  
  
Tim,

Excellent response, thanks!  The link to the doc is just what I 
needed.

One more question.  I'm still getting UnicodeEncodeError on
some calls to str() because I should now be calling unicode()
instead.  Any easy way to map all of my str() calls to unicode()
call?

Thanks!
--Fred
  
  Fred Stluka -- mailto:f...@bristle.com --
  http://bristle.com/~fred/
  
  Bristle Software, Inc -- http://bristle.com -- Glad to be of
  service!
  
  Open Source: Without walls and fences, we need no Windows or
  Gates.
  

On 4/14/16 10:05 PM, Tim Graham wrote:


  You want `from __future__ import unicode_literals`:
https://docs.djangoproject.com/en/dev/ref/unicode/#general-string-handling

On Thursday, April 14, 2016 at 6:27:07 PM UTC-4, Fred Stluka
wrote:

   Django users,

In my Django app, I want to allow users to enter Unicode 
strings.  But if they do, I get UnicodeEncodeError when I
call
format() to embed their string into other strings.  Is there
an 
easy way to tolerate the Unicode?

Details:

After prompting the user for name, I may have a line of code
like:

    log('Name entered was: {0}'.format(name))

With Python 2.7.3 and Django 1.4.3, this raises exception 
UnicodeEncodeError if the user entered a string containing 
Unicode chars, because it tries to embed Unicode chars into
my ASCII string template.  So, I have to I change it to:

    log(u'Name entered was:
{0}'.format(name))

I have many thousands of such lines in my 200,000+ lines of

Python and Django code.

Is there a master switch somewhere that would cause a Python
2.x string literal to default to Unicode instead of ASCII,
as it 
does in Python 3?  

Or do I have to explicitly change '' to u'' in all such
places?

I looked into adding a line like this to the top of the
file, but 
no luck because it seems to only affect the encoding of
Unicode 
string literals (u''), not regular string literals (''):

    # -*- coding: utf-8 -*-

Any suggestions?  Much appreciated.  Thanks!

  --Fred
   Fred Stluka -- mailt...@bristle.com
  -- http://bristle.com/~fred/ 
  Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
  
  Open Source: Without walls and fences, we need no Windows
  or Gates.
   
  

  
  -- 
  You received this message because you are subscribed to the Google
  Groups "Django users" group.
  To unsubscribe from this group and stop receiving emails from it,
  send an email to django-users+unsubscr...@googlegroups.com.
  To post to this group, send email to django-users@googlegroups.com.
  Visit this group at https://groups.google.com/group/django-users.
  To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3da21b79-4bfd-4f05-bbc4-579505365376%40googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.


  




-- 
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/57184BE1.1030505%40bristle.com.
For more options, visit https://groups.google.com/d/optout.

Check for A Message When Testing with Selenium

[Austin West]

I'm attempting to write a Selenium test for my django app that performs a 
custom action in the admin page. If the action is successful, the i use the 
message_user function to send a success message back to the user, e.g. 
"Action successful!". It appears that this message doesn't appear in the 
raw html when the new page is loaded, and as such I can't perform an assert 
that the message is appearing and the action was successful.

I know I could do this using the context/etc. using the built in django 
client, but is it possible to do it using an external web driver like 
Selenium?

Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a1d36959-b269-4a78-9051-684d7b551415%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

admin popup + button help

[Giuseppe]

I am trying to get a pop up that will let me create a new object to 
associate to a many to many relationship on a form/model. In the same way 
that it works in django-admin.

I have been followed the instructions from here 
, and its not 
working for me. 

whenever I click the plus button it opens the related object creating form 
in the same tab instead of a new pop up. When I try to submit the new 
object I get a cert error and I included the cert tag in the template.

Let me know what code you want to see and I can post it. Also if you know 
of a different resource, or library or way of doing this that would be 
amazing.

By the way I think the link provided was for django 1.1 and im using django 
1.9.1

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/142b7857-eada-443e-97ae-65687c7e87ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

implement django-admin + button popup

[Giuseppe Smith]

I have been trying to get a + button beside my many to many list that will 
give me a popup to a form to create a new related object to associate.

I have followed the instructions at this link 
http://www.hoboes.com/Mimsy/hacks/replicating-djangos-admin/ but it will 
not work. whenever I click the + button my browser switches to a new page 
instead of opening a pop up. When i try to create the object and save it, i 
get a cert error(i made sure the cert tag was in my forms. I am extremely 
new to python, django, javascript and working with code on the web.

I think the link was using django 1.1 and I am using django 1.9.1 python2

let me know what code you want to see if that will help, or if this just 
wont work with django 1.9.1 or if you know of a working example I could run 
and pick apart. Or a library that I could use to make creating my 
application easier.

Anything would be amazing.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/022379cc-e098-4925-ac67-2815adf2974b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can not read request.body from a POST request

[Vijay Khemlani]

Why would you want to access request.body directly? You should use
request.POST, request.GET, request.FILES.

On Wed, Apr 20, 2016 at 5:27 PM, Mihai Corciu  wrote:

> Is there a method to access request.body from a POST request in Django,
> without disabling 'django.middleware.csrf.CsrfViewMiddleware' ?
>
> CsrfViewMiddleware is causing:
>
> Exception Type: RawPostDataException
> Exception Value: You cannot access body after reading from request's
> data stream
>
> which means request.body is impossible to acces without disabling
> CsrfViewMiddleware.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/9e35deeb-5586-46ec-8d54-648acdafbb8d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALn3ei0%3DUx0euOS7XZ9Wb6cw9yMvKeqGwQO0cu37Y60broG%2Bvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Can not read request.body from a POST request

[Mihai Corciu]

Is there a method to access request.body from a POST request in Django, 
without disabling 'django.middleware.csrf.CsrfViewMiddleware' ?

CsrfViewMiddleware is causing:

Exception Type: RawPostDataException
Exception Value: You cannot access body after reading from request's 
data stream

which means request.body is impossible to acces without disabling 
CsrfViewMiddleware.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9e35deeb-5586-46ec-8d54-648acdafbb8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Spatialite for GeoDjango can't be loaded on Ubuntu Wily Werewolf

[Giorgos Ouzounoudis]

I had the exactly same error on Ubuntu 16.04.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3ca907fe-d84c-4de1-99db-2cbb7f1bc59b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why when I call a method within a middleware does not return an HttpResponse?

[술욱]

because from the exception you return to process_request() and if you
don't return anything None in implied.



2016-04-20 15:10 GMT-03:00 Neto :
> The problem is that when happens the exception, the redirect does not work,
> only if I put return before is_authenticated_user(), like this:
>
>
> class Check(object):
>
> """
> Check
> """
>
> @staticmethod
> def process_request(request):
>
> def is_authenticated_user():
>
> try:
> request.session['user']
> except KeyError:
> return redirect(reverse('mysite:login'))
>
>
> return is_authenticated_user()  # why I need put "return" here?
>
>
>
>
>
>
> Em quarta-feira, 20 de abril de 2016 14:58:03 UTC-3, 술욱 زولوكْ escreveu:
>>
>> What's the value of request.session['user'] when user is not logged in?
>>
>> My guess is it's an instance of AnonymousUser.
>>
>> 2016-04-20 11:43 GMT-03:00 Neto :
>> > Hi,
>> >
>> > I have a middleware that checks whether the user is logged in.
>> >
>> > class Check(object):
>> >
>> > """
>> > Check
>> > """
>> >
>> > @staticmethod
>> > def process_request(request):
>> >
>> > def is_authenticated_user():
>> >
>> > try:
>> > request.session['user']
>> > except KeyError:
>> > return redirect(reverse('mysite:login'))
>> >
>> >
>> > is_authenticated_user()
>> >
>> >
>> >
>> > Why it does not works? How to solve?
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Django users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to django-users...@googlegroups.com.
>> > To post to this group, send email to django...@googlegroups.com.
>> > Visit this group at https://groups.google.com/group/django-users.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/django-users/7a9effe3-9fd3-42ff-bfd3-5ab7ea03030e%40googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/1c984bab-f08f-4355-8aa2-c6e28b5ee579%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CADut3oDsJqQM25didRRMJ4gnS%3Db5h6isj7urUORBseZ44eGjew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: No Downtime Code Releases

[Alex Heyden]

I wouldn't recommend tying your repository structure to your deployment
needs. Put that in the deployment script instead. You can see if any
migrations are pending with manage.py migrate --list

On Wed, Apr 20, 2016 at 1:59 PM,  wrote:

> My thought process for separating the models into a separate repo is
> something like this:
>
> I am predominately putting up our (heroku) maintenace page when migrations
> are run
> If the models are in separte repo, I only need to run migrations when that
> repo is deployed.  If migrations are not deployed in my non-model repos, I
> would skip putting up the maintenance page.
>
> Most of our db changes are to accommodate back-end data warehousing.  The
> other/additional way I was thinking about spliting our app up was
> separating the backend processes from our front end API's that primarily
> deal with security and authorization.  The security and authorization
> models do not change very often, so an app that only deals with that part
> would not need to restart very often.  That said, there are a couple models
> that we need to run that that are shared with our back-end processes.
> Having those models split out would potentially let us pip install them
> into a separate service.
>
> However it sounds like you guys are saying there are other
> concerns--namely flushing the pyc files.  I'm not exactly sure this is
> relevant to me since we are using heroku, and an entire new server/slug is
> deployed when we do a code release. It's not clear to me if that slug
> deployment would drop connections or cause other kinds of problems.
>
>
>
>
> On Tuesday, April 19, 2016 at 9:13:30 AM UTC-7, Avraham Serour wrote:
>>
>> I don't think you would gain anything by separating your models to a
>> different repository, what are you trying to gain here?
>>
>> if you put a maintenance page when doing migrations it won't matter if
>> the models are from a different package or not.
>>
>> you could still run migrations on a live system, you just should take
>> into account that there could still be parts of the system using something
>> is not there yet/anymore
>>
>> so you should break migrations into 2 whenever you are adding or removing
>> something.
>>
>> when adding a model or field you should first run the migrations and only
>> after that deploy the new code using the new model/field
>>
>> when removing something you should first stop using it and then migrate.
>>
>> you could plan your deployment/releases and know in advance if you are
>> either adding or removing something and never add and remove in the same
>> release
>> meaning commit and deploy the model and only after that commit the code
>> using the new model
>>
>> or you can checkout the code on the side and runs migrations using this
>> separate env, this way you could add a new model and use it in the same
>> commit.
>>
>> for removing you can just do it backwards.
>>
>>
>> Avraham
>>
>>
>>
>> On Tue, Apr 19, 2016 at 3:38 AM,  wrote:
>>
>>> Hey,
>>>
>>> I have two issues I'm looking at solving at work, and I'm looking for a
>>> couple suggestions as to how other people have solved this.  The two things
>>> are:
>>>
>>> * scale out their django installation to allow for smaller releases (I'm
>>> thinking microservices, but it could also be internal django apps or who
>>> knows what else)
>>> * minimizing the impact of migrations during releases (aka we want to be
>>> able to release in the middle of the afternoon
>>>
>>> Currently we put up a maintenance page whenever we are doing database
>>> operations (aka migrations).  This seems like a recommended best practice.
>>>
>>> One way I was thinking about addressing this issue was to break all of
>>> our models out into a separate repo.  That way we'd only need to deploy
>>> migrations when the models themselves have deployed.  For code that needs
>>> the models, we could pip install the repo as an app and away we go.
>>> Likewise it seems like I could break up different parts of our app via a
>>> similar strategy.
>>>
>>> Does this seem viable?  How have other people solved this kind of
>>> problem?
>>>
>>> Thanks,
>>>
>>> -Ben
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-users/e5fd0359-9e8b-4cce-b3e1-4880951a2a8e%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are 

Re: No Downtime Code Releases

[bliyanage]

My thought process for separating the models into a separate repo is 
something like this:

I am predominately putting up our (heroku) maintenace page when migrations 
are run
If the models are in separte repo, I only need to run migrations when that 
repo is deployed.  If migrations are not deployed in my non-model repos, I 
would skip putting up the maintenance page.  

Most of our db changes are to accommodate back-end data warehousing.  The 
other/additional way I was thinking about spliting our app up was 
separating the backend processes from our front end API's that primarily 
deal with security and authorization.  The security and authorization 
models do not change very often, so an app that only deals with that part 
would not need to restart very often.  That said, there are a couple models 
that we need to run that that are shared with our back-end processes.  
Having those models split out would potentially let us pip install them 
into a separate service.

However it sounds like you guys are saying there are other concerns--namely 
flushing the pyc files.  I'm not exactly sure this is relevant to me since 
we are using heroku, and an entire new server/slug is deployed when we do a 
code release. It's not clear to me if that slug deployment would drop 
connections or cause other kinds of problems.




On Tuesday, April 19, 2016 at 9:13:30 AM UTC-7, Avraham Serour wrote:
>
> I don't think you would gain anything by separating your models to a 
> different repository, what are you trying to gain here?
>
> if you put a maintenance page when doing migrations it won't matter if the 
> models are from a different package or not.
>
> you could still run migrations on a live system, you just should take into 
> account that there could still be parts of the system using something is 
> not there yet/anymore
>
> so you should break migrations into 2 whenever you are adding or removing 
> something.
>
> when adding a model or field you should first run the migrations and only 
> after that deploy the new code using the new model/field
>
> when removing something you should first stop using it and then migrate.
>
> you could plan your deployment/releases and know in advance if you are 
> either adding or removing something and never add and remove in the same 
> release
> meaning commit and deploy the model and only after that commit the code 
> using the new model
>
> or you can checkout the code on the side and runs migrations using this 
> separate env, this way you could add a new model and use it in the same 
> commit.
>
> for removing you can just do it backwards.
>
>
> Avraham
>
>
>
> On Tue, Apr 19, 2016 at 3:38 AM,  
> wrote:
>
>> Hey,
>>
>> I have two issues I'm looking at solving at work, and I'm looking for a 
>> couple suggestions as to how other people have solved this.  The two things 
>> are:
>>
>> * scale out their django installation to allow for smaller releases (I'm 
>> thinking microservices, but it could also be internal django apps or who 
>> knows what else)
>> * minimizing the impact of migrations during releases (aka we want to be 
>> able to release in the middle of the afternoon
>>
>> Currently we put up a maintenance page whenever we are doing database 
>> operations (aka migrations).  This seems like a recommended best practice.
>>
>> One way I was thinking about addressing this issue was to break all of 
>> our models out into a separate repo.  That way we'd only need to deploy 
>> migrations when the models themselves have deployed.  For code that needs 
>> the models, we could pip install the repo as an app and away we go.  
>> Likewise it seems like I could break up different parts of our app via a 
>> similar strategy.
>>
>> Does this seem viable?  How have other people solved this kind of problem?
>>
>> Thanks,
>>
>> -Ben
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/e5fd0359-9e8b-4cce-b3e1-4880951a2a8e%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the 

Re: Why when I call a method within a middleware does not return an HttpResponse?

[Neto]

The problem is that when happens the exception, the redirect does not work, 
only if I put return before is_authenticated_user(), like this:


class Check(object):

"""
Check
"""

@staticmethod
def process_request(request):

def is_authenticated_user():

try:
request.session['user']
except KeyError:
return redirect(reverse('mysite:login'))


return is_authenticated_user()  # why I need put "return" here?





Em quarta-feira, 20 de abril de 2016 14:58:03 UTC-3, 술욱 زولوكْ escreveu:
>
> What's the value of request.session['user'] when user is not logged in? 
>
> My guess is it's an instance of AnonymousUser. 
>
> 2016-04-20 11:43 GMT-03:00 Neto : 
> > Hi, 
> > 
> > I have a middleware that checks whether the user is logged in. 
> > 
> > class Check(object): 
> > 
> > """ 
> > Check 
> > """ 
> > 
> > @staticmethod 
> > def process_request(request): 
> > 
> > def is_authenticated_user(): 
> > 
> > try: 
> > request.session['user'] 
> > except KeyError: 
> > return redirect(reverse('mysite:login')) 
> > 
> > 
> > is_authenticated_user() 
> > 
> > 
> > 
> > Why it does not works? How to solve? 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Django users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to django-users...@googlegroups.com . 
> > To post to this group, send email to django...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/django-users. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-users/7a9effe3-9fd3-42ff-bfd3-5ab7ea03030e%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1c984bab-f08f-4355-8aa2-c6e28b5ee579%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Django Password Normalization

[Michal Petrucha]

On Wed, Apr 20, 2016 at 07:42:26AM -0700, Arun S wrote:
> For ex, adding the Django Code Snippet for handling User names in the Login 
> Page :
> 
> default_username = (unicodedata.normalize('NFKD', default_username)
> So Django does follow Normalizing of Usernames usign NFKD Algorithm.
> Then applies Hashing Algorithms on this.

Not really – the line of code you quoted above is only used to
generate the default username in the createsuperuser management
command, based on the current system account. The purpose there is to
turn a string that potentially contains diacritics or other non-ASCII
characters into a stripped-down ASCII-only version.

The only other uses of Unicode normalization I found in Django are a
similar case when slugifying strings, code that truncates strings to a
certain length (where normalization is used to ensure that combining
marks do not count as separate characters), and the handling of the
decimal separator in decimal numbers.

So no, Django does not normalize usernames. Django does not normalize
anything, other than when stripping out all non-ASCII characters and
diacritic marks from strings.

> *But the same is never followed for Passwords.*
> Is this done on Purpose that the HASHING algorithm takes care of whatever 
> required and Normalization isnt quite required for such purpose.
> 
> Even the Django Documentation does'nt talk about Unicode Normalizing on 
> Passwords but you can still find it for Other forms of Text inputs.

For the record, I personally think Unicode normalization is a
reasonable feature request for Django, if nothing else, then at least
because of the example with Unicode in passwords. However, I'm not
certain at the moment which layers of Django deal with bytestrings,
and which handle Unicode objects, and I have no idea where such
handling would belong.

I think it might be a good idea to bring this up on django-developers@
to see if other people think it is worth including in Django core or
not. I would recommend describing specific cases where normalization
is necessary. If this is just a hypothetical request, “just in case”
some client sends denormalized requests (or with unusual
normalization), but there are no actual existing client
implementations that would to that, it's probably not worth the
effort.

Regards,

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160420180200.GG1129%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Why when I call a method within a middleware does not return an HttpResponse?

[술욱]

What's the value of request.session['user'] when user is not logged in?

My guess is it's an instance of AnonymousUser.

2016-04-20 11:43 GMT-03:00 Neto :
> Hi,
>
> I have a middleware that checks whether the user is logged in.
>
> class Check(object):
>
> """
> Check
> """
>
> @staticmethod
> def process_request(request):
>
> def is_authenticated_user():
>
> try:
> request.session['user']
> except KeyError:
> return redirect(reverse('mysite:login'))
>
>
> is_authenticated_user()
>
>
>
> Why it does not works? How to solve?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/7a9effe3-9fd3-42ff-bfd3-5ab7ea03030e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CADut3oA0ibHqEU6HbPC8zdB7UYRJju%2BZv%3D8Y82U_30NFRQmHoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Why when I call a method within a middleware does not return an HttpResponse?

[Neto]

Hi,

I have a middleware that checks whether the user is logged in.

class Check(object):

"""
Check
"""

@staticmethod
def process_request(request):

def is_authenticated_user():

try:
request.session['user']
except KeyError:
return redirect(reverse('mysite:login'))


is_authenticated_user()


Why it does not works? How to solve?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7a9effe3-9fd3-42ff-bfd3-5ab7ea03030e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Django Password Normalization

[Arun S]

For ex, adding the Django Code Snippet for handling User names in the Login 
Page :

default_username = (unicodedata.normalize('NFKD', default_username)
So Django does follow Normalizing of Usernames usign NFKD Algorithm.
Then applies Hashing Algorithms on this.

*But the same is never followed for Passwords.*
Is this done on Purpose that the HASHING algorithm takes care of whatever 
required and Normalization isnt quite required for such purpose.

Even the Django Documentation does'nt talk about Unicode Normalizing on 
Passwords but you can still find it for Other forms of Text inputs.


On Wednesday, April 20, 2016 at 7:52:27 PM UTC+5:30, Rick Leir wrote:
>
> There is also a new issue in Trac on this topic. I added two links to 
> Stackoverflow discussions there. 
>
> The issue: supposing a password is mañana. Depending on what client you 
> use, input methods can give you two different UTF8 characters for ñ. As a 
> first step, let's add test case, and check whether it fails. 
>
> My guess (tho I am new to this) is that this is a Django issue not Python. 
> Cheers-- Rick

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/90031b13-bac4-4601-a684-fd10dcab27a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Django Password Normalization

[Rick Leir]

There is also a new issue in Trac on this topic. I added two links to 
Stackoverflow discussions there. 

The issue: supposing a password is mañana. Depending on what client you use, 
input methods can give you two different UTF8 characters for ñ. As a first 
step, let's add test case, and check whether it fails. 

My guess (tho I am new to this) is that this is a Django issue not Python.
Cheers-- Rick

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/24b2f0c8-7882-4db9-8584-d35cf1b21819%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Django Password Normalization

[Michal Petrucha]

> On Wed, Apr 20, 2016 at 4:16 PM, Arun S  wrote:
> 
> > let me try to clear my question.
> >
> > please correct me if am wrong.
> > basically all I want to know is that there already exists a number of
> > Unicode normalization forms.
> > Reference
> >
> > Unicode normalization forms: http://unicode.org/reports/tr15/#Norm_Forms
> >
> > so as I said as a part of a company norms, the project needs to follow
> > certain csdl standards and according to that it states that all passwords
> > shall be normalised according to the ref mentioned and then convert then to
> > a utf8 which then follows thru the hashing process.
> >
> > so since the major part of the project uses djangos frameworks, I believe
> > that the user authentication methods used already applies the hashing
> > algorithms.
> >
> > but what I could not figure out is that
> > 1: does django apply any such normalization process for the user passwords.
> > 2: how is it different between a normalised password and then hashed with
> > djangos hashing algorithm s and a non normalised password just saved after
> > hashing.

Ah, unicode normalization, now your question makes a lot more sense.

A quick grep through the sources of Django didn't reveal any explicit
normalization of plaintext passwords. However, you can implement your
own hashing function that will use the unicodedata module from the
standard library to perform unicode normalization, and then call one
of the built-in password hashers to do the actual work.

On Wed, Apr 20, 2016 at 04:20:35PM +0300, Avraham Serour wrote:
> in summary: "Unicode Normalization Forms are formally defined
> normalizations of Unicode strings which make it possible to determine
> whether any two Unicode strings are equivalent to each other"
> 
> as I see this would be highly unsecure for passwords, this is something
> like converting special characters to latin characters, or forcing lower
> case only

I don't agree – when a user enters the letter Å, you almost never care
wheher it is represented as U+00C5, or U+0041 U+030A – they represent
the same character, just in two different ways. Unicode normalization
is a tool to recognize those two representations as the same thing.

As a user, if I use a password containing non-ASCII characters, I
definitely wouldn't expect that with the same correct password, I
would be able to authenticate using a browser that sends the data in a
composed normal form, but not with another browser that sends the same
string in a decomposed normal form.

Regards,

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160420134232.GF1129%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Issue with Django Password Normalization

[Avraham Serour]

actually upon further reading the document it seems it specifies on how to
handle unicode, it tells how unicode strings whould be stored.

if that's the case then it is not a django problem but a python problem.

if you are on python 3 then you are using unicode strings, python handles
that for you.

if you are running on python 2 I believe django uses explicit unicode
strings, you should double check that.



On Wed, Apr 20, 2016 at 4:32 PM, Arun S  wrote:

> Does that mean that Unicode Normalisation is a very weak and unsecure way
> for passwords?
>
> In this case, what is the actual Usage of Unicode Normalization ?
> Why exactly do we need something like a Unicode Normalization ?
>
> Offcourse django provides various ways to strengthen and vallidate the
> passwords.
> that can be used.
>
> But also Observed is that the Django Code does the Unicode Normalization
> for User names and Email Ids using NKFD Normalisation Algorithm.
>
>
> On Wednesday, April 20, 2016 at 6:51:18 PM UTC+5:30, Avraham Serour wrote:
>>
>> in summary: "Unicode Normalization Forms are formally defined
>> normalizations of Unicode strings which make it possible to determine
>> whether any two Unicode strings are equivalent to each other"
>>
>> as I see this would be highly unsecure for passwords, this is something
>> like converting special characters to latin characters, or forcing lower
>> case only
>>
>> On Wed, Apr 20, 2016 at 4:16 PM, Arun S  wrote:
>>
>>> let me try to clear my question.
>>>
>>> please correct me if am wrong.
>>> basically all I want to know is that there already exists a number of
>>> Unicode normalization forms.
>>> Reference
>>>
>>> Unicode normalization forms: http://unicode.org/reports/tr15/#Norm_Forms
>>>
>>> so as I said as a part of a company norms, the project needs to follow
>>> certain csdl standards and according to that it states that all passwords
>>> shall be normalised according to the ref mentioned and then convert then to
>>> a utf8 which then follows thru the hashing process.
>>>
>>> so since the major part of the project uses djangos frameworks, I
>>> believe that the user authentication methods used already applies the
>>> hashing algorithms.
>>>
>>> but what I could not figure out is that
>>> 1: does django apply any such normalization process for the user
>>> passwords.
>>> 2: how is it different between a normalised password and then hashed
>>> with djangos hashing algorithm s and a non normalised password just saved
>>> after hashing.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-users/69f70909-215e-4daa-a770-a10b3c2de63a%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/9b11feda-914f-4516-9841-2dad8084654b%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tJXTupQ0L3niFjJNu-ObocuEQAGcJPRd0-5JcZRf_gJ8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Django Password Normalization

[Arun S]

Does that mean that Unicode Normalisation is a very weak and unsecure way 
for passwords?

In this case, what is the actual Usage of Unicode Normalization ?
Why exactly do we need something like a Unicode Normalization ?

Offcourse django provides various ways to strengthen and vallidate the 
passwords.
that can be used.

But also Observed is that the Django Code does the Unicode Normalization 
for User names and Email Ids using NKFD Normalisation Algorithm.


On Wednesday, April 20, 2016 at 6:51:18 PM UTC+5:30, Avraham Serour wrote:
>
> in summary: "Unicode Normalization Forms are formally defined 
> normalizations of Unicode strings which make it possible to determine 
> whether any two Unicode strings are equivalent to each other"
>
> as I see this would be highly unsecure for passwords, this is something 
> like converting special characters to latin characters, or forcing lower 
> case only
>
> On Wed, Apr 20, 2016 at 4:16 PM, Arun S  
> wrote:
>
>> let me try to clear my question.
>>
>> please correct me if am wrong.
>> basically all I want to know is that there already exists a number of 
>> Unicode normalization forms.
>> Reference
>>
>> Unicode normalization forms: http://unicode.org/reports/tr15/#Norm_Forms
>>
>> so as I said as a part of a company norms, the project needs to follow 
>> certain csdl standards and according to that it states that all passwords 
>> shall be normalised according to the ref mentioned and then convert then to 
>> a utf8 which then follows thru the hashing process.
>>
>> so since the major part of the project uses djangos frameworks, I believe 
>> that the user authentication methods used already applies the hashing 
>> algorithms.
>>
>> but what I could not figure out is that
>> 1: does django apply any such normalization process for the user 
>> passwords.
>> 2: how is it different between a normalised password and then hashed with 
>> djangos hashing algorithm s and a non normalised password just saved after 
>> hashing.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/69f70909-215e-4daa-a770-a10b3c2de63a%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9b11feda-914f-4516-9841-2dad8084654b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Matt Schinckel]

On Wednesday, December 2, 2015 at 6:31:31 PM UTC+10:30, john@gmail.com 
wrote:
>
> +1 for disabling migrations completely - for several reasons.
>
> 1. Right now, I'm trying to run tests against a production database with 
> runserver, in *read-only* mode - but it fails because it can't create the 
> django_migrations table.  (I'm in the process of upgrading from Django 1.4 
> to 1.8, so the table doesn't yet exist in production.) 
>

2. Our mysql database is 3TB, with some tables of up to 500GB - and I 
> assume that migrating them with Django - without taking the system down for 
> days - is not possible.  Instead, we use Percona's pt-online-schema-change, 
> which does an excellent job of migrating big tables, whilst keeping them 
> fully usable with no downtime.
>

When upgrading from 1.4 to 1.7+, you shouldn't be changing anything in the 
database. Sure, you'll want to build up the migrations, but you won't 
actually want to apply them, only fake them. If you are attempting to 
change your db structure at the same point in time as upgrading from 
pre-1.7 to post-1.7, you are making it much harder than it needs to be. 
(Yes, I'm going through the same process, with a database of similar size. 
Mine is postgres though).
 

> Point 2 is covered, I think, by setting all models to unmanged, as we do - 
> but that doesn't help me with the upgrade process in point 1 - unless I'm 
> missing something?
>
> (Yes, perhaps I could jump through hoops and make a second, writable 
> database, with appropriate routers etc, to enable creation of the 
> django_migrations table, to get past point 1 - but if django migrations are 
> useless to us anyway... disabling migrations entirely seems far more 
> logical.)
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2b648b12-78ba-4323-9404-512aef5d0e77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Django Password Normalization

[Avraham Serour]

in summary: "Unicode Normalization Forms are formally defined
normalizations of Unicode strings which make it possible to determine
whether any two Unicode strings are equivalent to each other"

as I see this would be highly unsecure for passwords, this is something
like converting special characters to latin characters, or forcing lower
case only

On Wed, Apr 20, 2016 at 4:16 PM, Arun S  wrote:

> let me try to clear my question.
>
> please correct me if am wrong.
> basically all I want to know is that there already exists a number of
> Unicode normalization forms.
> Reference
>
> Unicode normalization forms: http://unicode.org/reports/tr15/#Norm_Forms
>
> so as I said as a part of a company norms, the project needs to follow
> certain csdl standards and according to that it states that all passwords
> shall be normalised according to the ref mentioned and then convert then to
> a utf8 which then follows thru the hashing process.
>
> so since the major part of the project uses djangos frameworks, I believe
> that the user authentication methods used already applies the hashing
> algorithms.
>
> but what I could not figure out is that
> 1: does django apply any such normalization process for the user passwords.
> 2: how is it different between a normalised password and then hashed with
> djangos hashing algorithm s and a non normalised password just saved after
> hashing.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/69f70909-215e-4daa-a770-a10b3c2de63a%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tKOJGwT0-wB0kt468KDJcv-CK9norO4LCxDUMooWFknDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Django Password Normalization

[Michal Petrucha]

On Wed, Apr 20, 2016 at 03:02:06PM +0200, Erik Cederstrand wrote:
> Do you want passwords to be case-insensitive? If so, you can
> subclass AuthenticationForm and override clean_password(), and
> set_password() on your user model, and put any transformations of
> the raw password there.

A more robust way to implement this would be to write a custom
password hasher, as described in the docs:
https://docs.djangoproject.com/en/1.9/topics/auth/passwords/#writing-your-own-hasher

That way, you wouldn't risk missing any code paths where you'd forget
to make the password transformation manually, and it would allow you
to use the built-in views and forms instead of having to roll your
own.

That being said, making passwords case-insensitive sounds like a bad
idea, and you should only ever do that if you know really well what
you are doing.

> If you want to enforce certain password rules (length, must contain
> numbers and special chars, etc) then override
> AuthenticationForm.clean_password() and raise ValidationError() for
> your rules.

Again, Django already provides a more robust mechanism for that, which
has been introduced in version 1.9:
https://docs.djangoproject.com/en/1.9/topics/auth/passwords/#module-django.contrib.auth.password_validation

Cheers,

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160420132016.GE1129%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Issue with Django Password Normalization

[Arun S]

let me try to clear my question.

please correct me if am wrong.
basically all I want to know is that there already exists a number of Unicode 
normalization forms.
Reference

Unicode normalization forms: http://unicode.org/reports/tr15/#Norm_Forms

so as I said as a part of a company norms, the project needs to follow certain 
csdl standards and according to that it states that all passwords shall be 
normalised according to the ref mentioned and then convert then to a utf8 which 
then follows thru the hashing process.

so since the major part of the project uses djangos frameworks, I believe that 
the user authentication methods used already applies the hashing algorithms.

but what I could not figure out is that 
1: does django apply any such normalization process for the user passwords.
2: how is it different between a normalised password and then hashed with 
djangos hashing algorithm s and a non normalised password just saved after 
hashing.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/69f70909-215e-4daa-a770-a10b3c2de63a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Django Password Normalization

[Simon Charette]

Hi Arun,

I'm not sure this is what you are referring to but Django 1.9 ships
with password validation[1] which can be configured to:


   1. Prevent field similarity (e.g. password == username)
   2. Enforce minimum password length
   3. Prevent usage of common password (e.g. "password")
   4. Enforce the usage of at least one numeric character

You could also define your own rules and add them to 
AUTH_PASSWORD_VALIDATORS,

Simon

[1] 
https://docs.djangoproject.com/en/1.9/topics/auth/passwords/#module-django.contrib.auth.password_validation

Le mercredi 20 avril 2016 06:44:49 UTC-4, Arun S a écrit :
>
> Hi,
>
> As a Part of a very big project for a Company, we follow CSDL rules and we 
> use Django Extensively.
>
> As a part of Django, we would like to Follow certain Normalisation Process 
> for all the Passwords during User Login.
> In the Django Documentation, there isn’t any information on whether Django 
> already follows any Particular Normalisation Process.
>
> Could anyone please let me know if Django already Follows certain 
> Normalisation process.
> In case it does, what kind of Process is used and at which point is this 
> applied?
>
> In case, there is no Normalisation process applied, then can a middleware 
> be added to support this?
>
>
> Regards
> Arun.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/cbc9d3d4-4d03-43cf-ab7b-0b5f76d7f607%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Django Password Normalization

[Michal Petrucha]

On Wed, Apr 20, 2016 at 05:41:37AM -0700, Arun S wrote:
> basically I would like to know if the latest version of django
> already supports any kind of normalization for the login passwords.

Most of us probably have no idea what kind of normalization you are
talking about. At least I know I don't. I did try to search for
resources on password normalization, but I didn't find anything that
seemed relevant in the least bit; all I found was a ton of information
on database normalization, which does not have anything with password.

Django does hash passwords using cryptographically secure password
hashing algorithms, if that's what you're asking. If you're interested
in anything else, then the question is, what is your use case, and is
there any reason why a custom hassing function would not do the job?

Regards,

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160420130531.GD1129%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Issue with Django Password Normalization

[Erik Cederstrand]

> Den 20. apr. 2016 kl. 14.41 skrev Arun S :
> 
> basically I would like to know if the latest version of django already 
> supports any kind of normalization for the login passwords.

What exactly do you mean by "password normalization"? Do you want passwords to 
be case-insensitive? If so, you can subclass AuthenticationForm and override 
clean_password(), and set_password() on your user model, and put any 
transformations of the raw password there.

If you want to enforce certain password rules (length, must contain numbers and 
special chars, etc) then override AuthenticationForm.clean_password() and raise 
ValidationError() for your rules.

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/AA50597A-699E-4390-B442-97D76BDF5D78%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Issue with Django Password Normalization

[Arun S]

basically I would like to know if the latest version of django already supports 
any kind of normalization for the login passwords.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/650f8db7-e8a3-4a43-aa21-346d9e39a878%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: request user

[Avraham Serour]

if you can get the request object you can get the current user with
request.user


On Mon, Apr 18, 2016 at 9:38 PM, Elias Coutinho 
wrote:

> Good afternoon people,
>
> I am using django material, LayoutMixin
>
> My view is:
>
> class NewProfissoesPessoaView (LoginRequiredMixin, LayoutMixin,
>  extra_views.NamedFormsetsMixin,
>  extra_views.CreateWithInlinesView):
>title = "New Job"
>model = ProfissoesPessoa
>
> print ( 'come on line 334')
>
> layout = Layout (
>Row ( 'person', 'profession', 'rating'),
># Fieldset ( 'Address'
># Row (Span7 ( 'address'), Span5 ( 'zipcode'))
># Row (Span5 ( 'city'), Span2 ( 'state'), Span5 ( 'country')))
>Inline ( 'Qualifications Profession', ItemInline)
>)
>
> def form_valid (self, form):
>print ( 'come on line 343')
>profession = self.object.save (commit = False)
>profissao.pessoa = request.user
>profissao.save ()
>
> def get_success_url (self):
>return self.object.get_absolute_url ()
>
>
>
> If you look has form_valid function, I'm trying to get my registration can
> be done without having to manually enter the logged in user.
>
> A View only enter if you login, but when loading the template it does not
> meet the user field. (This field wanted to hide)
>
> As I am using django materials needed to create the forms.py
>
> Can someone help me? All he wanted was to save without informing the user
> logged in, he seve be added without the intervention of anyone.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/d5d3b9d5-dba6-4361-999c-e0467ad69a3a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tLMZ4MJKYTzqMYWJw9XgPj2_nBMduNUqzpw32FmMac5%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Issue with Django Password Normalization

[Arun S]

Hi,

As a Part of a very big project for a Company, we follow CSDL rules and we 
use Django Extensively.

As a part of Django, we would like to Follow certain Normalisation Process 
for all the Passwords during User Login.
In the Django Documentation, there isn’t any information on whether Django 
already follows any Particular Normalisation Process.

Could anyone please let me know if Django already Follows certain 
Normalisation process.
In case it does, what kind of Process is used and at which point is this 
applied?

In case, there is no Normalisation process applied, then can a middleware 
be added to support this?


Regards
Arun.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e78eb4df-656d-4d63-aff1-4ff3cf969eb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[marcin . j . nowak]

On Wednesday, August 26, 2015 at 1:08:51 PM UTC+2, grzegorz.stalmierski 
wrote:
>
>
> With current architecture around migrations Django 
> is database owner, not one of the database services.
>
>
Application layer is chaning over time and its lifetime is a way shorter 
than database and data.
Mid-level and big systems are often service oriented, where services are 
responsible to do things other than displaying blog page as a html.
Django should not manage their databases, or even must not. 

Django as a database owner is a nonsense in some cases.  

Don't get me wrong - builtin migrations are ok for small projects, but as a 
system architect I should have possibility to disable them.
When disabled, Django should not remind me about unapplied migrations and 
should disallow me to makemigrations or migrate db.
Also Django should dump SQL of the current models state to make diff using 
external tool.
That' all.

Marcin

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4c1f4933-26ef-4311-b4bc-cd0cd4dbd56d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No Downtime Code Releases

[Daniel Chimeno]

This can help you.
https://medium.com/@healthchecks/deploying-a-django-app-with-no-downtime-f4e02738ab06#.dmyf7lk8y

El martes, 19 de abril de 2016, 3:37:19 (UTC+2), bliy...@rentlytics.com 
escribió:
>
> Hey,
>
> I have two issues I'm looking at solving at work, and I'm looking for a 
> couple suggestions as to how other people have solved this.  The two things 
> are:
>
> * scale out their django installation to allow for smaller releases (I'm 
> thinking microservices, but it could also be internal django apps or who 
> knows what else)
> * minimizing the impact of migrations during releases (aka we want to be 
> able to release in the middle of the afternoon
>
> Currently we put up a maintenance page whenever we are doing database 
> operations (aka migrations).  This seems like a recommended best practice.
>
> One way I was thinking about addressing this issue was to break all of our 
> models out into a separate repo.  That way we'd only need to deploy 
> migrations when the models themselves have deployed.  For code that needs 
> the models, we could pip install the repo as an app and away we go.  
> Likewise it seems like I could break up different parts of our app via a 
> similar strategy.
>
> Does this seem viable?  How have other people solved this kind of problem?
>
> Thanks,
>
> -Ben
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5886e713-b5fb-4263-98e2-3afcde89ab3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.