weixin_39859988
2020-12-02 08:48 阅读 9

Web GUI with gpsd

Hi Martin, after setting up the gpsd daemon, I tried to compose a new position report in the web GUI. Unfortunately it does not take the current position reported by gpsd. Using the command line

pat position
the position report is correctly composed using the current gpsd position.

As I looked briefly through the code (http.go and index.js) I could not find any reference to gpsd or an API call providing the position for the web GUI. I therefore assume, this feature is currently not implemented?

该提问来源于开源项目:la5nta/pat

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

10条回答 默认 最新

  • weixin_39812224 weixin_39812224 2020-12-02 08:48

    Hi,

    you are correct. The Pat web gui position report feature only supports manual entry or browser location (GPS enabled phones works great).

    We would need some sort of API to request a position from GPSd from the client javascript code then. Preferably also add some UI controls so the user can choose which source to use (manual entry, GPSd or browser location).

    点赞 评论 复制链接分享
  • weixin_39637661 weixin_39637661 2020-12-02 08:48

    I was about to jump in and attempt this before I saw PR #146. Is there any reason that PR hasn't moved forward?

    点赞 评论 复制链接分享
  • weixin_39812224 weixin_39812224 2020-12-02 08:48

    Hi!

    Yes, PR #146 needs a proper code review and I've been busy with other work lately (unfortunately).

    Off the top of my head; The patch needs to be updated to be more idiomatic (e.g. return early, use of iota for constants). In addition, it includes some changes that needs to be adressed and possibly improved (like lazy loading, config backward compatibility etc).

    That patch as it stands now, will throw errors and verbose logging if GPSd is unavailable or not enabled IIRC. It also has the possibility to leak GPS coordinates to malicious users over the network since the API endpoint is not protected in any way. All of this needs to be addressed I think.

    • I'm sorry I have not been able to provide a review yet. It's on my TODO list!

    In the meantime, users can either build the PR or use Firefox' GPSd support.

    点赞 评论 复制链接分享
  • weixin_39637661 weixin_39637661 2020-12-02 08:48

    All sounds reasonable, but I do want to discuss this part:

    It also has the possibility to leak GPS coordinates to malicious users over the network since the API endpoint is not protected in any way.

    Is that a concern because GPS coordinates are more sensitive than the rest of the data exposed by the API? As far as I can tell, security needs to be reconsidered throughout the web side of things, and the recent breakage to "Powerful Features" is symptomatic of that fact. Obviously we can't just always slap SSL/TLS on because it would then be illegal to access the frontend through ham network links, but perhaps we could secure it with TLS and a self-signed certificate by default, with the option to turn it off for ham links or localhost. Without going too deep, web security probably deserves a separate issue to itself. Filed #159.

    Having said that, I don't think GPS coordinates are that much more sensitive than the rest of the data exposed in the API. I do think it'd be reasonable to say we won't add the API until we've addressed web security as a whole.

    In the meantime, I'll try out 's existing patch. Thanks!

    点赞 评论 复制链接分享
  • weixin_39637661 weixin_39637661 2020-12-02 08:48

    A couple of comments on #159 suggest there are some reverse-proxy options (Apache HTTP or traefik.io) which solve the encryption/authentication issue. Does that resolve the data sensitivity issue? If so, we can focus on making the patch conform with language and project style as discussed earlier.

    点赞 评论 复制链接分享
  • weixin_39812224 weixin_39812224 2020-12-02 08:48

    Is that a concern because GPS coordinates are more sensitive than the rest of the data exposed by the API?

    Yes, I believe so. All other data exposed by the API are "publicly available" since all messages sent/received over the air are required to be open for public view.

    Further more, when a user chooses to expose Pat on all network interfaces, they are likely to understand that anyone on the network will be able to view their messages. What concerns me the most is that the majority of users will not be aware that this endpoint could be used by an attacker to track the user's position in real time even though the web gui does not appear to expose that data.

    If this gets merged: Find a Raspberry Pi with GPSd and Pat http enabled (for all network interfaces).. and you'll have a very decent GPS tracker.

    A couple of comments on #159 suggest there are some reverse-proxy options (Apache HTTP or traefik.io) which solve the encryption/authentication issue. Does that resolve the data sensitivity issue?

    No, it does not unfortunately. We would need to protect the API with some sort of authentication mechanism. Enabling Basic Auth with Apache or traefik.io will not work, since the JS client would need to know how to authenticate with the API.

    We would also still have to make sure that we don't expose the endpoint on anything other than localhost.

    Don't get me wrong, I would love to see this feature being added. I'm working on a review of PR #146 now, which will provide some suggestions to find a solution.

    In the mean time, users should check out this post on how to enable GPSd as a source for Geolocation in Firefox/Chrome: https://stackoverflow.com/questions/35979965/geolocation-from-gpsd

    点赞 评论 复制链接分享
  • weixin_39859988 weixin_39859988 2020-12-02 08:48

    I'm not sure what your use scenarios are. I can only speak from my point of view: We life on a boat. The boat is equiped with a HF-Radio, a Pactor Modem, a GPS receiver and a little Linux server. The server also provides the WiFi accesspoint to access the internal network. GPSd and Pat are running in separate Docker containers. Pat is accessable through the web interface exposed by nginx reverse proxy on our internal network. Everyone with access to our WiFi can access Pat. For that to happen, he/she has to be within proximity of our WiFi. Our network is NOT accessable from outside (internet). Pat is normaly used to get recente GRIB files or to send a position report to WinLink (where the positions are exposed to the internet, accessable for everyone).

    With the usecase above in mind, I cannot follow your concerns in terms of security. Normally GPSd will run on the same device or at least on the same network, exposing the position to everyone.

    But as I said, this is my usecase. What usecase do you have in mind?

    点赞 评论 复制链接分享
  • weixin_39649736 weixin_39649736 2020-12-02 08:48

    I have the same use case as blockmurder. Used on a sailboat with a private secure wifi network and pat running on a raspberry pi.

    Thanks for your work!

    点赞 评论 复制链接分享
  • weixin_39637661 weixin_39637661 2020-12-02 08:48

    My use case is PiPat; similar to and -axiell, it's normally disconnected from the internet on an isolated WiFi network secured with WPA, or if it's connected at home it's behind NAT and not addressable from outside.

    I would hope anyone exposing Pat on the internet would already be securing it somehow. While the emails are necessarily sent in cleartext on RF at some point, having them accessible on the internet to be queried at any time has a much higher chance of being attacked and abused.

    点赞 评论 复制链接分享
  • weixin_39812224 weixin_39812224 2020-12-02 08:48

    Merged (v0.8.0)

    点赞 评论 复制链接分享

相关推荐