roundcube / roundcubemail

The Roundcube Webmail suite
https://roundcube.net
GNU General Public License v3.0
5.93k stars 1.64k forks source link

Selection all deleting not selected emails #9671

Open hellzapoppin opened 1 month ago

hellzapoppin commented 1 month ago

Prerequisites

Describe the issue

Hi,

this is a very annoying and dangerous issue.

It is the second time this happened this week and my inbox disappeared completely. Sometimes, when you search for a term, select all using the select >> all button and delete the selected emails, the entire inbox is deleted instead of the selected emails. I have lost emails from 4 or 5 years ago... today this happened again... I am unsure if it has anything to do with 2 tabs being used at the same time.

What browser(s) are you seeing the problem on?

No response

What version of PHP are you using?

No response

What version of Roundcube are you using?

last

JavaScript errors

No response

PHP errors

No response

pabzm commented 1 month ago

Sorry this happens to you. I cannot reproduce that behaviour, though. Can you give me a detailed description how this happens?

I suppose using two tabs might be part of the problem, because the search filters make use of the session, which is shared across tabs. But as long as I can't reproduce it, that's just a guess.

alecpl commented 1 week ago
  1. The delete POST request contains _uid="*" and _search=1234567890". You have to have more than one message on the list otherwise _uid will contain the message UID.
  2. In the delete action handler we have then rcmail_action::get_uids(null, null, $multifolder, rcube_utils::INPUT_POST) call. This partially depends on session but is not the main issue here.
  3. Then we call $rcmail->storage->delete_message($uids, $mbox); which uses rcube_storage::parse_uids(). This one depends on the storage object "search state".
  4. The "search state" is being set from rcmail_action_mail_index::run() via $rcmail->storage->set_search_set($_SESSION['search']); call. This happens before the delete handler kicks in.

So, I can see how one tab removed a "search state" from the session, and the other tab when not seeing the data in session falls back to deleting all messages in a folder.

I think the solution will be to bail out if _search is set in the request, but the "search state" does not exist in session.