Problems with cut/copy&paste

Hi, just investigating problems with copy/cut & paste functionality and I think it is due to browser cookie restrictions ... I've read that the maximum size for cookies in most browser is 4092 bytes per cookie (some browsers even 4092 bytes per domain).

Now if you want to copy 20 items and the IDs of them are (do not ask why) insanely long, setting the __cp cookie in plone.app.content.browser.contents.copy does not work anymore ... it fails silently and doesn't set any cookie. So if you want to paste the copied items somewhere, the actionbutton in structure pattern simply ignores your click, because it checks the existance of __cp cookie.

And it can get even worse as in our case: If your customer successfully moved an item from one place to another, the __cp cookie of that action doesn't get removed on success. Now if he afterwards wants to move or copy "too much items" somewhere else he doesn't notices that it didn't work because the action silently fails. BUT if he now clicks the paste action in the target context, it reads your old cookie contents and fails, because the item isn't there anymore ... whoooha ...

Has anybody an idea how to make these actions work with a cut/copy clipboard data bigger than 4092 bytes?

cheers :beer:

So this would do the trick and fixes my issues:

lets discuss it!

There might be a better solution for this. See issue https://github.com/zopefoundation/Zope/issues/854 and the commit from today: https://github.com/zopefoundation/Zope/commit/6d486cad617e9c5630234f71c59348505c07a269

@petschki I think the first one looks good - and could well also solve an issue we have found where a WAF is blocking the __cp cookie.

Nothing in plone uses Request.SESSION and for a good reason. As soon as you have ZEO setup it is likely to break unless you have a special setup to deal with that (sticky cookies, shared sessions using plugins etc). I think requiring sessions to be handled correctly for any install of Plone would be too much of a breaking change.

Can't you change it to use content UIDs instead? or local storage (with a progressive enhancement backdown of going back to cookies).

It is quite simple to store the session data in a ZEO managed storage (rather than the typical RAM based tempstorage). Python's CSRF protection, however, recognizes sessions as
objects from a temporary storage. Therefore, it is important to use this as name of the session storage.

You're right ... dealing with sessions needs a bit more effort.
I really like the idea of storing UIDs to the cookie. Localstorage would be nice too, but thats up to the frontend isn't it? or can you store data to localstorage via REQUEST?