View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004143 | GNUnet | other | public | 2016-01-23 14:30 | 2018-06-07 00:24 |
| Reporter | lynX | Assigned To | lynX | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
| Summary | 0004143: mantis timeouts edit sessions and deletes work done | ||||
| Description | We've discussed it in https://gnunet.org/bugs/view.php?id=3896 – I wrote three paragraphs with useful information but Mantis told me my session has expired and when I went back in the browser it even deleted the input form. Ironically Mantis still considers me logged in, so it apparently isn't a cookie problem as discussed on https://www.mantisbt.org/bugs/view.php?id=11680 since I got timeouted in certainly less than an hour. http://tracker.dev.opencascade.org/view.php?id=24039 describes this scenario: > With PHP default values, sessions created more than 1440 seconds (24 minutes) > ago have a 1% chance to be invalidated each time a new session is initialized. > This explains the seemingly random occurence of this error. > Unfortunately, this problem cannot be fixed without a major rework of the way > sessions and form security are handled in MantisBT. > As a workaround, the Administrator can > - Increase the value of session.gc_maxlifetime > - Set $g_form_security_validation = OFF. Note that for security reasons, it is strongly recommended not to do this. > - Users may also install local tools to avoid loss of form data, e.g. Lazarus Form Recovery add-on for Firefox. Unfortunately not all of my browser instances already have Lazarus installed. The administrator from opencascade.org then wrote a patch that makes the browser re-login with a dirty javascript hack. This is not helpful for people like us who do not permit Javascript execution - also it is an indication that you have not understood WWW programming. I decided to look at the Mantis source.. found it to be in a zip on sourceforge. How could you install a software that was obviously developed by Windows people in the first place? trac seems a much more saner choice for a bugtracker to me! Anyway, it took me one grep to find the culprit of the problem. meta_inc.php reads like this: <meta http-equiv="Pragma" content="no-cache" /> <meta http-equiv="Cache-Control" content="no-cache" /> <meta http-equiv="Pragma-directive" content="no-cache" /> <meta http-equiv="Cache-Directive" content="no-cache" /> <?php } # ! isset( $g_allow_browser_cache ) ?> <meta http-equiv="Expires" content="<?php echo gmdate( 'D, d M Y H:i:s \G\M\T', time() ) ?>" /> So the input form is emptied because they explicitly tell the browser to empty it. This is a bad programming habit that goes back to around 1995. Instead of working with the caching logic of the browsers, web developers force full trust in the server to be available and doing the right thing. I would attempt to kick out those lines, but we might then run into other problems where the developers have coded "dirty" and the stuff only works if the browser acts stupid. Interestingly for some operations they have added a $g_allow_browser_cache flag whereby the cache is not inhibited. The following edit may solve our problem at least in the sense that we can go back in the browser, reload and resubmit our contribution: Edit view.php and add the line "$g_allow_browser_cache = 1;" before the include. Just a guess from a former web developer. | ||||
| Tags | No tags attached. | ||||
|
|
Ok, bonus problem for you, Lynx: Any idea how to get this into an unmaintained Debian package from 'oldstable'? |
|
|
Just edit the php file, it's not a binary. And disallow upgrades. :D |
|
|
Christian wrote in 0003896: > most other systems are also crap, and then there is the question of how to migrate the info that is in Mantis right now... I looked around a bit as well, and indeed, most web-based issue trackers out there suck on various levels.. There were a few attempts to make distributed issue trackers, but most of these are abandonware.. Perhaps the least bad choice would be bugzilla, since it is still actively developed and has quite a large user base, and there are a few non-web tools to interact with it: - http://www.liquidx.net/pybugz - http://www.jemarch.net/hacks/bugz-mode As for migration there's an old tool that probably doesn't work anymore: http://www.mehnle.net/software/m2bz There's also gitlab which has an issue tracker, but its issue filtering capability is still lacking: https://gitlab.com/gitlab-org/gitlab-ce/issues/989 PS: just got an invalid security token error after taking too long to edit this, but using the back button I still have what I wrote in the textarea, except now the Add Note button is disabled and can only submit this by opening a new tab and copy-pasting the content.. |
|
|
I am getting security token crap because I access this via Tor, so my exit node changes occasionally. What about trac? It allows the user to write her own SQL filter statement which is surprisingly easy and effective to tune the output to exactly what one needs... |
|
|
I've set "$g_allow_browser_cache = 1;" globally now via the configuration file. Let me know if this fixes it. |
|
|
I just experienced a timeout again, had to go back and reload. The dropdown selections are lost, the rest of the form elements stay. So I would say we can accept this solution. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-01-23 14:30 | lynX | New Issue | |
| 2016-01-23 14:50 | Christian Grothoff | Note Added: 0010092 | |
| 2016-01-23 15:10 | lynX | Note Added: 0010093 | |
| 2016-03-24 19:38 | tg | Note Added: 0010335 | |
| 2016-06-01 22:01 | lynX | Note Added: 0010842 | |
| 2016-06-01 22:09 | Christian Grothoff | Note Added: 0010843 | |
| 2016-06-01 22:09 | Christian Grothoff | Assigned To | => lynX |
| 2016-06-01 22:09 | Christian Grothoff | Status | new => feedback |
| 2016-06-17 20:20 | lynX | Note Added: 0010909 | |
| 2016-06-17 20:20 | lynX | Status | feedback => assigned |
| 2016-06-17 20:21 | lynX | Status | assigned => resolved |
| 2016-06-17 20:21 | lynX | Resolution | open => fixed |
| 2017-02-26 02:18 | Christian Grothoff | Product Version | => Git master |
| 2017-02-26 02:18 | Christian Grothoff | Fixed in Version | => 0.11.0pre66 |
| 2017-02-26 02:18 | Christian Grothoff | Target Version | => 0.11.0pre66 |
| 2018-06-07 00:24 | Christian Grothoff | Status | resolved => closed |
