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.
There is much simpler method: after receiving a POST from web form, use redirect (header("Location: /")) to move player one step further. Thus, when he/she will press F5 next time, new page (GET /) will be reloaded, not the old one.
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.
You do not know my financial expectations yet. They will not kill the project - they will grow with it instead ;-)
--
Cheers,
(-) Szycha.