Quote:
Originally Posted by Pseudomizer
...this is what i had implemented from day one when i experienced this bug.
|
I wish you would've posted it.

It would've saved me quite a bit of time.
Quote:
Originally Posted by Pseudomizer
- still have unregistered user on the list of attendees
- users are listed who never clicked on the link
I found out how they bypass our check for userid. They open 2 windows as a user who is not attending the event and sees the link "i want to attend to this event". Then he goes to the second window and logs out of the forum. The cookie is cleared. Then he goes back and clicks the link in the first window which is still there and oleeeeeeeee oleeeeeeeeee you have the user "unregistered user" attend the event. :-(
I haven't found out how they managed now to subscribe other users to an event but i will try to find out this as well.
|
That makes sense actually since all our code does is eliminate the prompt for an unregistered user and doesn't actually make it so an unregistered user cannot set the bit.
I think some sort of "if user logged in" code prefixing the db update would keep the unregistered users from setting the bit even if they somehow get the option. I've briefly looked at calendar.php and it seems like it will be easy to implement. The question is just where to put the code.
Now from what I've seen, if a unregistered user is already set, the only way to unset them is to get to a prompt and unset it.
As far as the other users that never clicked it, the only thing I can think of is some sort of db corruption. How many events do you have so far and how many people have used it? Maybe there are problems once usage gets above a certain level.