Feature - edit server list

[kvlahromei]

Hi, during testing it's pretty annoying to enter the server configs again and again just because you swapped two chars at the api string or URL. It would be nice, if you could edit existing items instead :-)

[milovanderlinden]

I think it might be a good thing to have an option to pull the/a list from "official sources"

Sources

• I found there is a list at: http://wiki.open311.org/GeoReport_v2/servers.json
• Another list is at https://github.com/codeforamerica/open311status/blob/42f3efa7586ea47d235e41b961e9e443fdbab73c/lib/endpoints.json I guess this one is used by http://status.open311.org/
• And then we have the file open311-android/open311-android/res/raw/available_servers.json

Although all 3 files are in json format, they vary slightly in structure. I am thinking about a way to merge the variants into a structure the application can use. This is a small example of a merged config. I will think this over and see if there is a way to implement a method to grab external lists as well as save a config to the available_servers.json

[{
    "name": "Quebec, QC",
    "country": "CDN",
    "api_documentation": "",
    "api_issue_tracker": "https://github.com/open311/open311.github.io/issues?q=is%3Aopen+is%3Aissue+label%3Aville.quebec.qc.ca",
    "api_key_request": "http://donnees.ville.quebec.qc.ca/DemandeCle/form_cleapi.aspx",
    "jurisdiction_id": "ville.quebec.qc.ca",
    "api_discovery": "http://api.ville.quebec.qc.ca/discovery.json",
    "version": "georeport-v2",
    "base_url": "http://api.ville.quebec.qc.ca/open311/v2/",
    "test_url": "http://dev-api.ville.quebec.qc.ca/open311/V2/",
    "production_ready": null,
    "gov_domain": true
  },
  {
    "name": "Brookline",
    "url": "http://spot.brooklinema.gov/open311/v2/",
    "format": "json",
    "supports_media": true,
    "jurisdiction_id": "",
    "api_key": "",
    "splash_image": ""
  }, {
    "name": "Baltimore",
    "url": "http://311.baltimorecity.gov/open311/v2/",
    "format": "json",
    "supports_media": true,
    "jurisdiction_id": "",
    "api_key": "",
    "splash_image": ""
  },
  {
    "bainbridge": {
        "endpoint": "http://seeclickfix.com/bainbridge-island/open311/"
    },
    "bloomington": {
        "endpoint": "https://bloomington.in.gov/crm/open311/v2/"
    }
  }
]

[inghamn]

The sticking point is that the api_keys are supposed to be kept secret. Putting them up on a public webserver seems wrong.

[milovanderlinden]

I agree with that.

[kvlahromei]

How about to inverse the concept? So an App sends (private) Mails to all Open311 providers and asks for adding an specific API-key, which is than equal in all endpoints?

[milovanderlinden]

I like your concept @kvlahromei do you have any more details on how you would implement this and what components are required? Do you think this requires manual intervention at the various providers?

[kvlahromei]

IMHO this just modifies the manual work for the providers + app devs:

• currently: Code App, ask for a secret API key that get's shipped with your dedicated app at every endpoint / provider
• idea: Code App, promote your secret API key via eMail to all endpoints / providers

API keys were never designed to implement strong security (as they are shipped and processed at the devices in plain text). They are just an soft approach for 'access moderation' (rate limit, testing, ...) so IMHO we should deal with them more like HTTP useragents and not like private keys in async crypto :smile:

[inghamn]

This is not, currently an automated process with the Open311 servers that I am aware of. It's been an email conversation with each of the Open311 cities.

We're usually given an api_key that works with a test server, while they review the app. We have to run a few test posts to make sure everything works. It has been about a week-long turnaround to receive a production api_key for each of the cities that we've included in the GeoReporter app so far.

I don't see this process changing anytime soon, from the perspective of the cities offering Open311 endpoints.

[milovanderlinden]

So the solution, (assuming @kvlahromei you have control over the apikey issueing process at the city you are creating the solution for) should be a hybrid. Offering at least automated AND manual issueing of API keys is necessary for backward compatibility.

I would love to hear how you intend to implement the apikey issueing back end. Can you shed some lights on that? I am also looking for it!

[kvlahromei]

@milovanderlinden I guess this is an misunderstanding, as I suggest the API key to be still added manually by the endpoint operrators. BUT using only a unique key per App would allow the apps to become spread very fast, as you skip the long 'handshaking' ("well I like to get a key", "wait"...(days pass) "ok we grant you key XYZ".

If you like to do it manually, you would (IMHO) ignore the API key, but identify the application using HTTP user agent strings instead. Then (again) it's up to the server admins to lock/unlock single applications in advance or on request?