Custom Query (1168 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (46 - 48 of 1168)

Ticket Resolution Summary Owner Reporter
#1049 fixed API Location object should have 'displayName' attribute Jonas Haraldsson
Description

API Location object should have the 'name' attribute renamed to 'displayName'

current: u'location': {u'name': u'Sweden', u'objectType': u'place'}

expected: u'location': {u'displayName': u'Sweden', u'objectType': u'place'}

#27 fixed API Support for Mobile Uploads joar Blaise Alleyne
Description
This might be a bit broad and/or already considered elsewhere, but
having API support to upload media from third-party clients
(especially on mobile computers) would be a killer feature. For
example, on my N900, Maemo has share plugins which support Flickr,
Twitpic, etc., and integrate well into the build in camera
software.

StatusNet implemented the Twitter API to allow for broad support,
but I'm only familiar with Flickr, not so much Picasa or Deviant
Art or other platforms. Would it make sense to implement (parts of)
the Flickr API here to benefit from that same kind of support? Is
there another API to consider? Or does it make more sense to create
something new?

`http://www.flickr.com/services/api/ <http://www.flickr.com/services/api/>`_

The feature request end goal is having some kind of API support for
third-party upload clients, especially on mobile devices. Not sure
if this has been considered, or what the best way to do this is.



#5397 fixed API client registration fails if Content-Type has options Ben Sturmfels
Description

I was just playing with the client registration API and noticed that the following valid request fails. The client I'm using is from the httpie package.

http --form --verbose POST http://127.0.0.1:6543/api/client/register type=client_associate application_type=native
POST /api/client/register HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, compress
Content-Length: 45
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Host: 127.0.0.1:6543
User-Agent: HTTPie/0.8.0

type=client_associate&application_type=native

HTTP/1.0 400 BAD REQUEST
Access-Control-Allow-Headers: Content-Type, X-Requested-With
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Origin: *
Content-Length: 33
Content-Type: application/json
Date: Tue, 19 Jan 2016 12:31:30 GMT
Server: PasteWSGIServer/0.5 Python/2.7.6
Set-Cookie: mediagoblin_csrftoken=12864927827420732302; HttpOnly; Path=
Vary: Cookie

{
    "error": "Unknown Content-Type"
}

It should succeed like this:

HTTP/1.0 200 OK
Access-Control-Allow-Headers: Content-Type, X-Requested-With
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Origin: *
Content-Length: 120
Content-Type: application/json
Date: Tue, 19 Jan 2016 12:32:00 GMT
Server: PasteWSGIServer/0.5 Python/2.7.6
Set-Cookie: mediagoblin_csrftoken=726380659778734454; HttpOnly; Path=
Vary: Cookie

{
    "client_id": "F5lY7pUrmL9ytOjF3RW1md", 
    "client_secret": "yAce42AR3a8SGUSiJDp4GbEaYB8xBQoktNU5ZjlpmWO", 
    "expires_at": 0
}

This looks to be caused by the content-type parsing function not being aware of extra options like Content-Type: application/x-www-form-urlencoded; charset=utf-8, since the simpler case works Content-Type: application/x-www-form-urlencoded.

Attaching a patch including tests for the current code paths plus one with header options.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.