[GH-ISSUE #30] No authentication in task checking #25

New issue

Closed

opened 2026-02-28 01:22:49 +03:00 by kerem · 4 comments

kerem commented

2026-02-28 01:22:49 +03:00

Owner

Originally created by @ghost on GitHub (Aug 22, 2012).
Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/30

I know sending a plaintext password in a POST is bad, but it is an incredible improvement over no authentication at all. Until a more secure authentication mechanism is available, task checking should at least have an option to use POST instead of GET, and include both the secret and the device ID in it.

Originally created by @ghost on GitHub (Aug 22, 2012). Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/30 I know sending a plaintext password in a POST is bad, but it is an incredible improvement over no authentication at all. Until a more secure authentication mechanism is available, task checking should at least have an option to use POST instead of GET, and include both the secret and the device ID in it.

kerem closed this issue

2026-02-28 01:22:49 +03:00

kerem commented

2026-02-28 01:22:50 +03:00

Author

Owner

@olliebennett commented on GitHub (Dec 23, 2012):

I agree that this would be an improvement.

In order to maintain backwards compatibility with the current process (i.e. server configurations which currently check for the GET parameter ?task=send) how about sending both POST and GET together? That is, send a POST request to your_callback_url?task=send.

As a sidenote, I'm actually satisfied by the level of security offered by the combination of HTTPS POST and the secret/device ID, which sacrifices neither clarity of code nor ease of server development. What would your suggestion be for the "more secure authentication mechanism"?

@olliebennett commented on GitHub (Dec 23, 2012): I agree that this would be an improvement. In order to maintain backwards compatibility with the current process (i.e. server configurations which currently check for the GET parameter `?task=send`) how about sending both POST and GET together? That is, send a **POST** request to `your_callback_url?task=send`. As a sidenote, I'm actually satisfied by the level of security offered by the combination of **HTTPS** POST and the secret/device ID, which sacrifices neither clarity of code nor ease of server development. What would your suggestion be for the "more secure authentication mechanism"?

kerem commented

2026-02-28 01:22:50 +03:00

Author

Owner

@ghost commented on GitHub (Feb 28, 2013):

Combining GET and POST like that is kind of ugly, but so is breaking API. There's probably some combination of server and language that breaks even with that, but probably rather rare.

I would propose that since there's already a user defined secret key(i.e. a password) per sync target, all requests to that target(sending, task checking, potential callbacks) would include in POST these items:

Device ID
A hash of the secret, concatenated with the device id
Hash function should be something widely available, like sha512.

@ghost commented on GitHub (Feb 28, 2013): Combining GET and POST like that is kind of ugly, but so is breaking API. There's probably some combination of server and language that breaks even with that, but probably rather rare. I would propose that since there's already a user defined secret key(i.e. a password) per sync target, all requests to that target(sending, task checking, potential callbacks) would include in POST these items: 1. Device ID 2. A hash of the secret, concatenated with the device id Hash function should be something widely available, like sha512.

kerem commented

2026-02-28 01:22:50 +03:00

Author

Owner

@mandric commented on GitHub (Mar 4, 2013):

I vote for separate settings option to include username/password for HTTP basic auth, that is just used on any request when activated. Basic Auth over https is not so horrible.

@mandric commented on GitHub (Mar 4, 2013): I vote for separate settings option to include username/password for HTTP basic auth, that is just used on any request when activated. Basic Auth over https is not so horrible.

kerem commented

2026-02-28 01:22:50 +03:00

Author

Owner

@eyedol commented on GitHub (Apr 8, 2014):

Basic Auth is now supported.

@eyedol commented on GitHub (Apr 8, 2014): Basic Auth is now supported.