On 2016-11-04 14:35, Stephen Finucane wrote:
On 2016-11-01 06:07, Daniel Axtens wrote:
2) Can you elaborate on how you plan to expose this data? ie
something
via REST?
I've been thinking an '/events' API endpoint for now. This would
require
polling from CIs etc., but it would be a good first step.
Makes sense to me. If we had a /events?created_on__gte=TIMESTAMP, the
API could be used fairly efficiently.
?since= would be much nicer, but that's a minor quibble.
I agree - 'since' and 'until' are what I generally expect. On that
note, we still have to do REST API filtering :O
Some random, related thoughts:
Does DRF support rate limiting? As we grow a bigger API we might want
to
consider that.
To the best of my knowledge it does, though I don't know if this is
something one would do at the application layer. Rate limiting really
seems like something a lower level component, such as nginx itself or
HAProxy, would be suited for. If we're going to start making full use
of the DRF functionality, supporting some form of caching (read:
ETags) would return far better ROI, IMO.
Thinking of rate limiting - do we have it for the login page? Should
we
add it to avoid brute forcing of credentials?
We don't, nor do I know if we care about it. Patchwork would appear to
be a very low value target, seeing as it has no direct repo or mailing
list access. However, it looks like there are packages available [1]
to handle this, however, if sysadmins cared enough. Maybe someone
should document this.
What are your thoughts on the overall idea. This would, out of
curiosity, be something you or Andy would fancy running with, would
it? :)
+ missing link
[1] https://pypi.python.org/pypi/django-axes/
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
