A few API problems


(Michael - DiscourseHosting.com) #1

As some of you might know we’re developing a PHP REST API client. We’re running into a lot of problems though.

  1. Trying to change some site settings but this doesn’t work. My Ruby knowledge is pretty limited, but this is what I think is happening.

First, some code snippets.

config/routes.rb

Discourse::Application.routes.draw do
...
   namespace :admin, constraints: StaffConstraint.new do
    get '' => 'admin#index'
    resources :site_settings, constraints: AdminConstraint.new

lib/admin_constraint.rb

class AdminConstraint
  def matches?(request)
    return false unless request.session[:current_user_id].present?
    User.admins.where(id: request.session[:current_user_id].to_i).exists?
  end
end

lib/current_user.rb

# 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.

  1. 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 ?

app/controllers/user_controller.rb

class UsersController < ApplicationController
...
  def create
    return fake_success_response if suspicious? params
...
   def suspicious?(params)
      honeypot_or_challenge_fails?(params) || SiteSetting.invite_only?
    end

Why is this honeypot complicating things anyway? That is security by obscurity…


Amending current user logic in Discourse
(Michael - DiscourseHosting.com) #2

First problem is fixed here !

Still wondering about the honeypot and invite_only setting though :confused:


(Sam Saffron) #3

You would be surprised how much spam a trivial honeypot system can fight. You can read a bit about my thoughts in this matter at:

http://samsaffron.com/archive/2011/10/04/Spam+bacon+sausage+and+blog+spam+a+JavaScript+approach

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


(Michael - DiscourseHosting.com) #4

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.

Yes please :smile:


(Jeff Atwood) #5

Is this still an issue? Can this be closed?


(Jeff Atwood) #6