On 17 Feb 2010, at 14:52, Christopher Lenz wrote:
> On 17.02.2010, at 23:45, Christopher Lenz wrote:
>> Actually I can think of a possible attack vector here. But I'm not sure
>> whether this list is the right place to discuss this stuff. Don't we have a
>> security@ list?
>
> Oh I see you've
On 17.02.2010, at 23:45, Christopher Lenz wrote:
> Actually I can think of a possible attack vector here. But I'm not sure
> whether this list is the right place to discuss this stuff. Don't we have a
> security@ list?
Oh I see you've already alluded to that vector in your original message :P
-
On 17.02.2010, at 21:34, Florian Weimer wrote:
>> thanks for reporting this, but I'm not I understand what's supposed to be
>> going on. Can I ask you to explain in a little more detail what your concerns
>> are?
>
> If you have an open Futon session, any web site you visit can write to
> the Futo
Florian,
Do you have any examples of how other sites have protected against
this? Unless I'm missing something I don't see how this is specific to
Futon so surely someone else has some explicit documentation on how to
avoid such things.
Thanks,
Paul Davis
On Wed, Feb 17, 2010 at 3:34 PM, Florian
* Jan Lehnardt:
> thanks for reporting this, but I'm not I understand what's supposed to be
> going on. Can I ask you to explain in a little more detail what your concerns
> are?
If you have an open Futon session, any web site you visit can write to
the Futon database, provided that the URL to th
On Wed, Feb 17, 2010 at 7:31 PM, Mikeal Rogers wrote:
> The etag is for the entire query, I think he wants to cache on an doc
> by doc basis for all the docs that were returned for the query. But
> this does remind me that you'll still need to check the etag and the
> query again if there are *new
The etag is for the entire query, I think he wants to cache on an doc
by doc basis for all the docs that were returned for the query. But
this does remind me that you'll still need to check the etag and the
query again if there are *new* documents in the query.
-Mikeal
On Wed, Feb 17, 2010 at 10:
On Wed, Feb 17, 2010 at 4:49 PM, Jan Snasel wrote:
> Hello,
>
> You created greate piece of software, indeed. I'm missing only a small
> feature - add "_rev" field for each document in view result. Imagine
> situation when client (javascript application in browser window) is able to
> cache doc
A better way to do that kind of cache invalidation would be to use _changes.
Cache the sequence number along with the objects, then do a new
_changes request with since=seq and then keep it open continuously so
you can use the push notifications to update objects on the page and
in the browser in
> I'm missing only a small feature - add "_rev" field for each document in
> view result.
>
Well, you can do it easily yourself, can't you? Just emit doc._rev in your
view. Or am I missing something in your usecase that prevents it?
LT
Emit the _rev from your map function.
On Wed, Feb 17, 2010 at 07:49, Jan Snasel wrote:
> Hello,
>
> You created greate piece of software, indeed. I'm missing only a small
> feature - add "_rev" field for each document in view result. Imagine
> situation when client (javascript application in br
Hello,
You created greate piece of software, indeed. I'm missing only a small feature
- add "_rev" field for each document in view result. Imagine situation when
client (javascript application in browser window) is able to cache documents.
It recieves some view result, and downloads only docume
12 matches
Mail list logo
