Re: Django's User authentication
james_027 <[EMAIL PROTECTED]> writes: > what if I need additional fields or methods for my apps? Do i inherit > it or edit the user class? The standard approach is here: http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model However, also have a look at this approach: http://groups.google.com/group/django-developers/browse_thread/thread/f62b05cae5e5f462/55889eafe381a09b?lnk=gst&q=multiple+profiles&rnum=1#55889eafe381a09b It does require writing a context processor and a middleware, but they are very small and simple, and they greatly simplify the use of your user object in your views and templates. -- +-----------+ | Jason F. McBrayer[EMAIL PROTECTED] | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada| --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: --+++Does anybody have instructions to make a photo app+++--
Naco <[EMAIL PROTECTED]> writes: > Well im looking for tutorials on building a simple photo app to start > with Have a look at stockphoto (http://www.carcosa.net/jason/software/django/stockphoto/). It is a bit out of date, and has a few bugs and so forth that are on my to-fix list, but it is basically a minimalistic photogallery app that is intended to integrate into any django-based site. -- +-------+ | Jason F. McBrayer[EMAIL PROTECTED] | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada| --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Redirecting within custom template tags
neebone <[EMAIL PROTECTED]> writes: > Just to update, I'm getting the form to post to a different url which > handles the logic of creating the comment then redirects back to the > article page on success. All good. My only problem is what to do if > the form contains missing fields - I need to get back to the article > page and re-populate the form with the entered information _plus_ > error messages (field required etc). You are probably to the point of where you need to be writing your own view rather than using generic views and trying to handle things in the template tags. It is probably best for you to just let the article page handle form submissions, so it can handle the errors as well. -- +-------+ | Jason F. McBrayer[EMAIL PROTECTED] | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada| --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: syncdb without shell access
Robin Gruyters <[EMAIL PROTECTED]> writes: >> > > My hosting provider doesn't give shell access, so I can't >> > > execute like "syncdb", "startapp", "startproject", etc. >> > > >> > > Is there another way to do this? (e.g. by creating a runsync.py >> > > script?! (or something?)) If you can access the database provided by your hosting provider remotely, then you can use your local copy of your project to run syncdb: just modify your local settings.py to point to your database on your provider, and run syncdb there. -- +---+ | Jason F. McBrayer[EMAIL PROTECTED] | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it.-- Dogen| --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: FileFields, MEDIA_ROOT, and private media
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > 1) Create two separate media directories: /media/public and > /media/restricted > 2) Configure Apache to serve /media/public directory directly > 3) Configure Apache to serve the /media/restricted directory using > mod_python > 4) Set a url entry in urls.py to e.g.: > > (r'^media/restricted/(?P.*)','myproject.myapp.views.view_restricted_media') > 5) Create view_restricted_media as: > @restrict_to_superuser > def view_restricted_media(request,path): > return static.serve(request,path,RESTRICTED_MEDIA_DIR) Thanks; I'll probably end up doing something very much like this. The only thing I'm not crazy about with this solution is that it is a little intensive on the webserver configuration; I prefer to make the webserver configuration as simple as possible and do more complex things on the application side. In this case, it's not too bad; I'll just have to document it adequately. Thanks again. -- +---+ | Jason F. McBrayer[EMAIL PROTECTED] | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it.-- Dogen| --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: FileFields, MEDIA_ROOT, and private media
"Adrian Holovaty" <[EMAIL PROTECTED]> writes: > Are you using the Django admin for the file uploads? If not, you can > just write your own views that upload the data to a place of your > choosing. You'd be dealing with request.FILES for this. Unfortunately (?), I am using the Django admin for the file uploads -- they are (potentially private) attachments to a wiki-like model, and I'd like to leverage the admin for as much as possible. Another possibility that occurs to me would be to use mod_rewrite to redirect-away requests for that subdirectory of MEDIA_ROOT, but on the other hand, I'd like to be as webserver-agnostic as possible. -- +-----------+ | Jason F. McBrayer[EMAIL PROTECTED] | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it.-- Dogen| --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
FileFields, MEDIA_ROOT, and private media
I've got an unusual situation with an app, and I'm wondering if anyone could make a suggestion. The app will have a number of file upload fields for uploading files that are _not_ supposed to be made available to the webserver (as they are private). I'd like for particular FileFields to be able to upload to somewhere that is not a subdirectory of MEDIA_ROOT. The obvious solution is to just set MEDIA_ROOT to someplace that is not visible to the webserver (making MEDIA_URL somewhat irrelevant), and let the webserver serve media from someplace else, that Django doesn't know about. I can do this if I have to. However, I'd like to be able to use my apps that require this setup in the same project as more typical apps that need MEDIA_ROOT to be visible to the webserver. So, is there some straightforward way to put file uploads outside of MEDIA_ROOT? Should I write my own field class for the purpose? Move the file someplace else in the model's save() method? Use the normal setup, but lock down that subdirectory of MEDIA_ROOT in the webserver's configuration? Something else? -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Model Inheritance
On Fri, 2006-05-05 at 15:06 -0600, Joseph Kocherhans wrote: > That sounds about right. I've been developing a new authentication > system for django since PyCon that allows for different or even > multiple backends... the api has been pretty unstable so far, but it's > getting close. I've written some docs, but I'm sure they could use > some more work. Now that magic-removal has been merged I'm going to > request a branch to finish it up. If you're interested in going that > route and providing feedback, I'll speed up my efforts. I have a patch > available you could use, but maintaining a patched version of django > is a PITA to put it lightly. I would be interested in this, and in following the branch and providing feedback and possibly patches. I'd also be willing to work on docs. > > Does it make more sense to base this project on the Floating Sargasso > > branch, or to take one of those desperate measures? > > That would also work. It'd be better than mokeypatching IMO. If you > aren't using the admin system you're probably best off just rolling > your own authentication. In the long run, basing the project on Floating Sargasso is probably not sustainable. Doing my own auth would not be hard, and would work fine for the main app, since regular users will not be using admin functionality. However, they will, probably, be using various apps integrated into one site, so it just makes more sense to be using django authentication --- in the best case, I'd have to duplicate everything associated with django authentication (like DjangoContext putting request.user in the context), and in the worst, I'd have to do that plus modify various (possibly third-party) apps to use it instead of django auth. Let me know when and how I can help on the new-auth branch. -- ++ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Model Inheritance
"Joseph Kocherhans" <[EMAIL PROTECTED]> writes: > Yeah, it hasn't been implemented yet. I'd be (pleasantly) surprised to > see it finished before the end of the summer. Your best bet is to use > ForeignKey and/or OneToOneField. It's probably not exactly what you > want, but it should work. Note that the semantics of OneToOneField are > going to change by the time inheritence is implemented, so you may > want to use ForeignKey instead. This is kind of painful for me, since one of my projects depends on overriding auth.User (to do ldap authentication). I've been putting off my update to MR in order to think about what I want to do about this. It seems like for now my main options are to implement my own authentication scheme that doesn't integrate fully with Django's and which doesn't work with the auth pages (not _terribly_ important for this particular project), or to monkeypatch auth.User anywhere it might be used (evil). Is that true, or is there something that I'm missing? Does it make more sense to base this project on the Floating Sargasso branch, or to take one of those desperate measures? -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: session auto-logout
"sam" <[EMAIL PROTECTED]> writes: > A newbie question: > > I am using Django admin's authentication to do login/logout for my own > application. I want to automatically log user out if no activity for 5 > minutes. I read the session tutorial and played a bit with > SESSION_COOKIE_AGE -- but it doesn't work for me. Any suggestion > appreciated. Are you sure SESSION_COOKIE_AGE isn't working for you? It won't automatically redirect them to an unauthenticated page when their session is expired, but their next request should hit @login_required and redirect them. Also, if they already had an old session, it will have the default long expiry time. You may wish to flush the core_sessions table and see if it's working for you afterwards. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Multi-page forms
Andrew Gwozdziewycz <[EMAIL PROTECTED]> writes: > Why not just store the values in the database after each pages > submission? That's a point. I hadn't observed that it was a multi-page form for creating an object --- I was looking at the general case of multi-page actions where you are not necessarily wanting to store all that data long-term. The only caveat with doing it this way is that you need to fill in all the required fields in the first page --- either with the final data or with placeholder data that will be replaced by the second page. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Multi-page forms
"Chetan Vaity" <[EMAIL PROTECTED]> writes: > I want to build a two-page form for creating an object. As I see it there are > two options: > 1. Store values in hidden fields > 2. Use the session to store the variables from the first form > > Any Django best practices? I'd say use the session to store the values from the first form. If you use hidden fields, they could be modified by the user after submitting the first page. That would just mean that you'd need to do all your validation in the view handling the second page, but for UI reasons you probably want to do validation of a field on the page where the user actually entered it. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: only show something(form) if javascript-enabled
On Tue, 2006-02-21 at 23:52 +0100, gabor wrote: > i wanted to have in the user-manager form a way to do the normal > password-thing (2 password fields, check if they are equal, and so on). > > so, i created a page-template, put it to the right place so that it > overrides the django-users-manager template, > and started some javascript hacking :) > > i added the password fields to that page, and used javascript to: > -when submitting: check if the 2 passwords are equal, and if they are, > calculate the password-has, set it into the password-hash input-field > (which i made hidden), and allow the form to be submitted. otherwise do > not allow the form to be submitted. Don't do that. Calculate the password hash on the server side. You're trying to do something in the template that ought to be done in the view. So write a view that does what you want, rather than trying to use client-side code to generate stuff to be sent to an existing view. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: using the devel-webserver for production?
gabor <[EMAIL PROTECTED]> writes: > i'll set up something "serious" then there. i think i'll go with the > lighttpd+fcgi approach. You can also build mod_fastcgi for Apache 1.3. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: only show something(form) if javascript-enabled
Gábor Farkas <[EMAIL PROTECTED]> writes: > > at the end, i did the followin: > > - no javascript-visibility tricks > - the form's submit buttons are written out using document.write > - i added a tag to warn the user to enable javascript > > this way, if javascript is disabled, the user cannot submit the form. he > can still see it, but cannot submit (so cannot break anything). Unless they, say, save it to disk, edit it, reopen it, and submit the form. Which would be a perfectly logical thing for a user to do when presented with a trivially broken form that they legitimately want to submit. I know you know that you can't rely on client-side validation, but I just want to say, you _really_ can't rely on client-side validation. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: truncate html filter?
Adrian Holovaty <[EMAIL PROTECTED]> writes: > On 2/8/06, Milton Waddams <[EMAIL PROTECTED]> wrote: >> I'm wondering if anyone has a filter which safely truncates html so as >> not to chop through tags. > > Hey Milton, > > You could try using the Python interface to HTML Tidy: Beautiful Soup (http://www.crummy.com/software/BeautifulSoup/) might also be something to look at for this. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: login via url
On Wed, 2006-02-08 at 06:04 -0800, [EMAIL PROTECTED] wrote: > Does someone have a recipe for logging in via url only. I would like > to have it work with admin or regular user where > credentials can be passed as parameters in a url and they are logged in > and directed to the url. For admin login I am wanting it to simply log > into admin index. You _could_ do this by looking at the admin interface's login view, and handling request.GET the way it handles request.POST. But IMO you _shouldn't_ do this, as it may (depending on other things) open up quite a few new ways to steal credentials (think about referrers, and about httpd logs). -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: memory usage
On Wed, 2006-02-08 at 13:36 +0530, Kenneth Gonsalves wrote: > i have three django sites on a box. It is virtual hosting. The > active memory allotted is 75MB. I am getting complaints that i am > exceeding this memory. What can be done? as far as i can see, each > time someone accesses the site, a new httpd process is started > which takes up about 12 mb - 6 hits and the memory is exhausted It will probably take more specific information to answer this. What is the webserver (apache, lighttpd, other), and what method are you using to connect django to it (mod-python, fast-cgi, scgi, other)? If fast-cgi, how is your program started (apache mod-fastcgi process manager, or standalone)? All of those could have some impact on memory usage. Also, according to another recent thread on this list, DEBUG=True significantly increases memory usage. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Do I use @login_required to extend authentication?
On Thu, 2006-02-02 at 12:32 -0800, Jason Huggins wrote: > Hmm... Jason, your code is probably the "next logical step" for my > hack. The following is the right link to your code, yes? > -->http://www.carcosa.net/jason/blog/computing/django/authentication-2005-12-05-13-25.html To some of it, heah -- the bit that replaces the user model. My actual code in (development/testing) use also includes the ldap login function, a "populate this user object from ldap" function, and login and logout views that will create a user object if necessary. I'd post them here, but it would probably be more work for me to sanitize out the local-interest-only stuff from the general code than it would be for you to write your own version -- it's really just a dozen or so lines of code. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Do I use @login_required to extend authentication?
"tonemcd" <[EMAIL PROTECTED]> writes: > You do mention that every entry in LDAP must also exist in the django > users table as well - is that a fundamental requirement? I've written very similar django-to-ldap glue code to this, and what I did was treat the django User model as a cache of data in ldap. I have a login view that, if a matching django user cannot be found, but ldap authentication succeeds, creates the django user, then imports information about them into the User object from ldap and saves the user. The user object could be deleted on logout, or periodically by a grim record reaper but I haven't found that necessary yet. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Adding ManyToMany relationships
On Wed, 2005-12-07 at 05:35 -0800, quentinsf wrote: > OK, I've found the code, and it looks as if set_FOOs() does intelligent > things about only updating the *changes* to the list of object IDs. > I'll use that for now. > > Add and Delete methods would be nice though, as would something that > takes objects instead of IDs. Seems more Djangoesque. (Is that a > word?) I've also been missing add/delete methods. The app I'm writing/using uses a ManyToMany relationship to keep track of what articles each user has read. Adding to this list is a little slow, at least partly because the whole list must be fetched and updated before set_FOOs() gets called. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: ANN: Django site on washingtonpost.com
On Mon, 2005-12-05 at 21:20 -0600, Adrian Holovaty wrote: > Check it out: The first Django app at washingtonpost.com! > > The U.S. Congress Votes Database > http://projects.washingtonpost.com/congress/ > > It lets you browse every vote in the U.S. Congress since 1991. Very useful, and the RSS feeds could be a very handy tool for activists. One thing -- the RSS feeds would be a lot more useful if they included the bill and the vote description -- the Question field is not very informative without that, and right now it's the only thing besides Yes or No in the entry afaict. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: E-Commerce / Credit Card Processing
On Wed, 2005-11-30 at 17:51 -0800, Joshua D. Drake wrote: > We will actually be writing a class for PayFlowPro here in a couple of > weeks. I am sure > we could share. I would be very interested in this, as well. Are you translating their PHP or Perl code from the developers kit, or taking some other approach? -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: redirecting subdomain requests
On Sun, 2005-10-16 at 14:27 +, Alice wrote: > I'm just learning regular expressions (something I've put off for ages > now), and was wondering if it was possible to redirect from a subdomain > to somewhere within my project using Django, i.e. > > redirect 'Subdomain.domain.com.au/appname/' to > 'domain.com.au/appname/pagename' > > or is this better suited to mod_rewrite? (something else I've put off > learning about) You could put an app at subdomain.domain.com.au/appname/ with an index view that just returns HttpResponseRedirect. But learning just enough about mod_rewrite to do the job would probably be less work. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: django in a production environment
On Mon, 2005-09-12 at 21:10 -0500, Adrian Holovaty wrote: > We've used Django with mod_python for the past couple of years in a > production setting, so that's the most "proven" server arrangement. I > personally haven't used it with fcgi -- just haven't had the chance -- > so I'm not sure how fcgi compares. Can anybody else chime in? Well, I should jump in and say that, even though my previous post may have sounded a little negative about fastcgi, fastcgi is my choice. Partly this is just because I have more experience with fastcgi than with mod_python, but it is also because fastcgi is a more general solution for replacing CGI, running PHP, etc. I'd be running mod_fastcgi anyway, so why not use it for Django? Another poster mentions SCGI. I've looked into that, but the Apache 2 module for it is unstable, according to the documentation, which rules it out for me. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: django in a production environment
On Tue, 2005-09-13 at 02:00 +, [EMAIL PROTECTED] wrote: > I am getting ready to deploy my first real production django web site > for a customer and I was wondering what people had to say about > mod_python vs fcgi. I have the impression that using mod_python is the > prefered way. Is this because of speed? Or are there other reasons > why fcgi is not desirable? They both have their own disadvantages. The main disadvantage of fcgi is that the stack is more complicated (apache mod_fastcgi -> flup fcgi - > django wsgi). There is more to configure and there is more to go wrong. It's not unusual to have intermittent errors with django on fcgi, either after first starting the fastcgi server, or under high load. (This may not be true with lighttpd, of course.) The main disadvantage with mod_python is that it has to run under the same userid as Apache. Also on shared hosting, it is probably a bit less common than mod_fastcgi (not sure). If the server is dedicated to your django website, then neither of these is probably a problem. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Packaging django apps
On Thu, 2005-09-08 at 19:21 -0700, Jason Huggins wrote: > Jason F. McBrayer wrote: > > Hi. I've more-or-less finished a django app that might be useful to > > other people > > > I'd like to package this for other people in a way that is as convenient > > for them as possible, while not requiring too much work from me. So, > > what do people expect from a third-party django app by way of packaging? > > The Python world is slowly catching on to using Python "eggs" and the > "cheeseshop" (gosh, I hate that name-- I'll henceforth only call it > "The Shop".) Don't like the bouzouki player? Yes, I've been noticing the use of eggs and ez_setup. Good and bad points. Good: usually gets dependencies for you. Bad: breaks ./setup.py bdist_rpm, which is how I normally install Python libraries. I'll look at app-packaging as an egg, but I suspect that for a django app the more practical option will be along the lines of "unpack this tarball in your apps directory, run this script to set up the database, add to your installed apps by hand"... -- ++ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Dealing with long operations in views
Suppose a view, handling a POST, has to perform some task that can be reasonably expected to take a lot of time, long enough that it will often cause a timeout somewhere in the chain (between browser and webserver, between webserver and fastcgi server, etc). Suppose the view (as naively implemented) tries to do the normal thing and redirects to a GET version of itself after handling the post. What's the best way to prevent the timeout? Use a thread or os.fork() to do the work in the background, and go right ahead with the redirect? Do the work in the background and redirect after sleeping a little or via a temporary page, even though you don't know for sure that the job is done? Is it even safe to use a thread or forked process to do the work? -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Packaging django apps
Hi. I've more-or-less finished a django app that might be useful to other people --- it's a feed reader similar to feedonfeeds, except that it is multiuser, supports categories, and is more tolerant of invalid feeds (thanks to the wonderful feedparser -- feedparser.org). It's basically functionally complete (I now use it instead of feedonfeeds), though it still has a few rough edges and is missing some less-used views. I'd like to package this for other people in a way that is as convenient for them as possible, while not requiring too much work from me. So, what do people expect from a third-party django app by way of packaging? Just a tarball of the app and templates directory? Install scripts? README, COPYING, and INSTALL documents? -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: internal_error.html?
On Mon, 2005-09-05 at 18:50 -0500, Eugene Lazutkin wrote: > Yep. It depends on size. It seems that web server sends the first part of > page up to some limit and stalls for a while. After that it may send the > rest or append "internal_error.html" nonsense. > > Now I have to figure out who is the culprit: Apache, FastCGI server, Django > (e.g., FastCGI portion of it), or some weird interaction of all of them. My > bet is it is not Django, but who knows... I have had a similar problem with django under fcgi (using the fcgi-wsgi connector from flup). On longer pages, most of the page is sent, then it stalls until mod_fcgi times out listening to the fcgi-server, then sends the rest of the page. I have found a workaround for this, which is to use flup's gzip middleware like so: django-fcgi.py: -- #!/usr/bin/python from flup.server.fcgi_fork import WSGIServer #from flup.server.fcgi import WSGIServer from flup.middleware.gzip import GzipMiddleware from django.core.handlers.wsgi import WSGIHandler handler = WSGIHandler() handler = GzipMiddleware(handler) WSGIServer(handler).run() This prevents the stalls, at least for browsers that support gzip encoding! I am not, at this time, sure where the problem lies; whether it is in django's WSGI interface, in flup's fcgi-wsgi adapter, or in Apache's mod_fcgi. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: initial data
On Thu, 2005-09-01 at 10:15 +0100, Rachel Willmer wrote: > is there a django way to set up the tables with the initial data I > want? or should I just do this using a postgres script? You could either do it with a postgres script, or you could write a python script that imports your models, instantiates objects, and saves them. Or, of course, you could use the admin interface, but that would quickly get tedious. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Storing models in sessions
On Wed, 2005-08-31 at 14:28 +0400, Maniac wrote: > I use Django's model objects to store a users environment. It's not just > some options like prefered color or something instead it's a full blown > model. To be specific it's an application for ordering printing of > digital pictures. The users environment consists of a desktop with image > thumbnails, thumbnails know their position on the desktop, and also > store all the printing parameters like paper type, size, special framing > etc. > > Speaking generally I wonder how (or wether) Django's sessions are > suitable to store such rather large structured data. I think you would be better off storing the model objects as usual, but adding a couple of flags to your model: one to indicate that this object is a temporary/unregistered user, and one to store when the object should be expired. You can then either periodically do batch expiry, or some other system. I assume that once no sessions refer to one of those users anymore, having an inactive temporary user model hanging around doesn't cost you anything except database space which you can reclaim when it's convenient. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: User Authentication - What's the best way?
u = users.get_object(id__exact=user_id) if user_id: return view_func(request, *args, **kwargs) else: return redirect_to_login(request.path) except (KeyError, users.UserDoesNotExist): return redirect_to_login(request.path) return _checklogin A typical view function will be decorated with login_required like so (as I'm using python 2.3): def view(req): blah blah blah... view = util.login_required(blah) > Anyone point me in the right direction? Or even a breif explanation of > how django's admin authentcation works might get me going. I arrived at this solution by looking at the anonymous session documentation and the admin code. If my code samples don't help, you might want to look there, too. Good luck! -- ++ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Basic file upload (not model file object)
On Tue, 2005-08-30 at 03:32 -0700, Dagur wrote:
> It took me a while but I figured out how to do this:
>
> if request.POST:
> new_data = request.POST.copy()
> new_data.update(request.FILES) # This has to be added
>
> errors = manipulator.get_validation_errors(new_data)
> if not errors:
> new_message = manipulator.save(new_data)
> return HttpResponseRedirect("%i/" % new_message.id)
Thanks for the response. My problem actually turned out to be a hard-
to-spot typo in my template. The "enctype" on the form was
"multipart/form_data" rather than "multipart/form-data". Too much
typing python, I guess ;)
Thanks, all, for the response. As I said, I knew it had to be something
stupid.
--
+--------+
| Jason F. McBrayer [EMAIL PROTECTED] |
| "If you wish to make Pythocles wealthy, don't give him more |
| money; rather, reduce his desires."-- Epicurus |
Re: Basic file upload (not model file object)
On Mon, 2005-08-29 at 20:04 -0700, Leonardo Santagada wrote: > Just guessing, but in python strings are byte arrays, so I don't think > there is any error in that. Or maybe there is a problem with the form > sending the content and the validator expecting a filename, or the > inverse. > > Just my 2 cents, and as noone answered this I thought it may help The problem seems to be that the validator isn't expecting a string. I assume that it is not a bug with the validator (or else it would have been noticed, since it is the built-in validator on the standard FileUploadField), but somewhere else, either in my template or my view, but I am unable to find the problem (so far). Thanks for the input. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Basic file upload (not model file object)
I'm almost certainly missing something very, very simple here, but I haven't been able to find what it is on my own. One view in my app should allow users to upload an OPML file, which the app will parse and use to import feeds, but which won't otherwise be stored. As with most other non-model-based forms, I'm using a custom validator for this form: class AddFromOPMLManipulator(formfields.Manipulator): def __init__(self): self.fields = ( formfields.FileUploadField(field_name="opml_file", is_required=True,), ) When the form is submitted, I get this traceback: Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/handlers/base.py", line 64, in get_response response = callback(request, **param_dict) File "/home/jmcbray/Documents/topical/business/site_test/apps/engulf/views/util.py", line 231, in _checklogin return view_func(request, *args, **kwargs) File "/home/jmcbray/Documents/topical/business/site_test/apps/engulf/views/engulf.py", line 333, in add opml_errors = opml_manipulator.get_validation_errors(opml_data) File "/usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/formfields.py", line 70, in get_validation_errors validator(new_data.get(field.field_name, ''), new_data) File "/usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/formfields.py", line 491, in isNonEmptyFile if not field_data['content']: TypeError: string indices must be integers The form enctype is multipart/form-data. Obviously the value of the field the validator is seeing is a string, and obviously it shouldn't be. So what's going wrong here? It's surely something that should be completely obvious, but somehow I'm just managing to miss it. -- ++ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: IMPORTANT: Django model syntax is changing
On Fri, 2005-08-26 at 13:33 -0500, Adrian Holovaty wrote: > On 8/26/05, Jason F. McBrayer <[EMAIL PROTECTED]> wrote: > > > In [1]: from django.models.engulf import feeds, users, articles, categorys > > > In [2]: c = categorys.get_list(user_id__exact=1) > > You want categorys.get_list(user__id__exact=1) -- a subtle change. > With the new syntax, calling code never refers to the "user_id" field > -- only to "user". Ahah. That's a good candidate for the change documentation there. I've added it to the user-contributed notes on the Wiki. -- +----+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: IMPORTANT: Django model syntax is changing
The new syntax breaks get_list() for me. Here's an excerpt from my
model:
class Category(meta.Model):
name = meta.CharField("Name of Category", maxlength=255)
user = meta.ForeignKey(User)
feed = meta.ManyToManyField(Feed, filter_interface=meta.VERTICAL)
class META:
admin = meta.Admin()
def __repr__(self):
return self.name
class User(meta.Model):
username = meta.CharField('Username', maxlength=64, unique=True)
password = meta.CharField('Password', maxlength=64)
feed = meta.ManyToManyField(Feed, filter_interface=meta.VERTICAL,
null=True, blank=True)
class META:
admin = meta.Admin()
def __repr__(self):
return self.username
def check_password(self,password):
if password == self.password:
return True
else:
return False
And here's what fails (in an ipython session, to demonstrate):
> In [1]: from django.models.engulf import feeds, users, articles, categorys
> In [2]: c = categorys.get_list(user_id__exact=1)
> ---
> TypeError Traceback (most recent call last)
>
> /home/jmcbray/Documents/
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/utils/functional.py
> in _curried(*moreargs, **morekwargs)
> 0 return _curried
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in function_get_list(opts, klass, **kwargs)
>1118
>1119 def function_get_list(opts, klass, **kwargs):
> -> 1120 return list(function_get_iterator(opts, klass, **kwargs))
>1121
>1122 def function_get_count(opts, **kwargs):
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in function_get_iterator(opts, klass, **kwargs)
>1100
>1101 cursor = db.db.cursor()
> -> 1102 select, sql, params = function_get_sql_clause(opts, **kwargs)
>1103 cursor.execute("SELECT " + (kwargs.get('distinct') and "DISTINCT
> " or "") + ",".join(select) + sql, params)
>1104 fill_cache = kwargs.get('select_related')
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in function_get_sql_clause(opts, **kwargs)
>1297
>1298 # Convert the kwargs into SQL.
> -> 1299 tables2, join_where2, where2, params2, _ =
> _parse_lookup(kwargs.items(), opts)
>1300 tables.extend(tables2)
>1301 where.extend(join_where2 + where2)
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in _parse_lookup(kwarg_items, opts, table_count)
>1287 _throw_bad_kwarg_error(kwarg)
>1288 except StopIteration:
> -> 1289 continue
>1290 return tables, join_where, where, params, table_count
>1291
>
> /usr/lib/python2.3/site-packages/django-1.0.0-py2.3.egg/django/core/meta/__init__.py
> in _throw_bad_kwarg_error(kwarg)
>1176 def _throw_bad_kwarg_error(kwarg):
>1177 # Helper function to remove redundancy.
> -> 1178 raise TypeError, "got unexpected keyword argument '%s'" % kwarg
>1179
>1180 def _parse_lookup(kwarg_items, opts, table_count=0):
>
> TypeError: got unexpected keyword argument 'user_id__exact'
>
I've tried a few variations on the keyword argument, and can't seem to
find what it is now looking for. I regenerated the database from the
model (sqlreset) and populated it a bit, just to make sure that wasn't
it, but no joy. My django tree is at revision 559. Is anyone else
seeing this?
--
++
| Jason F. McBrayer [EMAIL PROTECTED] |
| "If you wish to make Pythocles wealthy, don't give him more |
| money; rather, reduce his desires."-- Epicurus |
Re: Existing Database?
On Fri, 2005-08-19 at 08:35 +0200, Andreas Kostyrka wrote: > And there is completely another answer that would match with the > question: How to write a completely "independant" model -> which APIs > must be implemented by a model. (Consider "legacy databases" that are no > SQL databases.) I am interested in this as well. I've seen some examples of adding non- database methods to a model, but nothing that is entirely dissociated from an SQL database. -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
Re: Problems with User Auth stuff
On Tue, 2005-08-02 at 18:28 +, Django wrote: > I made it work with the users going in django.models.auth. But it is > not a very good solution as it becomes project-wide and I cannot have > another similar application. > > I think we need to have a way to tell the auth/sessions framework the > correct user tables to use. It is hardcoded to pick the > django.models.auth table only! Just to chime in on this: I would like to be able to have users authenticated against something else entirely (an LDAP server), while still supporting sessions in some convenient manner. Ideally I would also have credentials stored on the browser side (Basic-Auth over SSL or Digest-Auth) rather than stored in session files on the server, but that's a separate issue, I suppose. Can anyone suggest how I ought to go about plugging an alternative authentication model into Django? Or should this kind of thing be on the devel list? -- +--------+ | Jason F. McBrayer [EMAIL PROTECTED] | | "If you wish to make Pythocles wealthy, don't give him more | | money; rather, reduce his desires."-- Epicurus |
