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
Unix timestamps after Sep 13 2020 are rejected as graph start/end arguments #3245
Comments
|
Should now be resolved, thanks! |
|
Thank you for the fix, but you just moved the problem 16 years into the future |
|
I did, well spotted If you're still using this version of the software then, I'd worry |
|
Well, I'd worry, too, but my point is that someone will have to deal with this again in the future before the 16 years, no matter the version |
|
It does, but by then we will hopefully be all on 64-bit so we can then go above the 32-bit barrier :) |
|
@netniV I guess this issue is present in (much) older versions of Cacti. Do you happen to know when it was introduced? I probably need to fix Cacti in the stable and oldstable releases as well as let the Ubuntu people know about it. |
|
This setting goes back to at least 0.8.7. So, anything after that has this clipping boundary to future times. |
Describe the bug
The
graph_startandgraph_endrequest variables ingraph_image.phponly accept values less than1600000000, which isSun Sep 13 12:26:40 2020in UTC (just 7 months from now!).Note: at least
graph_json.php,graph_xport.phpandremote_agent.phpare also affected.To Reproduce
Steps to reproduce the behaviour:
http://host.example.com/cacti/graph_image.php?local_graph_id=123&graph_end=1600000000&disable_cache=true.graph_endvariable.1599999999if you wanna see it working, or just look at my screenshots.Expected behavior
The example URL should display a timespan ranging from
<today>until Sep 13 2020.Screenshots
graph_image.phpusinggraph_end=1599999999graph_image.phpusinggraph_end=1600000000Desktop:
N/A
Smartphone:
N/A
Additional context
Relevant lines of code:
cacti/graph_image.php
Lines 82 to 90 in bb619ef
My suggestion is to compare these timestamps with something like
now + 1 yearinstead of an hard-coded one. I don't mind preparing a pull request to fix this after further discussion about a solution.The text was updated successfully, but these errors were encountered: