Bug 22448 - No proxy settings provision for Geoclue
Summary: No proxy settings provision for Geoclue
Status: RESOLVED MOVED
Alias: None
Product: GeoClue
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Jussi Kukkonen [inactive]
QA Contact: Geoclue Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-24 00:05 UTC by kr0y
Modified: 2018-05-06 14:36 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kr0y 2009-06-24 00:05:57 UTC
Most of the Geoclue location providers depend on an Internet connection. However if the connection is made via a proxy then there is no particular way to provide the proxy settings to Geoclue. Setting the environment variables like http_proxy etc do not help either.
Hence, it will be really helpful if there is a way to explicitly provide the proxy settings to Geoclue
Comment 1 Bastien Nocera 2009-06-24 02:46:03 UTC
The problem is the use of xmlNanoHTTPInit, which doesn't support proxies. libsoup should be used instead (as done in my patch for the Skyhook provider).
Comment 2 Jussi Kukkonen [inactive] 2010-09-22 02:37:21 UTC
Agreed, although I think Ross's librest suggestion may make most sense. I will try this.
Comment 3 Zeeshan Ali 2013-09-09 14:50:27 UTC
Closing all bugs on old geoclue. If your bug still applies to new geoclue, please do re-open, I really don't have time to go through each and every bug and evaluate separately. :( Apologies for any inconvenience caused by this change.
Comment 4 Bastien Nocera 2014-11-01 01:12:44 UTC
Still applicable I guess, as system services don't use the session proxy settings.
Comment 5 Zeeshan Ali 2015-03-02 18:50:39 UTC
Isn't this more a libsoup bug? We use libsoup all over now for HTTP.
Comment 6 Bastien Nocera 2015-03-02 18:53:20 UTC
(In reply to Zeeshan Ali from comment #5)
> Isn't this more a libsoup bug? We use libsoup all over now for HTTP.

No, not really. You'd still need to carry over user settings from the session to the system. Ask Richard, there's a similar need in PackageKit for example.
Comment 7 Jonas Danielsson 2016-03-22 08:37:42 UTC
From IRC:

<jonasdn> hughsie (or other people): Geoclue... it uses libsoup to query for instance mozilla location service. When you are behind a proxy you expect libsoup to pick up your settings. But Geoclue runs as a system service and not in our user settings. A tip in the bug (https://bugs.freedesktop.org/show_bug.cgi?id=22448) is to ask you if you know how to best carry over these settings from a user to geoclue.

<hughsie> jonasdn, gnome-settings-daemon tries to tell packagekitd the user settings, but it's pretty horrible

<jonasdn> I see, do you think we want a generic kind of way to do these things? Or should geoclue ask for proxy details via dbus api?

<hadess> jonasdn, it's a hard problem
<hadess> proxy settings are per-user

<jonasdn> yeah

<hadess> and geoclue, PK, etc. are system daemon

<zeenix> for now, i'd be content with adding a setting in /etc
<zeenix> /etc/geoclue/geoclue.conf that is

<hadess> might be easier to have g-s-d pass the setting to geoclue, as is done for PK
<hadess> maybe using the same interface
<hadess> not sure whether there are other services that could use the same feature

<ebassi_plr> zeenix: An ancillary configuration file would not help; you'd need a privilege escalation to update the details — and what happens if you have multiple users?

<hadess> zeenix, this is the same problem as allowing the agent only for the current user
<hadess> the one that has the seat, or a seat

<zeenix> hadess: yeah and it's solved, isn't it?

<DimStar> hadess: just for the record: on openSUSE, we rely on libproxy which reads proxy settings for various tools from /etc/sysconfig

<zeenix> hadess: err.. nm :)

<DimStar> (the packagekit solution was done the same: user proxy forwarding is disabled, PK relies on libzypp relies on libproxy to get the right system settings)

<hadess> DimStar, yeah, probably the way we don't want to solve the problem

<zeenix> hadess: i'm actually clueless on how we'd solve that issue but for now we just keep agent per user and that works

<mclasen> it doesn't solve the problem, as far as I can see

<DimStar> hadess: which proxy does a system daemon use on a multi-user setup? good luck in anasering that :)

<zeenix> hadess: so i think we could do the same for proxy

<hadess> DimStar, the one the admin set up

<jonasdn> and runnin geoclue in the user session is out of the question?

<zeenix> yes :)

<DimStar> hadess: erm.. in a user session, the user sets up (an set up) the proxy. That's exactly what we solved with libproxy and the sysconfig module.. now it DOES take the admin configured one in the system context and ignores users proxies

<hadess> DimStar, eg. the user that's marked as the admin
<hadess> DimStar, you're misunderstanding me i think

<DimStar> probably - for me an admin on linux is root

<hadess> DimStar, a user is tagged as an admin
<hadess> we have user roles, that's what we'd use

<DimStar> you can have only one admin?
<DimStar> (agreed: proxies are a mess - they always have - always will)

<hadess> no, you can have multiple, and you'd need to find a way to sync the system and user ones
<hadess> just like for system languages, or system keymaps

<mclasen> zeenix: I think running the network facing parts of geoclue in the user session would be right, in some respects

<zeenix> mclasen: that complicates things quite a lot. Which user? Every user? We end up spamming the network (Mozilla location service) when there are multiple users?

<DimStar> hadess: not exactly: the language set by the user stays in the user context - we never have to pass this on to a system daemon.

[2016-03-01 14:46:25] <mclasen> zeenix: only in active sessions, I guess - there's rarely going to be more than one

<hadess> DimStar, pretty sure we already pass that down

<DimStar> but I trust you will find 'the right' solution. I'm not sure I can add a lot here

<zeenix> mclasen: is there any other advantage than proxy?

<mclasen> you don't have to allow sandboxed apps to talk on the system bus
<mclasen> which seems really suboptimal from a sandboxing perspective

<hadess> mclasen, not every location source is the network

— DimStar thinks the best an admin could do here is a 'local forwarding proxy' - and users all connect to that one
<DimStar> only proxy auth is completely broken in all those setups

<mclasen> hadess: not like we're not handling plenty of physical devices in the session already

<zeenix> mclasen: sandboxing? I thought you were only talking about running the networking bits in user session
<zeenix> mclasen: but now it sounds you are talking about taking the whole thing to sesson

<mclasen> zeenix: I don't foresee apps talking to more than one thing for getting a location
<mclasen> if you have a session service for it, it will be on the hook for merging information it gets from the network with other sources


<zeenix> mclasen: i'm not sure what you mean. So apps will talk to a session-running component of geoclue?

<mclasen> that would be my preferred architecture
<zeenix> mclasen: i actually first put geoclue on session bus and then hadess convinced me that it should remain on system bus
<zeenix> mclasen: so you have to convince him first :)

<mclasen> well, we can just not allow system bus connections for sandboxed apps, and wait for things to sort themselves out :-/
Comment 8 Jonas Danielsson 2016-03-22 09:21:56 UTC
How about making this an Outreachy project?
Comment 9 GitLab Migration User 2018-05-06 14:36:58 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/geoclue/geoclue/issues/54.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.