summaryrefslogtreecommitdiff
path: root/src/portal
Commit message (Collapse)AuthorAgeFilesLines
* portal: Fix initialization orderwip/carlosg/portal-initializationCarlos Garnacho2020-10-041-11/+7
| | | | | | | | | | | | | The portal is currently first claiming the bus name, then adding the portal object+interface. This may break things with autostart as clients are able to send a message to an object path that is not there yet. Changing the order means the object path is there when the DBus name is made known, so clients are able to talk immediately to it. Fixes the error reported at https://github.com/flathub/org.gnome.Music/pull/24#issuecomment-702565846
* portal: Add missing GError in error pathCarlos Garnacho2020-09-301-0/+5
| | | | Otherwise we try to error out, but never really finish the DBus invocation.
* portal: Add testing envvar to override .flatpak-infoCarlos Garnacho2020-09-301-4/+26
| | | | | | This will be used by our functional test suite to test portal workings. Likewise, use this envvar presence to force the use of the Tracker portal in the bus TrackerSparqlConnection.
* build: Link portal specifically with libtracker-commonCarlos Garnacho2020-09-221-1/+1
| | | | We used to get this from tracker_sparql_dep, that will change.
* portal: Allow prefixed names in graph constraintsCarlos Garnacho2020-07-171-3/+5
| | | | | So it is not necessary to use the full IRI in order to specify a graph in a flatpak build specification file.
* portal: Handle default object path in lookupsCarlos Garnacho2020-07-171-1/+17
| | | | | | | | | If the service URI we are asking permissions for has the default object path, ensure we look it up with it being implicitly defined. This allows the following policies to work the same: dbus:org.example.Endpoint=* dbus:org.example.Endpoint:/org/freedesktop/Tracker1/Endpoint=*
* portal: Handle missing .flatpak-info fileCarlos Garnacho2020-07-171-3/+13
| | | | | | | | | | The helper function may return NULL keyfile and no error if the .flatpak-info file does not exist. If that is the case, there is good chance we are talking with a client outside a sandbox. Still be overly restrictive and allow access to an empty set of graphs, the client shouldn't be talking to the portal in that case.
* portal: Add systemd user session unit fileCarlos Garnacho2020-07-173-0/+18
|
* portal: Add CloseSession requestCarlos Garnacho2020-07-171-2/+45
| | | | | | This request takes an object path received through CreateSession, checks ownership from the DBus sender, and explicitly closes a session.
* portal: Add DBus service fileCarlos Garnacho2020-07-172-0/+11
| | | | So the service can be autostarted
* portal: Set up watch on peersCarlos Garnacho2020-07-172-0/+68
| | | | And close sessions when those vanish
* portal: Handle */default keywords in policyCarlos Garnacho2020-07-171-2/+15
| | | | | Those translate to CONSTRAINT GRAPH ALL and CONSTRAINT GRAPH DEFAULT, to let access to all graphs, or the default unnamed graph specifically.
* portal: Implement filtering endpointCarlos Garnacho2020-07-174-6/+313
| | | | | | | | | | | | | | This endpoint is a private subclass that manipulates communication so 1) session endpoints can only be used by their original creator 2) all update queries are forbidden 3) GraphUpdated filters down events on disallowed graphs 4) Queries are prepended CONSTRAINT clauses This makes sandboxed endpoints restricted so: - Updates cannot happen - Graphs/Services in queries get filtered down - GraphUpdated signals avoid filtered down graphs
* portal: Add XDG portal implementationCarlos Garnacho2020-07-176-0/+705
View Lorry Controller Status