View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000665 | XMB1 | Bugs | public | 2021-06-15 00:29 | 2024-04-24 15:22 |
Reporter | lottos | Assigned To | |||
Priority | low | Severity | tweak | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Product Version | 1.9.8 SP2 | ||||
Summary | 0000665: u2u subject is truncated where it exceeds the u2u table subject column setting | ||||
Description | u2u table, subject column If subject exceeds table subject setting when sending a u2u, MySQL generates a warning [when debug is on]: 'Message' => 'Data truncated for column \'subject\' at row 1', Perhaps the code from post.php for handling where subject is > table subject setting field length could be repurposed/recycled into u2u code. | ||||
Steps To Reproduce | Send a u2u with a subject in excess of the table subject setting. | ||||
Tags | No tags attached. | ||||
MySQL Version | |||||
PHP Version | 7.4 | ||||
Web Server | Apache | ||||
Browser | |||||
Flags | |||||
Original Reporter | |||||
SVN Revision | |||||
Git Commit | |||||
|
I'm wondering if this could potentially cause PMs to fail to send without any "notice" to the user depending on the DB's configuration, come to think about it. This could actually be more of an issue than it looks to be at the moment given the lack of proper error handling. |
|
Yep, just checked and if strict mode is turned on (which is actually the default ever since MySQL 5.7/8.0+ and MariaDB 10.2+ I believe), you'd instead get a "data too long" error and the U2U would fail to send. Running debug mode on production and exposing errors to users is also... less than ideal, too. |
|
There are a bunch of different issues here. Mainly, XMB needs stronger input validation. This problem applies to every database field that accepts user input. They can all throw the same warnings and errors. The MySQL server we are using here does not have strict mode enabled. It can be switched at runtime for testing, but I don't think it's a huge issue. The error handling was already addressed in 0000685. Patching the U2U subject and body fields might be adequate for now, but I think this issue should be examined more before doing that. |
|
With strict mode enabled it just outputs a data too long error (if I'm remembering right) in debug mode, or silently fails in non-debug mode. Tbh the fact the software even holds up so well DB-compatibility aside from a rather minor issue is actually really impressive, I've seen more active projects that would break entirely when STRICT_TRANS_TABLES was made default mode in MySQL 5.7/MariaDB 10.2 |
|
Correction. It truncates the subject even in strict mode. However, the limit being so liberal also allows you to do stuff like this, which isn't particularly ideal especially on mobile devices. |
|
That screenshot is off topic. We already have input validation for that one. |
|
Best examples are the AIM field (40 chars) and the bday field (10 chars). For some reason it's still possible to input a year greater than 9999. We only filter years less than 1900. |
|
I mean, the AIM field can be axed at this point, given AIM is dead. Fair enough, though. |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-06-15 00:29 | lottos | New Issue | |
2024-04-05 21:36 | flushedpancake | Note Added: 0000451 | |
2024-04-05 21:40 | flushedpancake | Note Added: 0000452 | |
2024-04-20 17:13 | miqrogroove | Status | new => acknowledged |
2024-04-20 17:13 | miqrogroove | Category | New Features => Bugs |
2024-04-20 17:13 | miqrogroove | Product Version | 1.9.11.15 => 1.9.8 SP2 |
2024-04-20 17:13 | miqrogroove | Note Added: 0000492 | |
2024-04-21 22:00 | flushedpancake | Note Added: 0000496 | |
2024-04-21 22:11 | flushedpancake | Note Added: 0000497 | |
2024-04-21 22:11 | flushedpancake | File Added: oh god.png | |
2024-04-24 08:53 | miqrogroove | Note Added: 0000507 | |
2024-04-24 09:04 | miqrogroove | Note Added: 0000508 | |
2024-04-24 15:22 | flushedpancake | Note Added: 0000509 |