Re: CrazyPonzi.com - 25+ BTC Invested | 140% Return | Each Investment for 120 Hour
When user enters Dashboard, you generate new, unique ID (you ensure uniqueness by using big numbers like 256-bit, or maintain a db of already used IDs - this could be as simple as two column table - ID + timestamp - upon generation you check if it has not been used within last 5-6 days).
at this point you have dashboard with new hidden unique-id field, that has never been used (submitted) before.
Note: you do not write the id to the table now.
When user submits his/her bet, first thing you do is to check whether it has already been used. If yes, proper message is thrown straight to the user face :-)
If no, bet is accepted and id is added to table.
old (stale) ids could be cleaned once per day via cron job, or per bet submission, or per unsuccessful bet submission <- my favorite option, means: random, but frequently enough.
If you stick to 5 days worth of IDs, you would end up with a table similar to active part of dashboard, which is as per now about 43 records.
I understand what you are saying, but I still fail to understand how this will solve the problem faced by SS2006 ? Because, user may want to submit two consecutive bets standing on the dashboard, which would have same effect of refreshing the page. If the first (desired action) is allowed, second (undesired action) will be automatically allowed. Rather, I can add an extra check box, which will be unchecked in each page load. Form will be submitted, only if this box is checked. But, this would probably create a bad user experience. So, I'm keeping it at hand as last resort.at this point you have dashboard with new hidden unique-id field, that has never been used (submitted) before.
Note: you do not write the id to the table now.
When user submits his/her bet, first thing you do is to check whether it has already been used. If yes, proper message is thrown straight to the user face :-)
If no, bet is accepted and id is added to table.
old (stale) ids could be cleaned once per day via cron job, or per bet submission, or per unsuccessful bet submission <- my favorite option, means: random, but frequently enough.
If you stick to 5 days worth of IDs, you would end up with a table similar to active part of dashboard, which is as per now about 43 records.
Perhaps our friend used some broken browser (msie?) :-) that did not ask him / her about form re-submission; or is a victim of some malware?
I dont think it is malware, because in that case he would have faced this problem for all his bets. It might be an old browser. May be some mobile browser too. Unless he clarifies, we will never know.Can I submit my CV for a position of project technical lead at CrazyPonzi.com? :-)
--
Best regards,
(-) Szycha.
LoLz... let this project grow. --
Best regards,
(-) Szycha.
