Use server-side geoip database

[linkfanel]

Currently the geographical location of the clients is resolved through an external third-party geoip web API call initiated by the client. This has a number of drawbacks.

One of them is performance: load and initialization time of a KiwiSDR is already long, part of it is this extra round-trip between the client and the geoip web API, and then sending back the info to the KiwiSDR. Moreover, if the third-party web API is slow to respond, down, or unreachable from one user's network, the results are suboptimal too.

Others are security. I know this isn't the only call that returns javascript passed to eval(), but this one extends the attack surface to a third-party website and host outside of KiwiSDR's control. It provides additional attack vectors to inject harmful javascript into a client.

Regardless of the web API, the geoip information is still relayed through the client. The client can intercept it and upload any bogus location string instead to the server. In turn this user input gets displayed to all other clients, with unfortunate abuse potential.

There exist geoip solutions that can be downloaded and embedded. The database is a flat local file, it is parsed and queried through a C library API. Lookups are logarithmically fast. The database file could be updated as part of regular KiwiSDR updates. This would be a much better design in my opinion and would just cut short all the issues above. Geoip service providers usually provide both a full-featured paying version, and a partial-precision free version of this. It might be worth looking into it to see if any would be suitable; or even willing to strike a deal (e.g. small "geoip provided by [company name]" caption).

[jks-prv]

Yes, I agree about the security and round-trip overhead problems of doing this in the client. Once again I fall back on my standard excuse that I was in a huge hurry when I did this and just took the first example that I ran across, which happened to be client-based. Now that I have better routines for managing Linux blocking task on the server-side I could move the query there (even if still to a third-party website).

But isn't doing this as an AJAX transaction on the client making it asynchronous w.r.t the client startup time? That's how I always understood AJAX to work.

I've tried to eliminate the "evil eval()s" everywhere I could. That's the motivation for the get/setVarFromString() routines. eval(AJAX response) is the only one remaining. Should be a simple matter to parse the response and enforce it to be a single function call to a known pre-defined function name, which it always currently is I believe.

[linkfanel]

Now that I have better routines for managing Linux blocking task on the server-side I could move the query there (even if still to a third-party website).

Yes, although querying a web API server-side would risk being more conspicuous since it comes from a single IP address, and hitting free usage limitations faster. I think a file-based geoip lookup wouldn't block.

But isn't doing this as an AJAX transaction on the client making it asynchronous w.r.t the client startup time? That's how I always understood AJAX to work.

Ah, yes possibly, I haven't examined the current impact in detail. It probably still counts somewhere, even if it's hopefully minimized by parallelism.