Your choices for keeping track of a given browser with some sort of browser-identifying ID (so you might know who a given user is) are:
- Cookies
- Local Storage
Your choices for storing the state of the 1200 buttons are:
- Server-side storage of the state that is given to the web page by the server
- Cookies (probably have to collapse the data to one bit per button0
- Local storage
So, for example, you could combine storing a browser identifing value in a cookie with storing the actual button state in a server-side database. Then, when the page is rendered, you look up the button state in the database for the browserID that is in the cookie and you either disable or remove the relevant buttons from the rendered HTML page.
You could do all the storage in a cookie by collapsing the 1200 buttons state to one bit per button. Using A-Z and a-z and 0-9 and a couple of symbols, you could easily have 64 values per character which would allow you to store the on/off state for 32 buttons per character so the on/off state for 1200 buttons could be stored in 38 characters which easily fits in a cookie. If you had to store a time/date for each button too, then that won't fit into a cookie so you'd be left to server-side storage or local storage.
FYI, I hope you realize that any client-side scheme is very easy to get around. In fact, if you're just trying to prevent a user from going to the same URL more than once, all they have to do is bookmark the original URL and they can go there as often as they like without even visiting your web page. Or, they can just wipe cookies or local storage. Or, they can just go to a different browser.
The only real way to prevent multiple visits is to require user authentication and validate (on your web server) that a given logged-in user is allowed to visit any given page before rendering the page. So, if you want to do this robustly, then it has to all be done server-side and you will need some sort of site login.