Bug in new version

Bug in new version SearchSearch
Author Message
Alex Kaiser
Frequent Contributor
Username: Alex_k

Post Number: 194
Registered: 07-2006
Posted on Friday, April 08, 2011 - 07:04 pm:   

Hi,

If sms user has forced source address with '&' char other accounts would be overriden with that source address. Awful bug.

Regards,
Alex K.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3086
Registered: 08-2008
Posted on Friday, April 08, 2011 - 07:18 pm:   

Hi Alex,

I'm sorry, but I need more of an explanation than that.

Configuration files are corrupted because of the & character? (Other user configuration shows forced sender address for a different account?)

User submitting a message mysteriously gets the forced sender address associated with a different account? (This happens to certain users or all users? This happens consistently? This happens occasionally?) Users are submitting messages using what protocol?

--
Des
NowSMS Support
Alex Kaiser
Frequent Contributor
Username: Alex_k

Post Number: 195
Registered: 07-2006
Posted on Friday, April 08, 2011 - 07:42 pm:   

Hi Des,

Sorry for a mess, let me put some details:
1. User has forced source address in NowSMS with '&' char
2. When that user doesn't submit messages over HTPP (seems only that protocol involved) - all is fine
3. If other user with that forced user submitting at the same time (with not predefined source addresses, it goes with 'Sender' parameter) source addresses’ being overridden with predefined source address.
4. When submission of predefined source address stops - situation becomes normal.

Please let me know, if you need more details.

Regards,
Alex K.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3087
Registered: 08-2008
Posted on Friday, April 08, 2011 - 11:26 pm:   

Hi Alex,

Am I correct that these HTTP submissions are occurring through an automated program (not actual users from a browser)?

What we have found is that keep-alive sockets remember any forced sender setting for the duration that the socket is open.

This would only effect an automated program that uses multiple user accounts on a single HTTP session.

You can have multiple programs (or multiple HTTP sessions from a single program) using different user accounts simultaneously.

Where you run into a problem is with a single program that opens up an HTTP connection and sends first using one account, then using another account.

If the first account has a forced sender address, and a message comes in over the same HTTP connection specifying an account that does not have a forced sender address, the forced sender address from the first account is not cleared.

It is a bug, but one that effects a rather specific and unusual scenario ... at least as best as we can understand and recreate it.

Until a fix is available, disable keep-alive sockets in the HTTP interface with the following setting in SMSGW.INI:

[SMSGW]
EnableKeepAlive=No


--
Des
NowSMS Support