Re: Query Refactor Update
What would the ListField Look like? On Jul 16, 8:06 pm, Alex Gaynor wrote: > Hey all, > > The last while has been spent continuing the fight to make aggregates > work correctly, Russ provided some good insight that's gotten me > farther on it. All that code is in my query-refactor-aggregates > branch on github, as it's not fully working ATM. This week I also > pushed a few updates to SVN, including support for F() expressions in > updates, and another small fix for bulk updates. > > My goals for next week are to continue the aggregates work (maybe even > finish it!), as well as to clean up the errors for trying to use > impossible features, right now they're a bunch of asserts, but ideally > they should be clean, expressive error messages as. I'm also going to > work on getting a ListField implemented, in principle the > storage/retreival of one shouldn't' be too bad, however MongoDB also > supports querying on them (as one might across a foreign key > relationship in a relational database), and I imagine some refactoring > will be necessary there. > > Since this is about the halfway point of GSOC I'll give a general > overview: we have a working MongoDB backend, with many implemented > features, and a set of changes to Django itself (that don't break > anything else of course) that enable this. Diligent readers will > recall that originally a backend was the goal for the 2nd half of > GSOC, with the first half being allocated to internal refactors. > Seeing as how the backend is nearing completion the 2nd half will be > targeted at these refactors, starting wiht the aggregation stuff I've > been working on. > > Thoughts, questions, flames, nobel prizes nominations welcome, > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: request.is_ajax() and hidden iframe kludge => request.is_framejax()?
I think Florian meant that its not possible to change HTTP headers by Javascript XSS attacks (or am I wrong here as well?). Athor attacks that doesn't use a browser as their client can ofcourse manipulate what is_ajax() returns. To the actual proposal: I have the same opinion here as Florian. It's an workaround for an edgecase that isn't defined in a standard. The best way - if you really need it - to have it, is to implement the method your self and inject it to the request object in a middleware. -- Servus, Gregor Müllegger 2010/7/17 David : >> This input field is easily fakeable. An attacker can't fake your >> browsers XHR requests, which makes request.is_ajax somewhat secure and >> trustable. I don't see how your solution could achieve that. > > is_ajax() simply checks an HTTP header. It is easily set by an > attacker. > > On Jul 16, 2:30 pm, Florian Apolloner wrote: >> Hi, >> >> On Jul 16, 7:25 pm, David De La Harpe Golden >> >> wrote: >> > People doing ajax have probably hit the "XMLHttpRequest doesn't do file >> > uploads (at least not non-browser-specifically), use a hidden iframe >> > kludge or flash" issue. Anyway, maybe that will change one day >> >> It's already changing, modern browsers can do what you want (google >> for html5 file uploads). I don't see any reason to support something >> like you suggest; we should support standards and not workarounds >> (just my opinion). Imo the best way currently is to use the new apis >> and fallback to flash or whatever if needed (I actually guess flash is >> the best fallback here). >> >> > The hidden-iframe requests will AFAIK show up with request.is_ajax() == >> > False to django. So a "done thing" (I think) to distinguish between the >> > non-ajax and hidden-iframe requests seems to be to just have an extra >> > field to act as a pseudo-header, i.e. >> >> > >> >> This input field is easily fakeable. An attacker can't fake your >> browsers XHR requests, which makes request.is_ajax somewhat secure and >> trustable. I don't see how your solution could achieve that. >> >> > or "?X-Requested-With=ScriptedIFrame" >> >> Same as above. >> >> > It might nonetheless be nice for django to have some support for >> > checking for some particular pseudo-header. >> >> -1, mostly due to the fact that it's something most people won't need >> and you can easily inject that info using a middleware yourself. Hence >> I am for solution A. >> >> Cheers, >> Florian > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Patch: Indefinite args for simpletags and inclusion tags
Hi, a quick +1 from me - the patch doesn't seem to introduce backwards-compatibility issues or implement a YAGNI feature - since there is already a usecase. Only documentation and tests are missing. -- Servus, Gregor Müllegger 2010/7/16 Stephen Burrows : > I went ahead and made a ticket with the patch. Thanks! > http://code.djangoproject.com/ticket/13956 > > --Stephen > > On Jul 16, 1:25 pm, Tobias McNulty wrote: >> On Fri, Jul 16, 2010 at 1:07 PM, Stephen Burrows < >> >> stephen.r.burr...@gmail.com> wrote: >> > Before posting the patch to django's ticketing system, I wanted to >> > check whether this would be a non-trivial patch and whether there >> > might be any good alternatives. >> >> Hard to tell without seeing the patch. :-) >> >> Could you stick it somewhere we can see it? Personally I like to see them >> in Trac, since it comes with pretty colors. If there isn't a ticket already >> out there for this I see no problem with creating one. We can always close >> it if it gets rejected. >> >> Cheers >> Tobias >> -- >> Tobias McNulty >> Caktus Consulting Group, LLC >> P.O. Box 1454 >> Carrboro, NC 27510 >> USA: +1 (919) 951-0052http://www.caktusgroup.com > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: proposal: abstract file upload/download handling
Hi Russell,
so, after our chat on IRC I've finally found the time to implement a
real proposal including unit tests. I've attached the patch to this
ticket:
http://code.djangoproject.com/ticket/13960
Now there is just one backend type with a single setting:
FILE_BACKENDS = (
'path.to.Backend',
'path.to.Backend2',
)
The end-user will normally use the API via ModelForm like this when uploading:
form = MyModelForm()
form.prepare_upload(request)
By default, prepare_upload() will prepare an upload to the current URL
(and thus current view). Optionally, you can specify a different url
via form.prepare_upload(request, url='/other/url').
The prepare_upload function is necessary because we need to support
services which first send the file and form data to a different URL
(e.g., to S3 or '/_ah/upload/...' on GAE). Once the upload is
finished, the service or backend is responsible for sending a request
to the actual target URL (some Django view).
So, in the template you have to use the generated upload url:
{{ form }}
FYI, behind the scenes prepare_upload() might also add hidden input
fields to your form, depending on the service you're using.
--
Downloads are split into two functions which both exist on the file
object returned by FileField.
With file.serve(request) which returns an HttpResponse you can handle
the file download from a Django view. This also allows app developers
to check permissions in the view before calling file.serve(request).
Additionally, there's file.download_url() which deprecates file.url
(because that uses the storage backend which is the wrong place for
this feature). This function will always return an URL. If none of
your backends provides an URL we use "MEDIA_URL + file.name" as a
fallback.
In some cases file.download_url() will point to a Django view which
calls file.serve(request) (and which can do some permission checks if
necessary). Authors of reusable Django apps are responsible for
providing a default backend which generates the URL to their app's
built-in download view. End-users can overrides this.
In your templates you'd always use code like this:
Download
Backends
Every backend derives from BaseFileBackend. Every backend instance has
these members:
* self.model: the model that own the FileFields to upload to or download from
* self.fields: the list of FileField instances to upload to or
download from (in case of a download there is just one entry)
For convenience, there is also self.field which makes sure that there
is just one field in self.fields and returns that field.
Every backend can override the functions mentioned above
(prepare_upload, file.serve, file.download_url). You can take a look
at the source for more details. FYI, the prepare_upload() function is
pretty much the same as before, just without the private=True/False
parameter.
Additionally, backends can define get_storage_backend() which returns
a storage backend for the given model/field combination. As a fallback
DEFAULT_STORAGE_BACKEND is used.
The API is also similar to DB routers. If any of those functions
returns None the next backend is tried (as defined in
settings.FILE_BACKENDS).
Please provide some feedback. Does this solve all issues you had with the API?
Bye,
Waldemar Kornewald
On Mon, Jun 28, 2010 at 2:08 PM, Russell Keith-Magee
wrote:
> Apologies for the late reply - I was at a conference all weekend, so
> I'm still catching up on mail.
>
> On Thu, Jun 24, 2010 at 12:24 AM, Waldemar Kornewald
> wrote:
>> On Wed, Jun 23, 2010 at 2:58 AM, Russell Keith-Magee
>> wrote:
>>> On Wed, Jun 23, 2010 at 2:58 AM, Waldemar Kornewald
>>> wrote:
On Tue, Jun 22, 2010 at 2:40 PM, Russell Keith-Magee
wrote:
> On Tue, Jun 22, 2010 at 2:55 PM, Waldemar Kornewald
> wrote:
> It also strikes me that a lot of this is being configured at the
> global level -- i.e., you have to nominate that your public upload
> backend will be S3, rather than nominating that a specific file field
> will be backed by S3.
I'm repeating myself here, but anyway: The primary purpose of this API
is to allow for writing reusable Django apps that automatically work
with your project's file handling solution(s) without hard-coding
anything. This requires that you specify the upload/download backends
separately from FileField (otherwise it's hard-coded and not reusable)
and instead provide a mechanism for detecting which backend should be
chosen for the current request. Of course, this mechanism could take
the FileField into account.
>>>
>>> You may feel that you're repeating yourself, but this point certainly
>>> wasn't clear to me from your previous two posts.
>>>
>>> Making it possible to configure the file handling strategy of a
>>> reusable app is certainly a reasonable feature request. However:
>>>
>>> 1) Again, the file storage strategy isn't something that is constant
>>> across a deployment. I may wa
