DRF structure query

Hi, Being fairly new to DRF, I'm just wondering on the best ways of going about stucturing an api which has man endpoints. Basically is there a good reason not to put different categories of endpoints together in different apps, like the ones for user data, ones for app data etc. And then

Re: How to insert a csrf_token when entering datas through a bot ?

On 12 April 2011 22:09, JustinMarsan wrote: > Hello, > > What would be the best way to allow some bots to POST some content to > a website. Without crsf_token, the bot will get a 403, and I would > prefer not to remove this behavior but rather find a way to make the >

Re: Advice: project hosting apps

There is also http://gitorious.org/ - it is ROR, but it is agpl. -- 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

Re: Cool and useful development commands :-)

On 24 February 2011 00:29, Simone Federici wrote: > Maybe you could write a filter "urlsafe" to use into templates so that > variable does not contains javascript. > And you could create a command that scan templates and raise an alert every > variable inside an href

Re: Just going to point this out ...

It would be interesting to perhaps extend something like django-lint to pick up on what could be mistakes in templates. -- 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

Re: Just going to point this out ...

> > is this what you're looking for? > > http://www.owasp.org/index.php/OWASP_Application_Security_FAQ > > Mike Hi Mike. Well in this case the page would be http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet but yes that link is a good starting point. I should

Re: Just going to point this out ...

> Which of course it can't - it is properly escaped. > > Cheers > > Tom > Yes. -- 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

Re: Just going to point this out ...

On 19 February 2011 01:36, Masklinn <maskl...@masklinn.net> wrote: > On 2011-02-18, at 15:31 , dave b wrote: >> On 19 February 2011 01:29, Shawn Milochik <sh...@milochik.com> wrote: >>> By the way -- I realized what happened. You CC'd me on the e-mail to the >&

Re: Just going to point this out ...

On 19 February 2011 01:29, Shawn Milochik wrote: > By the way -- I realized what happened. You CC'd me on the e-mail to the > list. So when I replied it went directly to you. Ah sorry about the mix up then! Yeah :P My view on this is that documentation can always be

Re: Just going to point this out ...

On 19 February 2011 01:19, Shawn Milochik wrote: > Don't take my comment as a personal attack. I was just pointing out that > injection attacks are one of those things we're all responsible for being > aware of and not opening ourselves up to. > > To the extent that Django

Re: Just going to point this out ...

On 19 February 2011 00:57, Shawn Milochik wrote: > I also didn't see the part where they state that you shouldn't put your > database login information in a template. That's probably because Django is > designed to allow Web developers to do their jobs more easily, not allow

Just going to point this out ...

Hi I cannot see where in the django documentation it states that you shouldn't do something like this: ** (as an example of a potential attribute injection vector[0] - where you are not using a URLField or failure to call full_clean (on a URLField) ). That is I cannot see where django states

Re: South - when to start?

On 18 February 2011 21:24, Piotr Zalewa wrote: > Where is the best moment to start with south? > > 1. The very beginning, as the first app added to the project? > 2. At the moment when more devs will be involved? > 3. When real data will start to show? > now! (just start using

Re: potential issue re in memory django file uploading.

Ok no movement :) Lighttpd has a default limit of 2gb, cherokee seems to have the same. Pin it on the httpd all you like - but the default apache has no limit (0 - unlimited :) ). http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody -- The better part of valor is discretion.

Re: potential issue re in memory django file uploading.

> His response is to say he will escalate this to some other security > forum. We can only assume that this is a threat that he will raise > merry hell until we do what he says. Right first: Yes I am sorry for the 9 or so posts :) I am only human. Right. Um no that's not a threat. That's being

Re: potential issue re in memory django file uploading.

On 31 August 2010 12:04, Russell Keith-Magee <russ...@keith-magee.com> wrote: >> On 8/30/2010 9:09 PM, dave b wrote: >>> Do not pass go do not collect profit! > ... >>> Put your hands up in the air like you just don't care! > ... >>> blahblahblalbha sss

Re: potential issue re in memory django file uploading.

> And, for the record, the fact that Ubuntu or Debian have chosen these > defaults doesn't make Apache insecure either. System defaults exist to > make it easy and obvious to get something started. A responsible > sysadmin for a public-facing webserver shouldn't be using *any* > OS-provided

Re: potential issue re in memory django file uploading.

> > From my testing (granted this was run against something pre-1.2 so things > may have changed since then), as soon as you initiate the first file upload, > you're monopolizing the devserver process, preventing further attempts to do > the following 9 uploads until the first has completed

Re: potential issue re in memory django file uploading.

>> Secure by default please! > > That's an easy epithet to throw around, but I disagree that it is > appropriate here. "Security" doesn't mean "stops the user from making > mistakes". Look like wsgi, apache2 and django all on ubuntu PLACE no size limits at all by default. Isn't that neat? I think

Re: potential issue re in memory django file uploading.

/me rolls eyes. You have a valid point re /tmp, sorry I am used to mounting /tmp as /tmpfs - my mistake :) Ok lets be *really* clear the security problem still exists. An attack can in the limits set on the maximum post by the httpd / module in use upload a large file. > I don't actually use

Re: potential issue re in memory django file uploading.

On 30 August 2010 11:04, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sun, Aug 29, 2010 at 8:26 PM, dave b <db.pub.m...@gmail.com> wrote: >  1) An actual problem where you can clearly describe the circumstances > or sequence of events that would allow an atta

Re: potential issue re in memory django file uploading.

> Anyway, since you have done your civic duty there's a good chance that a > fix will find its way into some future version. Thanks for being a good > citizen. Django is an awesome project and. However, a bug is a bug. I don't care if it is a security bug or not, a bug *should* get fixed. FYI: I

Re: potential issue re in memory django file uploading.

> An attacker could also assemble a powerful explosive device and detonate > it near enough your hosting service to take your site down. What > counter-measures are you going to take against that? Good question. I have two cats and they like to lick people ^^ They are a bit friendly I guess. Do

Re: potential issue re in memory django file uploading.

> OK, so you don't believe the advice you are getting, which is that of > the many issues a Django sit will face this is a relatively low > probability attack. That's fair enough - a vulnerability is a > vulnerability, after all, no matter how improbable, and not everyone > will set up their

Re: potential issue re in memory django file uploading.

On 29 August 2010 13:33, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > > > On Aug 29, 1:17 pm, dave b <db.pub.m...@gmail.com> wrote: >> On 29 August 2010 08:28, Steve Holden <holden...@gmail.com> wrote: >> >> > On 8/28/2010 6:10 PM, Graham

Re: potential issue re in memory django file uploading.

On 29 August 2010 13:17, dave b <db.pub.m...@gmail.com> wrote: > On 29 August 2010 08:28, Steve Holden <holden...@gmail.com> wrote: >> On 8/28/2010 6:10 PM, Graham Dumpleton wrote: >>> On Aug 28, 11:21 pm, dave b <db.pub.m...@gmail.com> wrote: >>>>

Re: potential issue re in memory django file uploading.

On 29 August 2010 08:28, Steve Holden <holden...@gmail.com> wrote: > On 8/28/2010 6:10 PM, Graham Dumpleton wrote: >> On Aug 28, 11:21 pm, dave b <db.pub.m...@gmail.com> wrote: >>>>>> So obviously my proposed attack is to simply say "content length is

Re: potential issue re in memory django file uploading.

On 28 August 2010 23:21, dave b <db.pub.m...@gmail.com> wrote: > On 28 August 2010 23:09, dave b <db.pub.m...@gmail.com> wrote: >> On 28 August 2010 22:46, Graham Dumpleton <graham.dumple...@gmail.com> wrote: >>> >>> >>> On Aug 28, 7:58 pm,

Re: potential issue re in memory django file uploading.

On 28 August 2010 23:09, dave b <db.pub.m...@gmail.com> wrote: > On 28 August 2010 22:46, Graham Dumpleton <graham.dumple...@gmail.com> wrote: >> >> >> On Aug 28, 7:58 pm, "david b." <db.pub.m...@gmail.com> wrote: >>> Ok so I was looking

Re: potential issue re in memory django file uploading.

On 28 August 2010 22:46, Graham Dumpleton wrote: > > > On Aug 28, 7:58 pm, "david b." wrote: >> Ok so I was looking through the code and I saw this (in >> django/core/files/uploadhandler.py) : >> >> FileUploadHandler >> ... >> >>    def