# possible we have an api call, impersonate
unless @current_user
if api_key = request["api_key"]
if api_username = request["api_username"]
if SiteSetting.api_key_valid?(api_key)
@is_api = true
@current_user = User.where(username_lower: api_username.downcase).first
end
end
end
end

As far as I understand, this is the problem: the StaffConstraint and AdminConstraint check the session and not the user object, thus causing the API impersonation to fail and to treat the request as if no one was logged in, obviously denying changing the site_setting.

Creating a user on an invite only forum fails. Yes that makes sense on a user interface but does it make sense if the API is being used ?

You would be surprised how much spam a trivial honeypot system can fight.

Good blog post. But isn’t that (your post / this honeypot mechanism) about doing something different than all the others? I.e. if you do something different in a piece of software that is likely to become big, then it is not different anymore by definition. What I’m trying to say is that as soon as someone puts the honeypot trick into a tool like XRumer, the bad guys have won and you have to think of something else. It’s an arms race that gives you a head start but as soon as the other party makes a move, you’re on equal foot, and you’ll be outnumbered by the amount of time they have available to spend. Every new counter-spam mechanism will be useless in a day, because it will be reverse engineered and implemented in their tools.

sam:

The api though should bypass honeypots and other systems cause you are clearly trusted.