spreedly / spreedly-elixir Goto Github PK

Hiya,

You have live Spreedly API credentials committed to config/test.exs. I'm assuming this isn't a live Spreedly account, but it still gives people access to your Spreedly account which is less than ideal. I noticed this while running tests and wondering how anything was actually passing since it all appears to make live HTTP requests. I'd recommend revoking these credentials.

Cheers,
James

So it looks like the spreedly elixir library might be broken. It was working for us until today.

it looks like the httpoison response in Spreedly.Base never matches parse_response. i threw a debugger and the api_request method in the Base module returns only an HTTPoison Struct. It doesn't return an ok or error tuple which parse_response expects.

i put in a catch all at the bottom

defp process_response(error) do IO.inspect(error) end

which just returns a %HTTPoison.Response{} instead of {_status, %HTTPoison.Response{}}

Using HTTPoison 1.6.2 in according to mix.lock

Hello, I've recently stumbled upon your library. Unofficial or not, it's under the hat of Spreedly so I'm very interested in using it.

That being said, going through the README I noticed you're storing the credentials in an Environment struct and then you require that struct in order to call operations.

I'm not gonna argue OOP vs. FP here because it's a matter of taste -- but would you be open to add wrappers to your Environment functions, directly in the Spreedly module? Something like this:

defmodule Spreedly do
  ...
  def purchase(key, secret, ...) do
    Spreedly.Environment.new(key, secret).purchase(...)
  end
  ...
end

I'd personally would be much more comfortable using it with more concise calls (only using Spreedly. as a prefix) and being able to do so statelessly (not storing credentials in objects between requests).

If you like the idea, you might not just add wrappers but simply change the core style to this? Up to you.

Additional food for thought might be adding bang functions (purchase!) which do the pattern matching internally and raise an error when the {:error, reason} tuple is returned.

Continuing the work in #21, we should consider a 422 Unprocessable Entity message from Core to be an error. We already do this if the reply from Core matches a certain format, but we should do it in the general case as well.

Change will likely target this function: