#django

one is by react ( facebook ) community and other is by django

cool_dude: thats an entirely different question :P

guys, if I want to use a custom manager everywhere? for example filtering by user objects.filter(user=request.user) and only if the user is superuser use the classic objects.all()

I mean, when I use objects.all() this should filter by user. Instead if I user superobjects.all() this is not filtered

It's a bad idea?

well, without using a threadlocal for request, you have to pass the request along somehow

yes Kangermu you are right

yeah, the dubt now is not about retrieving the `request`, I used request.user as example. I just want to swtich this logic

obects.all() is a queryset always filtered by `domain` for example

superobjects.all() is not filtered by domain

... you still need to pass the value in somehow.

what about creating a mixin that define a manager?

kezabelle: you mean the filter?

kezabelle: this way https://dpaste.de/K5ep

Hello! I've deployed a django app using Gunicorn and Nginx, but I can't access the django admin page, even though I create a superuser (and have run migrations), it just says username and password is wrong. even though I've created multiple superusers to test. Any idea where the problem might be? I can post any config you guys want, but not sure what you want

are you sure web application and cli is accessing same database?

vimes: is the user active?

createsuperuser creates active user

assuming you have not messed with it or usermodel

knbk: I would assume so, I did the same process on localhost and it worked ifne

no I have not

I did use certbot's nginx package to generate ssl for https though

try manage.py shell and get all user form auth model

the users seem to be there ssv https://dpaste.de/F2dr

vimes: are user.username and user.password as expected (i.e. user.password is a password hash)?

(and I'd check user.is_active just to be sure, even if the default is True)

ar you using sqlite?

Hi guys, I am developing an api for a mobile app using django rest, my problem is the mobile team wants us to support passing of "id" to a resource, that means they are the ones who will create the ID/primary key of the model, is it okay to support that one? we are using uuid for the id btw

not quite sure how to check that, let me google knbk , fleetfox I'm using postgres

vimes: what exactly are you not sure about?

vimes: ok, is there user which you created? if yes, probably you need to check your settings.py

knbk: how to see if passwords are hashed, but I have not fiddled with how django should store passwords

ssv: yes the users I created are there

vimes: try to use a sqlite3 as a default database and also set your SECRET_KEY as a 'abcd' and try to create user again

vimes: well, if user.password is a plaintext password it is not hashed, otherwise it probably is

ssv: huh, why exactly?

vimes: what version of django you use?

vimes: also check user.has_usable_password()

knbk: you misunderstand the true level of my incompetence, I'm unsure how to get user.password (andreas.password). I tried importing * from django.contrib.auth.model and calling andreas.password with no luck

1.11 knbk

seemed like the sensible version to use

vimes: right. You know how to get a queryset, right? you can get a specific user by using `user = User.objects.get(username='andreas')`

knbk: I'm not sure, maybe he's create a user with one secret key then change it and try to log in :)

then you can print user.password, etc.

ssv: the secret key has no effect on whether you can log in

knbk: I mean, when you create a new password

it's used for password reset tokens and to sign cookies, but that doesn't matter in this case

knbk: yes the password is a hash

I do have a differnet settings file for the server and localhost, but I don't see how it should mess things up

vimes: does `user.check_password('your_password')` return True?

knbk: yes it returns true

knbk: you're right, my bad (only for sessions, messages and password reset token).

https://dpaste.de/YFhD settings for my production

vimes: are you using those settings when running the shell?

hmmm maybe I'm not

export DJANGO_SETTINGS_MODULE=mysite.settings <- this should do it?

if those are your production settings, yes

you can always do `from django.conf import settings; print(settings.DATABASES)` to check if it's what you expect

vimes: what kind SESSION_ENGINE you use?

well it works fine when running from the server using just the django server (I know it's a bad idea), still working on making the other settings work

vimes: probably you session are not save after log in

iamriel: if you're using the full uuid, you have practically no chance of collisions, so that aspect shouldn't be an issue

ssv: is this hit? 'django.contrib.sessions.middleware.SessionMiddleware',

ssv: that wouldn't explain the error message, though

vimes: try to check you session store.

vimes: no, by default it's backends.db, check you django_sessions

knbk: but we still need to verify it in the server right?

vimes: I think fleetfox was correct the first time and you shouldn't have listened to any of us :)

knbk: That means we need to check if there is "really no" conflict?

vimes: check your server configuration to see which settings file is used by nginx/gunicorn

knbk: it's the production settings file

so it stores to postgres, localhost stores to sqlite

iamriel: for all practical purposes -- no

vimes: logins are working on the production? but not working on a local enviroment, right?

no the other way around

they are working localhost

but not on the server (production)

settings file is defined in gunicorn as DJANGO_SETTINGS_MODULE=fossekall.settings.production

vimes: then run your shell with `--settings=fossekall.settings.production` and check if the user exists

vimes: try to connect to postgres and check django_sessions table, the are store any sessions?

ssv: the login form itself gives an error, so sessions are not the problem

it seems like it can't find my user now

so your shell was using a different database. You need to create the user while using the production settings file

knbk: hm, maybe need to check AUTH_USER_MODEL and set if it not default.

sounds like very strange.

knbk: so it seems. can I set it to use the prod. database, or do I always have to manually go into shell with the correct settings defined?

I figured it out! I just create superuesr with the --settings. Thank you !!!!

oh, yay!

gz

is there an easy way to swtich default databases at runtime?

knbk: I see, thanks :D

Is there any performance difference between setting a model's __str__ to something like '{}: {}'.format(self.region, self.year) vs having a 'name' field on the model that is set to the same string once and then saved? With the name field, then I would set __str__ to self.name. Particularly if an instance's 'name' is dependent on many fields and ForeignKeys of the instance.

depends how often you render and need it