The goal is to restrict the amount of data being transferred from server in the client (or vice versa - out) through clipboard copy/paste operation.
Two options specifying the max size
In addition, notify the client when the data is truncated.
Please attach the patch.
attached the patch
improved patch
The updated patch changes:
@calvinko: this modifies a private clipboard method, please include the changes that call it.
patch with control command to set the size limits
The update patch - clipboard-size-v2.patch
OK, some minor changes are still needed:
max_send_size
and max_receive_size
in set_direction
and check for None in set_limits
- then you can just do xpra control :100 clipboard-limits -1 -1
> 3 > "1" False
with python3 you probably get an error in the clipboard code on every request (which may be worse as this is known to cause GTK to hang)
control_command_clipboard_limits
, you alias the clipboard helper to a local variable (good), but then you don't use it
setting_changed
method takes native values, not strings, either send a pair of values or a dictionary
address the minor changes stated in comment:5
As per comment:5:
use None default values for max_send_size and max_receive_size in set_direction
Otherwise regular clipboard clients, which call set_direction
without the extra arguments will end up removing the size restrictions.
IMO max_send
in setting_changed
is redundant and should be called send
address comment:6
Did you test this? Ideally this feature should be added to the unit tests.
I found at least two major problems during my quick testing:
2018-12-11 13:56:49,818 Data copied out truncated because of clipboard policy 1 to -1
And this ends up truncating all clipboard packets by 1 character.
How I tested:
xpra start :100
$ xpra info | grep clipboard | grep max_ clipboard.max_recv_size=-1 clipboard.max_send_size=-1 clipboard.max_size=4194304
$ xpra control :13 clipboard-limits 8 8 clipboard send limit set to 8, recv limit set to 8 (single copy/paste)
$ xpra info | grep clipboard | grep max_ clipboard.max_recv_size=8 clipboard.max_send_size=8 clipboard.max_size=4194304
XPRA_MAX_CLIPBOARD_RECEIVE_SIZE=10 XPRA_MAX_CLIPBOARD_SEND_SIZE=10 xpra start
$ xpra info | grep clipboard | grep max_ clipboard.max_recv_size=10 clipboard.max_send_size=10 clipboard.max_size=4194304
Then check that the client does receive a truncated string:
echo hello12345 | xclip -i -selection CLIPBOARD
xclip -o -selection CLIPBOARD
Then the other way (client to server) - preferably after changing the limits to ensure that send and receive limits are used the right way around. Also worth testing: client limits via env vars.
r21202 fixes a long standing bug that is uncovered by the extra "truncated" >attribute in the "clipboard-contents" packets - do you really need this? (it will create backwards compatibility issues with older versions - as some users just don't update as often as they should..)
You are right. I am actually thinking to add a clipboard-content-truncated message instead of changing the clipboard-content packets. All I need is to notify the client in some way. What do you think?
I have not test the code since I don't have an environment set up to test xpra. Lets ask Max to help testing.
I am actually thinking to add a clipboard-content-truncated message instead of changing the clipboard-content packets. All I need is to notify the client in some way. What do you think?
If you need to notify the client, then I would rather not add a new packet type.
We can workaround older clients by adding a new capability flag in the hello packet - something like clipboard-contents-slice-fix=true
.
address comment:10
clipboard-size-v5.patch
Max, see comment:7 for testing.
Merged in r21213 with the following changes:
get_format_size
function to ensure we return the correct size for the given data format (because CARD32
can actually be 64-bit...)
clipboard.contents-slice-fix
, capabilities are False
by default
set_clipboard_contents_slice_fix
from both too
Backports:
Fired up a trunk r21225 server, and followed the steps for using the control channel - primarily xpra control :DISPLAY clipboard-limits 8 8
and it broke the server side clipboard. I could copy text from my client into the server clipboard, but could not copy anything on the server. If I did, the clipboard would be empty, and I couldn't paste anything client side.
I ran a session with -d clipboard
demonstrating what I saw. My repro steps are pretty easy:
xfce4-terminal
or some terminal emulator with a Copy/Paste? menu
xpra control :DISPLAY clipboard-limits 8 8
I tried that on three different sessions, and it failed each time. I'll work on using the Environment variables and using xclip
.
I tried that on three different sessions, and it failed each time.
Failed how? Wrong data? No data? Do you have logs?
Requested logs.
When I copy from the client to server, I get as much text as I should within the limits - 8 characters. But when I highlight text on the server, copy it, and then paste it client-side, there's no data.
I just installed xclip
, and I restarted my server and now it's working?
I just installed xclip, and I restarted my server and now it's working?
What steps? The ones from comment:7 do use xclip so it should not come as a surprise that you need to have it installed.
Always test with the most basic tools, like xclip. Do not trust applications to do the right thing with the clipboard.
Noted.
Both the control channel and the environment variables work with xclip
, so as far as I can tell there isn't anything else to do.
I'm gonna go ahead and close this, unless there's any follow-ups.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2072