-
Notifications
You must be signed in to change notification settings - Fork 28
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
Too long phpmyadmin version #141
Comments
For this (and below mentioned ones), we can come up with a database migration (involving an ALTER TABLE ALTER COLUMN
Any suggestions welcome. |
The question is whether this is desired or we should enforce some kind of validation. For example (here) the version probably could be sanitized to strip distro suffixes and include only information we really care about (see #102, though it mentioned sanitizing at rendering charts, but maybe it's better to do that earlier). |
Okay. Yes, that sounds good. We can strip the phpMyAdmin versions to just have numeric versions (example regex code at http://ideone.com/pisa9Z) while saving to the database (or should we do the change in phpMyAdmin while sending the error-report itself ?) and maybe while displaying the stats too. But I am really not very sure how to handle the other truncations with respect to Also, I just realized that the the fields |
Changing it at phpMyAdmin side is not really needed, we need to validate the data at the error reporting server anyway, so I think it's best to do the cleanup there. It might be good idea to migrate existing data as well to have consistent data in the database and then no conversion on displaying stats would be needed. As for the other fields, the most errors seem to happen for the |
Fix phpmyadmin#141 Signed-off-by: Deven Bansod <devenbansod.bits@gmail.com>
About the error_message, should we put debug logs before saving the incident to see what type of error messages are creating this truncations? If all these messages are just exceeding the current limit of 100, we can adjust the limit by a bit. Otherwise, we can truncate all error_message content to 100 characters before saving. I think we use |
I think we can start with logging and looking at the problematic reports and then decide what to do with them. So I'd suggest to check length of the field before saving and if that does not fit, log the content and do not save the report. We can then review the logs and see if those reports are valid and worth addressing, they are result of somebody inserting false data or the request is result of bug in client. |
Fix phpmyadmin#141 Signed-off-by: Deven Bansod <devenbansod.bits@gmail.com>
The text was updated successfully, but these errors were encountered: