Use of client_ip is not thread safe

[kyledrake]

As I understand it, client_ip is supposed to be the ip address of the end user. I'm not exactly sure why Namecheap requires this (it's a bit of a security concern), but if it must be configured per end user as I understand it, configuring it globally for the entire Namecheap module will prevent it from being thread safe:

Namecheap.configure do |config|
  config.key = 'apikey'
  config.username = 'apiuser'
  config.client_ip = '127.0.0.1'
end

I think that it should be supplied to an instantiated object, such as this sinatra psuedocode:

require 'sinatra'
require 'namecheap'

Namecheap.configure do |config|
  config.key = 'apikey'
  config.username = 'apiuser'
end

post '/create_domain' do
  @client = Namecheap::Client.new client_ip: request.ip
  @client.create_domainblahblah
end

In a threaded environment (which is the default for sinatra using most web browsers), the client_ip would be squashed by other simultaneous requests as multiple requests came in concurrently.

Not sure what the best way to approach this is, except to refactor to work as shown above.

[parasquid]

Hey, sounds good. I'm gearing up for a refactor too (gonna start a new
branch for that)

I'm not sure what kind of use case will require changing the client ip
though. I originally made the gem to extract out the functionality from a
central domain management system we have in the company. So that means
there will always be one client ip as a global value (the ip of the server)

But I guess if we are gonna use it as some sort of saas that performs
namecheap calls in behalf of a multitude of users, with their own keys and
usernames, that would make sense.

What do you think?

On Monday, March 2, 2015, Kyle Drake notifications@github.com wrote:

As I understand it, client_ip is supposed to be the ip address of the end
user. I'm not exactly sure why Namecheap requires this (it's a bit of a
security concern), but if it must be configured per end user as I
understand it, configuring it globally for the entire Namecheap module will
prevent it from being thread safe:

Namecheap.configure do |config|
config.key = 'apikey'
config.username = 'apiuser'
config.client_ip = '127.0.0.1'end

I think that it should be supplied to an instantiated object, such as this
sinatra psuedocode:

require 'sinatra'require 'namecheap'
Namecheap.configure do |config|
config.key = 'apikey'
config.username = 'apiuser'end

post '/create_domain' do
@namecheap = Namecheap.new client_ip: request.ip
@namecheap.create_domainblahblahend

In a threaded environment (which is the default for sinatra using most web
browsers), the client_ip would be squashed by other simultaneous requests
as multiple requests came in concurrently.

Not sure what the best way to approach this is, except to refactor to work
as shown above.

—
Reply to this email directly or view it on GitHub
#11.

[kyledrake]

My interpretation of "IP address of the client accessing your application (End-user IP address)" is that you need to provide the IP address for each user request, though I'm not sure if they enforce that, nor do I understand why this information would be neccessary. I could certainly just provide the IP address of the server doing the work, but that does not seem to be the spirit of this. This is also information they could easily acquire on their own end by looking at the IP doing the request.