id should be url encoded when used in the delete url

[LaurentVB]

Hello.
We use the email address as id for users that want to subscribe to the newsletter but have no user account.
When the user subsequently creates a real account, we delete the existing record based on email address and add a new one with an integer id.

# Remove possible newsletter signup from customer
Customerio::Client.new(id,key).delete(user.email)

We recently have a user that has an accented character in the "local" part of the email address (ex: abcdé[email protected]). The delete call fails with the following error:

An URI::InvalidURIError occurred in signups#create:
 bad URI(is not URI?): /api/v1/customers/abcdé[email protected]
 app/models/user_observer.rb:14:in `after_create'

I'm not sure that this is a valid email address (I probably is according to the RFC), but I think you should probably make the lib more robust and url encode the passed id.

[alisdair]

I'm not sure that we can do anything about this, unfortunately, as it would be backwards-incompatible. Anyone using data which requires URI encoding would already be using URI encoding themselves, and double-encoding it would cause a failure.

As a workaround, you should be able to run URI.encode(id) on the id of your users.

If you can think of a backwards-compatible way to do this, please let me know.

[LaurentVB]

Hi.
Indeed, backwards-compatibility would be an issue.
I see three options:

• Detect if the string has already been encoded. If not, encode it (http://stackoverflow.com/a/2295286/424352 should work in 99,9% of the cases, shouldn't it?)
• add some config option in the CustomerIO::Client class that would force to always encode what's used in the url (some kind of strict mode, which would be off by default for backwards-compatibility, until next major release)
• if you consider it's the developer's responsibility and not the lib's to ensure the urls are valid, then you can simply document that every passed parameter that's used in URL must be urlencoded

In any case, that will require some documentation. Also maybe see what other Customer.io libs in other languages are doing, probably better to stay consistent.

Cheers.

[alisdair]

I've surveyed what the other Customer.io libraries are doing, and they all expect the id parameter to be URL encoded by the developer. For consistency that's the approach we're going to take here as well.

I'll leave this bug open until I update the documentation to reflect this. Thank you for the report and follow-up!

[LaurentVB]

Makes sense then.
Thanks for not having closed the issue right away as a user error ;-)