Evaluating current state of menshen

Let's check the current state of menshen, think about what we need, and design and implement it properly before using it in production and integrating the client library (bitmask-core). As what I just obsererved:

• /openvpn/config (docs: fetch a working config file for OpenVPN service)

  • seems to work - returns an openvpn config (as text, not json) with client certificate+key

• /openvpn/cert (docs: fetch a working certificate for OpenVPN service)

  • seems to work, returns cert+key as text
  • do we need it if we have /openvpn/config?

• /autoconf (docs: fetch a working config file for OpenVPN service.)

  • seems like it's not implemented: returns a 404 (haven't checked the code)

• /Service

  • returns locations and openvpn_configuration
  • a location has a filed region": "" - always empty
  • proposal: rename it to /locations and remove the vpn stuff (openvpn_configuration)
  • do we need the vpn stuff or do we need an additional endpoint?

• /gateways (docs: Fetch all gateways. This is an optional API endpoint for compatibility with vpnweb, but do not count on all the providers - to have it enabled since it makes it easier to enumerate resources. On the other hand, if the service has "open" VPN endpoints, they can enumerate them here freely. Bridges, however, should be more restricted as a general rule.)

  • seems to work
  • filtering by location: works if I specify miami/paris, filtering for 'blubb' returns all locations
  • same for port filtering: I get all gateways running on port 80, asking for port 1234 I get all gateways returend
  • filtering for country code seems not to work
  • filtering for tcp/udp: works but with the same behaviour in case of an error: inputting 'bla' returns all gateways
  • Each returend gateway has a field "healthy": true - Can we just not return this gateway to the user if it's broken?
  • I'm also interested in how we want to use "load": 0 and "overloaded": false
  • returns a single port instead of a list - see discussion in #30

• /gateway/{location} (docs: fetch random gateways for a given location)

  • requires a location id - I do not now what a location id is => if I supply 123, I get just null (json in case of an error would be nice)
  • if I use paris, I just get gateways sitting in paris. Questions:
    • the order is always the same. Is it a bug or just because it uses the load it's on purpuse (haven't checked the code)
    • can we remove this endpoint and use /gateways instead with the parameter location and order the elements we want

• /bridges (docs: Fetch all bridges. This is an optional API endpoint for compatibility with vpnweb, but do not count on all the providers to have it enabled since it makes it easier to enumerate resources. On the other hand, if the service has "open" VPN endpoints, they can enumerate them here freely. Bridges, however, should be more restricted as a general rule.)

  • seems to work (also has a "healthy": true field)
  • transport filtering (tcp/udp) does not work
  • location filtering works
  • no option to filter for countryBase (fr for France)

• /bridge/{location} (docs: fetch bridges by location)

  • there is no ramdon in the doc - purpose?
  • same like `/gateway/{location}

Also,

• What is meant by compatibility with vpnweb and do we still need it?
• TODO: Also I don't know if/what authentication is implemented (check code, what is required)

Also please keep Technical Diagrams.pdf page 7/7 in mind (our plan).

• There, we are using the endpoints /Service and /openvpn/cert. Why not /openvpn/config?

I'm happy to hear your feedback @cyberta @maxb @mcnair (I'm not able to tag anj and sgk)