|
a few DRUNK BONERS posted:Does anyone have any ideas / examples of how to design a project with different databases for different users? The idea is you would log in with username / password / group code and then be in a different database based on the group code (with no shared auth, each database has its own auth table). Database routers have no access to requests. There's some bullshit online about using thread local variables which seems dumb and fragile. Possibly this isn't something that Django can handle with a basic single server setup but maybe there's something I'm missing. Is this the thread local variable solution you’re referring to? Because it doesn’t look terribly unreasonable for the constraints you laid out. I don’t think there’s really gonna be a “clean” solution to this problem because the level of segregation you’re talking about is usually achieved by having a separate instance of the application for each database, which might be worth exploring even if you are constrained to a single server.
|
# ? Aug 27, 2021 14:00 |
|
|
# ? Jun 3, 2024 22:08 |
|
skull mask mcgee posted:Is this the thread local variable solution you’re referring to? Because it doesn’t look terribly unreasonable for the constraints you laid out. Basically I don't trust doing that kind of thing with threads when you're deployed on some cloud VM. I think you're right that there should be separate instances.
|
# ? Aug 27, 2021 19:09 |
|
If I have base.py and it says allowed_hosts=foo.com and I run it on a server/container with env allowed_hosts=bar.net what is the expected hierarchy
|
# ? Sep 10, 2021 01:20 |
|
Hadlock posted:If I have base.py and it says allowed_hosts=foo.com and I run it on a server/container with env allowed_hosts=bar.net what is the expected hierarchy Unless you specify to pull the env variable into base.pay you get what you type. code:
|
# ? Sep 10, 2021 13:38 |
|
Hey - I'm having a struggle with preventing people from making superusers from the default Admin User page. About 80% of the time my custom form without the superuser tick works, but sometimes the original form works, and lets staff members make someone a useruser. (eg from mashing F5, or getting lucky) Relevant code:Python code:
Is there a more "hard" way to prevent people from creating superusers at a deeper level than hiding fields? Using the latest Django. Thank you.
|
# ? Sep 18, 2021 16:03 |
|
`self.fieldsets` is a class attribute (not an instance attribute) and modifying it is not thread safe. I think what you want is to override get_fieldsets instead.
|
# ? Sep 21, 2021 06:47 |
|
Thank you. That worked!
|
# ? Sep 21, 2021 10:39 |
|
Does anyone here run Django serverless (Lambda, Azure Functions) in production? I have a couple of Zappa sites that are basically landing pages but for anything more involved I still host Django on EC2, with an RDS database if the site is sufficiently complex. With Zapppa looking unhealthy I was curious if anyone is looking at anything else like serverless framework or if it's just not a great fit for Django. For a more involved site with lots of async task queues spinning off work I'm looking for recommendations of what people like between moving to something like ECS, or going full bore with lambdas calling lambdas, etc.
|
# ? Sep 28, 2021 16:18 |
|
Hed posted:Does anyone here run Django serverless (Lambda, Azure Functions) in production? I have a couple of Zappa sites that are basically landing pages but for anything more involved I still host Django on EC2, with an RDS database if the site is sufficiently complex. I don’t have any complicated ones but yea deployed with Zappa is the easiest route. AWS SAM is good too. For anything with a series of lambdas calling lambdas I use lambda+ stepfunctions deployed with SAM.
|
# ? Sep 29, 2021 03:44 |
Someone please tell me if there's a better way to do this. I have a non-abstract base model like this: Python code:
Python code:
So, suppose I have a WidgetA and I want to convert it to a WidgetB. What's the best way of doing this? I basically want something like Python code:
Python code:
Is there some shortcut for "pass all the common fields from widget_a to a new WidgetB object"? Maybe something to do with the model _meta API?
|
|
# ? Mar 18, 2022 19:02 |
|
What about vars(widget_a)? That returns a dict of the instance attributes.Python code:
EDIT 2: Rereading, you're trying to avoid having to do that. D34THROW fucked around with this message at 19:26 on Mar 18, 2022 |
# ? Mar 18, 2022 19:22 |
That's actually very close to what I want, thanks! The only issue is that there are a few meta-fields that I have to pop out or WidgetB will barf. This is what I did right after posting: Python code:
Now I just wonder which is more pythonic and less brittle, _meta or vars ...
|
|
# ? Mar 18, 2022 19:31 |
Oh, interesting. Turns out that if you make a dict from vars(widget_a) and then use pop('_state'), suddenly your widget_a object has no _state and then it barfs if you try to delete() it. I could do a deepcopy of the dict and then pop it out of there, but that's more weird opaque boilerplate and still requires the explicit popping, so it doesn't blow my skirt up from a readability standpoint. So I think the moral of the story here is that there is evil magic in the model classes and if they're going to give me _meta, I might as well just use that; turns out it may actually be the most straightforward/single-step way. But thanks again for reminding me about vars, I'd forgotten entirely that it existed...
|
|
# ? Mar 18, 2022 19:44 |
|
Sounds like you’ve got it sorted but yeah I was going to reply that _meta is at least the blessed way since they’ve declared it stable.
|
# ? Mar 18, 2022 19:46 |
|
Data Graham posted:Someone please tell me if there's a better way to do this. Python code:
|
# ? Mar 19, 2022 02:05 |
|
Just doing my check-in to see if anyone's got a good guide to dockerizing Django to run on Fargate or k8s ... I've used cookiecutter-django or some random script I found but they are really opinionated with packages and how to run them.
|
# ? Mar 25, 2022 20:36 |
|
Cross posting from the devops thread as I got no response on over a weekHadlock posted:Is there an established plan of action for running Django migrations on logical postgres replicas It's worth noting that logical replication is a newer type of replication that lets you replicate just a single table or even specific columns of data in a table, different from normal replication i.e. physical replication I'm sure the Venn diagram of Django developers that give two fucks about logical replication on postgres is vanishingly small but gonna give it another try anyways
|
# ? May 3, 2022 20:27 |
|
I've been using Django more and more, but I haven't deployed anything yet. Something that has me confused is I created a ImageField in a model, but upon reading documentation I saw something that said Django can't actually serve media? So does that mean any image I add to the sqlite db won't actually be grabbable by a API? Thanks and sorry for the dumb question.
|
# ? May 4, 2022 14:33 |
|
Django is designed so that static assets (JavaScript, CSS, images) can be served by a CDN, i.e. a separate host to your webserver so that it's not bogged down with small easily-cacheable requests. However not everyone has a CDN so a lot of people use a plugin like whitenoise to serve these assets from the same web server as the Django app itself. For media uploaded via users, you need to build a view to actually serve those; i.e. something that will parse a URL to determine which file to serve, pull the data from wherever it's stored, and send it to the user. Django has a built-in view for this that's convenient for development but isn't suitable for production for various reasons. But you could write your own. E.g. If you have a model "MyImage", you might write a view with url pattern "/view_image/<int:model_id>/", and the view might look something like: code:
|
# ? May 4, 2022 15:50 |
|
Perfect, thank you for the help. I'm not going to push this little app live and it'l llive on my home network so a CDN might be a bit excessive, but will definitely use that built in view tool. Thank you!
|
# ? May 4, 2022 16:00 |
Also the most common (imo) use case is that you would set up Apache or Nginx to serve static files as well as media files directly via a traditional old-school directory alias, because you don't want to be passing requests for statics into your app server and making Django spin up a whole process for every single one. Nginx is built to serve up statics super fast and low-overhead, and you only want it to reverse-proxy requests to routes that actually need processing (i.e. Django routes). Of course that also means you can't do any meaningful access protection or authorization on those statics, so if you care about who can read those files, either you have to make obfuscated paths for any sensitive media to prevent the URLs from being guessable, or (if security by obscurity isn't your bag) bite the bullet and route those requests through an actual Django view like in the above post, so you can do an ownership check.
|
|
# ? May 4, 2022 16:10 |
|
So what i'm doing is just using Django as a API to get 1 piece of text and then a image to use for a background, of which all this information (and the images) are added only by the admin using Django Admin; so I don't think I need to worry about that stuff right? I'm not worried if someone gets in and there's nothing private, although I guess if I ever want to publically expose the API then I would need to worry. I guess I could offload the images to a CDN and then just hold onto the link as a URL in the API which would probably make stuff easier. I'm guessing there's no free CDN's for like ~200 images tho lol. I guess my sub question is, where can I host this API on the web if I wanted to for "free" or cheap? It has maybe 200 objects it'll expose on the API, if that makes sense. Thanks for all the help.
|
# ? May 4, 2022 16:14 |
Yeah if I were you I wouldn't be thinking about CDNs; just store the images on your server and set up Apache/Nginx to say "/media is an alias for /path/to/my/media_root/" (where /media is what you have MEDIA_URL set to and /path/to/my/media_root/ is MEDIA_ROOT). That way your Django admin will put the files in there and users will be able to access them directly by their URL as provided by the FileField.url value.
|
|
# ? May 4, 2022 16:19 |
|
worms butthole guy posted:So what i'm doing is just using Django as a API to get 1 piece of text and then a image to use for a background, of which all this information (and the images) are added only by the admin using Django Admin; so I don't think I need to worry about that stuff right? I'm not worried if someone gets in and there's nothing private, although I guess if I ever want to publically expose the API then I would need to worry. I guess I could offload the images to a CDN and then just hold onto the link as a URL in the API which would probably make stuff easier. I'm guessing there's no free CDN's for like ~200 images tho lol. For hosting your api, try the web hosting thread: https://forums.somethingawful.com/showthread.php?threadid=3289126
|
# ? May 4, 2022 16:45 |
|
sb hermit posted:For hosting your api, try the web hosting thread: To be specific, you'll probably want virtual private hosting, unless you can find a cheap or free provider that just does django or something. You can also try hosting it at home and using something like noip.com but that's not very secure.
|
# ? May 4, 2022 16:49 |
|
Sweet thank you both!
|
# ? May 4, 2022 17:43 |
|
For something that simple, you could host your Django API endpoint on a lambda and just pay $0.0005/request or whatever, have it serve up an S3 link to the image with a one time access token in the response If you want to code golf this you could probably drop the database requirement https://dev.to/vaddimart/deploy-django-app-on-aws-lambda-using-serverless-part-1-1i90 Hadlock fucked around with this message at 02:26 on May 5, 2022 |
# ? May 5, 2022 02:23 |
|
I ended up using PythonAnywhere, didn't know you could lamba that though. Maybe i'll move it to that.
|
# ? May 5, 2022 14:47 |
Is there any better way to do this?Python code:
Is the only way really to do a whole queryset/annotate/filter on the id of the object I already have? Feel like this should be more of a one-step kind of a thing but I can't brain my way into it. e: Here's how I'm a do it Python code:
e2: better yet Python code:
Data Graham fucked around with this message at 16:04 on Jun 25, 2022 |
|
# ? Jun 25, 2022 02:41 |
|
I'm creating an app that involves the User saving "favorite places" pins from Google Maps to the db. So when creating the User model, it seems it's technically possible to extend AbstractUser and add the auth fields + favorite_places=models.ManyToManyField(). Experienced developers seem to recommend creating a separate model, something like Profile, and adding the additional field(s) there, and then creating a OneToOne relationship between Profile and User. Any thoughts on this? To me as a novice, having 1 User model that can take care of everything seems more attractive than having a User model for auth + a Profile model for additional info and creating a 1-to-1 relationship between them. Why is it advised to do this?
|
# ? Aug 2, 2022 20:37 |
It's just easier to tack on a Profile model after the fact, if you never built your app with a custom User model to begin with. If you just used the built-in one, and your app is now in production, you get yourself into a situation where migrating to a brand-new custom User model via migrations is a huge pain. If I'm starting out from a blank sheet, I always like to build my own "User(AbstractUser): pass" as step 1, before even "initial commit".
|
|
# ? Aug 2, 2022 20:46 |
|
I have a Django site behind an AWS ALB, and the auth and redirection it provides is great. However, my old nemesis the "Invalid HTTP_HOST Header" comes up when the ALB does its health checks. For regular requests, of course the Host header is set in HTTP, but for the health checks it just goes for it, and I end up with "Invalid HTTP_HOST header: '172.31.29.18:5000'" may need to be added to your list of hosts. I don't see a way to customize the behavior of the ALB health check, is the only way around this to change my Django config for prod to scrape out the internal IP from the AWS HOSTNAME variable (currently HOSTNAME=ip-172-31-29-18.ec2.internal) and stuff it into the ALLOWED_HOSTS ? I feel like there should be a lot of people with this problem but I'm clearly not encountering it in my searches.
|
# ? Sep 8, 2022 23:25 |
|
Hed posted:I have a Django site behind an AWS ALB, and the auth and redirection it provides is great. If anyone cares I solved this by writing some Django middleware, and putting it higher in the settings.MIDDLEWARE stack than the built-in SecurityMiddleware, such that it short-circuits the response before "Host:" header gets checked in the HTTP request: Python code:
|
# ? Sep 10, 2022 02:38 |
|
Hed posted:If anyone cares I solved this by writing some Django middleware, and putting it higher in the settings.MIDDLEWARE stack than the built-in SecurityMiddleware, such that it short-circuits the response before "Host:" header gets checked in the HTTP request: This actually is helpful, I forgot that we had this same problem 2 years ago and had to fix it until you posted your solution, unfortunately. I still don't recall how we fixed it.
|
# ? Sep 13, 2022 15:40 |
|
I'll be using Django for web scraping to collect data for a business-to-business data service, mainly for business locations. Someone might be using or viewing parts of the PostgreSQL database directly. I want to make it easier to see which columns go with which table during joins or complex queries by using a custom naming convention. The default table name is appname_modelname, and Django doesn't convert the CamelCase model name convention into snake_case. Using the db_table option, the default appname_modelname for the table becomes model_name. Using the db_column option, the default field_name for the column becomes table_name_column_name. The id column becomes table_name_id. The purpose behind this convention is that during a join or complex query, or when different models have the same field names (e.g. first_name), it will make it easier to see which column goes with which table. Particularly, the foreign key will stand out. If there were a product table (using a hypothetical unrelated to the project), its column headers would be product_id, product_description, vendor_id, product_purchase_date, product_price. Is this going to cause difficulty down the line? Removing the appname_ prefix might lead to a higher chance of naming conflicts, but leaving it would make writing SQL queries take slightly longer. Looking at my PostgreSQL textbook, which uses app_name.table_name, it doesn't look like they'll be that much longer and there are always aliases Edit: Also, for naming indexes, I'll use {tablename}_{columnname(s)}_idx. This is PostgreSQL's system for default index naming, and it's used automatically behind-the-scenes when PostgreSQL creates constraints. Django shortens index names to 30 characters for compatibility with Oracle, but I'd like the names to be easier to read and more predictable, so if I accidentally break something and have to go into the DBMS, the SQL environment will feel familiar galenanorth fucked around with this message at 21:45 on Mar 12, 2023 |
# ? Mar 2, 2023 20:56 |
|
galenanorth posted:I'll be using Django for web scraping to collect data for a business-to-business data service, mainly for business locations. Someone might be using or viewing parts of the PostgreSQL database directly. I want to make it easier to see which columns go with which table during joins or complex queries by using a custom naming convention. You can override these conventions pretty straight forwardly. Still, I *highly* advise against lettiing clients have direct access to postgres. (But I get it happens, we have to do this at work for a couple of clients, and lets say I'm not a fan but its not up to me, these clients are multi-billion $$$$ multinationals)
|
# ? Mar 3, 2023 00:41 |
|
I'm helping to take over Votefinder, a Django project for keeping track of voting in games of Mafia on the forums. The previous maintainers of the project were not always Django/Python folks, and in doing an emergency scramble to re-establish the server while it was down I hit a big stumbling block because I didn't realize a previous maintainer of the project changed some assumptions about how Django projects are structured. I'm a bit leery of changing how things are organized in something using a big framework like Django, not necessarily for fear of weird behavior (you'd probably notice quickly enough) but for fear that it'll make the project harder to get into if things don't look and feel like a "normal" Django project does. Another goon just put in a PR to get some better environment variable support via dotenv, and one of the things they did is move everything that was in settings.py to an __init__.py file in a folder called settings. I know that the way Python works this is more or less functionally equivalent and is not a huge change, but like I said before, I'm leery of anything that causes serious deviation from "normal" Django structure. Am I right in being a little gunshy about changes like this, or is this common enough in Django that even if it's not how django-admin startproject wants to arrange it that it shouldn't be too alarming?
|
# ? Mar 30, 2023 23:12 |
|
I'd be a little nervous about that, because Django implements some funky magic with its app-discovery / import system, and lots of places import the settings.py file so anything non-standard there might be tricky to debug. It also smells bad to me that __init__.py is being used for anything except making it easier for other modules to import whatever "public functions/classes/types" exist in the __init__.py's directory. __init__.py is the last place I expect to see code, and it always irks me whenever I find significant code and constants defined there. I might be wrong on this, maybe there's some popular alternative way of managing Django settings and this PR is just following best practices. But I'd feel more comfortable if they could justify that decision by pointing to some docs that explain the alternative and why it's better.
|
# ? Mar 30, 2023 23:54 |
|
minato posted:It also smells bad to me that __init__.py is being used for anything except making it easier for other modules to import whatever "public functions/classes/types" exist in the __init__.py's directory. __init__.py is the last place I expect to see code, and it always irks me whenever I find significant code and constants defined there. I think this is a better way of expressing my feelings - all the settings for the DB type, logging, debug being on and off, etc. are in settings.py. Technically the contents of __init__.py are just declaring these based on reading them out from environment variables, so there's no logic per se - but then it feels like a change that's just made to make a change.
|
# ? Mar 31, 2023 00:31 |
|
|
# ? Jun 3, 2024 22:08 |
|
I will organize my settings files in a folder called settings with a pattern like:code:
|
# ? Mar 31, 2023 01:35 |