#django

jaagr any packages like what you describe?

you can run any number of django projects on the same server, just do the deploy instructions again :)

BlueOrg: Are you writing your blogs from scratch? (if you are making a blogging application that is)

contacten = Contacten.objects.filter(user=request.user.profielen).iwantthisidsontop(listids)

NBhosting: great function name =)

just as example to explain what im trying to

NBhosting, you could use Q to write something like: OR ID in (1,2,3)

wow "These format characters are not used in Django outside of templates. They were designed to be compatible with PHP to ease transitioning for designers."

BlueOrg: Just write the user signup package stand-alone and use it in both of your applications.

shinobi_one: lol, what characters? <?php ?

jaagr so I'm going to have 2 databases with their own Users? so a User in app1 can't use the same credentials to log into app2?

BlueOrg, yes, sounds like what you want

BlueOrg: well, depends on how you design the authentication... you can use the same database, even the same table if you'd like

when using an abstract base class for a child model, do i need to do anything else then the usual field describing for django to generate SQL?

jaagr: ... the template builtin "date" uses PHP style format characters instead of python strftime strptime :O

jaagr, why make things complicated :)

waverider: when did I make things complicated?

or do i need to write the SQL by hand, because manage.py sql 'appname' isn't giving any output for this child model

I was wanting to unify the log in process in the first place. If User logs in app1 he should be able to log into app2 also with the same credentials. I wanted to know how I can share the credentials.

waverider: thought I explained it well =)

jaagr, waverider :)

basic auth with 2 dbs works excellent. No need for "custom backend" ?!

BlueOrg: Then you would use the exact same auth. system

BlueOrg, for me it becomes less clear what you want. But sounds like you should read about authorization as well (not only authentication). You can have one authentication system and db for all users and provide differen permissions on apps (or url, object, etc.)

jaagr okay. so i wouldn't need to make any modifications to the auth system, is it? So if a user is created in app1 and is stored in app1.db when he hits app2's url and tries some CRUD operation there he would still be authenticated with credentials from app1.db? It seems a little mysterious to me.

waverider ^^ is that a little more clearer? Thank you, i'm still picking up django at work.

BlueOrg: are the 2 apps on the same domain? eg: app1.domain.com and app2.domain.com?

jaagr more like www.domain.com/app1/ and www.domain.com/app2/. but yeah. same domain.

BlueOrg, google django multiple databases (this is no big deal these days) and also look at authorization

he won't need multiple databases for it

he explicitly said he want's the same users for both apps

jaagr, just re-read his messages and he said he will need to update stuff in multiple dbs (as business logic)

yes, i mean for other stuff

waverider: regarding auth?

" Hello, I'm writing a website using django. In my project structure I have multiple apps. All do some kind of CRUD operations in multiple databases."

doesn't matter, does it? he still wants his auth to be shared

jaagr "So if a user is created in app1 and is stored in app1.db when he hits app2's url and tries some CRUD operation there he would still be authenticated with credentials from app1.db? It seems a little mysterious to me."

So BlueOrg: one db for authentication, you write some authorization logic for your different apps (you can even implement some sort of "sign up for app2 as well", that's your custom logic)

jaagr, multiple db-s is not related to auth

waverider: in this case, it's related to authentication

I was answering another part of his initial question, this part: "All do some kind of CRUD operations in multiple databases."

for auth, yes a single db

BlueOrg: don't tie the authentication to a specific app. If the apps are shared, use a shared part.. the authorization could be explicit for the apps in say

jaagr there are some operations in each app that would require a user to log in, i didn't want to create a hassle by asking them to sign up for app1 and app2 separately. if a user signs in through one app then it should also be valid in the other app. that was the gist. :)

jaagr okay.

any specific concepts/packages i could google for? thank you. :)

Anyone use Django Rest Framework? I could use a little help with permissions.

django authentication, django authorization

they are in django core

BlueOrg: Yeah, that's why you would use a shared storage for authentication.. But the authorization for the two apps would be separate.

separate like in two dbs?

jaagr hm, how would that happen?

waverider: as in divided into app1/app2

I'm confused. Are we talking about different apps, or different projects?

BlueOrg: ok, lets say you have a table with users.

jaagr okay...

BlueOrg: all registered users go into that table with authentication information.. then you have a table with permissions.. some permissions are for app1, and some for app2.. users belonging to only app1 only get those permissions.. and vice versa..

BlueOrg: just read the django auth docs

jaagr aah. okay. so if i authenticate them in the beginning before they go to either domain.com/app1/ or domain.com/app2 and store that info and have a table for permissions for both app1 and app2 that should effectively solve the problem, right?

jaagr okay. will do! Thank you! :)

BlueOrg: Yes.

thank you and waverider for patiently walking me through this! :)

BlueOrg: Since they are are on the same domain, you don't have to worry about anything else than the session

BlueOrg, no problem. The most important part is that one usualy clears things in his head first of all :).

And that often happens after talking about it for a while =)

jaagr, that's what it usually happens to me!

by the time I finish the question with the whole context, I usually know the answer :D

hehe yeah

here's a short model called TemperatureDaemon, for some reason django isn't generating SQL for the model, anyone happen to have any clues to why that could be? https://dpaste.de/KxFx

it uses an abstract base class

sorry for asking the question again, it's formed a bit better this time :)

Any good coding tunes to recommend? Use Your Illusion 1/2 is getting old!

simp: it's not generating anything at all?

simp, I am not 100% sure if that first string param does the right thing for all field types, you migh want to check that

it generates the sql needed for other models, but not this one

simp: Where is the TemperatureDaemon getting the `model` from?

`models`*

another app, and it's imported in top

jaagr just a small clarification. in the models.py files of my apps i know more need to define a User model right if i'm handling the auth in another app that the user encounters when he hits the / url? I could directly use login_required() in my apps after providing the nesscarry permissions for the apps?

the server daemon validates the code and finds no errors

simp, why would you want to have in the same class (via inheritance) linux daemon code and database model code anyway? Makes no sense. Just instatiate a model object (=db row) in the daemon where you need it.

two different things should be in two different classes

*very different

BlueOrg: Make a new app called user/auth/whatever...

BlueOrg: Then just require login for the views that requires authentication

waverider: to have different daemons that can be started and stopped separately

jaagr okay. thanks!

BlueOrg: Don't tie the authentication/authorization to a specific app. Since it will be shared between the two

simp, and you want a db row per daemon? You need to reference that db row via a plain variable.

BlueOrg, do you have a reason to not use the default django.contrib.auth.models.User and need to write your own user class?

waverider: that's exactly what i want. so i need to create another model that takes the info from TemperatureDaemon and then writes it to the DB?

while moving the temperatureDaemon somewhere else ofcourse

hmm, simp, models provide exactly that: write data to db. Have you followed the django tutorials? :)

waverider yes, i have some other fields i need to add to my User model apart from the ones specified by django.contrib.auth.models.User class.

BlueOrg, that is commonly done through django user profile (google that)

which is just another custom table linked to the user

hmm, one sec, this way might be obsolete, let me check

waverider: yes i have, but it's the first daemon i'm writing for it, all the other stuff has been reading probes. i'm quite new to django so it's good to get some feedback for the code every now and then :)

BlueOrg: Write a Profile class and use a ProxyUser

BlueOrg: What version of Django are you using?

Django 1.5.5

BlueOrg, Deprecated in Django 1.5: https://docs.djangoproject.com/en/1.6/ref/contr...

so jaagr was right, custom user way: https://docs.djangoproject.com/en/1.6/topics/au...

I am used to the old ways :)

I have a very newbie question.

Can someone give me an example of how a model Meta Class may be used?

I think I kind of got the a handle on it.