I just entered a bug in the Tracker. Since I chose to promote and demote via links, not forms, the parameters are sent via GET - the URL. Someone navigating the site will duplicate or undo promotions if they browse via forward and back. Worse, an accidental click on the wrong link in your browser's history can pull up a completely random change and implement it. Clearly, this cannot stand.
I see two ways of fixing it, and I'm not sure which is preferable.
1) The links go to a page which will update the database, then Location: forward the browser back to the linking page. When forwarding the browser back, the relevant parameters will be stripped off of the URL.
2) Add a `changes` field to the `pirates` table that is incremented each time the pirate is changed in any way. That way, updates can be done on "WHERE pirate_id = ? and changes = ?", which will simply have no matches if you browse backwards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Har! Nevermind, ye layabouts! I just managed to fix it in a way that allows comment fields for promotions and mass updating, in addition to correcting the bug. Neener!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just entered a bug in the Tracker. Since I chose to promote and demote via links, not forms, the parameters are sent via GET - the URL. Someone navigating the site will duplicate or undo promotions if they browse via forward and back. Worse, an accidental click on the wrong link in your browser's history can pull up a completely random change and implement it. Clearly, this cannot stand.
I see two ways of fixing it, and I'm not sure which is preferable.
1) The links go to a page which will update the database, then Location: forward the browser back to the linking page. When forwarding the browser back, the relevant parameters will be stripped off of the URL.
2) Add a `changes` field to the `pirates` table that is incremented each time the pirate is changed in any way. That way, updates can be done on "WHERE pirate_id = ? and changes = ?", which will simply have no matches if you browse backwards.
Har! Nevermind, ye layabouts! I just managed to fix it in a way that allows comment fields for promotions and mass updating, in addition to correcting the bug. Neener!