Authentication Is Too Complicated

[werkshy]

I don't know why the ping requests need to be so locked down. I think just sending the job token over https is probably secure enough - we could add an optional shared API key too.

[pjambet]

I agree, but this can't be changed easily, we would need to update all clients that are currently encrypting their payload to stop doing it before releasing a new version that only relies on API tokens.

[blahblahblah-]

We can also just ignore and not require the payload so that it is backwards-compatible.

[pjambet]

What would you ignore?

We currently have clients sending encrypted value for public_id, I don't see how we could remove the whole encryption handling code without breaking compatibility since we need to decrypt the payload they're sending in order to register their pings.

One approach could be to have a new endpoint, in order to have some kind of versioned API, but that sounds unnecessarily complicated.

[blahblahblah-]

Hmm true. I wasn't thinking about that. How about we accept either just the public_id or the encrypted value of public_id + timestamp, as the payload.

[pjambet]

I guess we technically could try to do that.

My current suggestion is to:

1. Merge JobsController: Accept base64 encoded payloads #18 (to unlock me for another task) since it is backwards compatible it would be safe to release it
2. Get our other clients to stop sending encrypted data (shouldn't take that long, but they can do it whenever they want)
3. Remove the whole encryption layer and add a note in the readme with a link to the newly created v1 if people want to run a version that supports encryption.

I think it's the best compromise (at least for me) since it doesn't require a lot of extra work.

[tvogels01]

I don't see a reason to deprecate the encryption, mostly because I don't want to touch any code that's using it. Providing a separate ping endpoint that's simpler would give users (and other adopters of cronut) the option to dial in their paranoia level.