Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input Capture Requested dialog needs to be clicked after every restart #1979

Open
mistyron opened this issue Oct 1, 2024 · 6 comments
Open

Comments

@mistyron
Copy link

mistyron commented Oct 1, 2024

What happened?

I want to start Input Leap (server) on Login and I want that clients can connect to it right away but that sdoesn't work. Instead I have to open the Input Leap dialog, click reload upon which the diaklog "Input Capture Requested" shows up and I need to swelect Allow every time. Is there a way that I can start Input Leap with a flag so taht it automatically allows connection? It would be the same thing on the client side as well.

Version

v2.4.0

Git commit hash (if applicable)

No response

If applicable, where did you install Input Leap from?

Fedora Repositories

What OSes are you seeing the problem on? (Check all that apply)

Linux

If applicable, are you using Wayland or X11?

Wayland

What OS versions are you using?

Fedora Linux 40

Relevant log output

No response

Any other information

No response

@mistyron mistyron changed the title Input Capture Requested dialog needs to be clicked afgter every restart Input Capture Requested dialog needs to be clicked after every restart Oct 1, 2024
@nbolton
Copy link
Contributor

nbolton commented Oct 1, 2024

Yeah the permission dialog is pretty annoying. I plan to do something about this. Not sure what is possible yet.

@whot Any ideas?

@sithlord48
Copy link
Contributor

sithlord48 commented Oct 2, 2024

I would suspect this is going to be a issue that has to be fixed within the xdg-desktop-portal backend .

@whot
Copy link
Contributor

whot commented Oct 2, 2024

flatpak/xdg-desktop-portal#1186 - needs to be implemented in the compositors though which is where I got stuck due to ETIME

@shymega
Copy link
Member

shymega commented Oct 2, 2024

I discussed this with @nbolton over a call.

My vision would be the following flow:

  • Software (let's say Input Leap) starts up.
  • Software verifies the SSL fingerprint of screen(/s) and stores the fingerprint.
  • The portal bus interface is requested. The user is presented with an 'Always trust this session' checkbox, which is then stored with the portal.
  • If the user checks this box, the portal will continue the flow as it does currently but inform the portal caller of the 'Trust' checkbox for future use.

Now, let's say, the user starts up Input Leap again. We go through the flow again, but in this case, the user has checked the 'Always trust' checkbox previously.

We then verify the SSL fingerprint has not changed. If it has, we should ask the user for permission again, and continue the flow, as described above.

In an alternate scenario, the SSL fingerprint hasn't changed, and the user has checked the 'Always trust' checkbox before. We don't want to ask the user again for permission because they have indicated they trust the connection. This would be bad UI/UX design.

In this case, the portal knows the user is OK with the connection, and the SSL fingerprint is valid. Input Leap then continues the connection sequence, and we're running.

The only problem with this is when SSL is disabled. We should think about this.

I'd welcome any thoughts on the flow that I described to Nick over our call.

@whot
Copy link
Contributor

whot commented Oct 3, 2024

A note here: the portal has a permission store so this is the first point to look at. Once that's added for the RD and IC portals the popups should go away altogether. Adding it shouldn't be that hard (technically).

Mind you, the SSL check does not need to/should not be in the portal interaction - that one is for local permissions only with the idea that if the user says "input-leap is fine" then it can always connect. The SSL verification for remote servers/clients should then happen in input-leap and rejected there.

@sithlord48
Copy link
Contributor

This is an upstream bug and we have this tracked in our Wayland Discussion #1976

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants