Ticket #3950 (new Bugs)

Opened 10 months ago

Last modified 7 months ago

Error when using special characters in username/password for CID lookup source

Reported by: patrick_elx Assigned to:
Priority: minor Milestone: Cut Line
Component: CallerID Lookup Version: 2.6-branch
Keywords: escape special characters Cc:
Confirmation: Need Feedback SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description

In the CID lookup source, you can specify a username/password for lookup sources.

This username/password is added in the extension_additional.conf in [cidlookup] as exten => cidlookup_1,1,Set(CALLERID(name)=${CURL(http://username:password@127.0.0.1:80/yourscript.php?${CALLERID(num)})})

however if you use special characters in your password (!@...) they are written as is in the extension without escape characters and the curl call fails.

I would suggest that when writing the [cidlookup] context the username and password are first checked for characters that need to be escaped.

the CURL(http://username:p@ss!word@127.0.0.1:80 should be written instead as CURL(http://username:p\@ss\!word@127.0.0.1:80

Change History

11/11/09 06:50:00 changed by mbrevda

Did you try escaping them when you entered them?

01/06/10 13:07:49 changed by krycek

Any update on this? I found that modifying the curl command line here works when it looks like this:

curl -u maint:\@password\! http://localhost:80/admin/modules/superfecta/bin/callerid.php?thenumber=${CALLERID(num)

How do I change that in FreePBX though?

01/28/10 08:46:03 changed by p_lindheimer

  • confirmation changed from Unreviewed to Need Feedback.

It's not completely clear to me where the issue is here. Is this reserved characters that Asterisk requires to be escaped when used in a variable, which would be the following I think: 

[ ] $ " \

Or is the issue a URL issue, and if so, would putting the username, password and the full completed URL through urlencode() prior to printing it out in the CURL statement? If we can get a better understanding then we can address this. It's easy enough to just escape '@' and and '!' from the above example, but then someone will come up with '$' as an issue, and so on... So if someone can pipe in we can give it a go to see if we can clean this up. (For now there is a clear workaround which is escaping characters in the configuration.

01/29/10 19:09:29 changed by krycek

Here was my original post in the PiaF forums:

OK, I figured out what works. By default, FreePBX write this into the extensions_additional.conf file:

exten => cidlookup_1,1,Set(CALLERID(name)=${CURL(http://maint:@password!@127.0.0.1:80/admin/modules/superfecta/bin/callerid.php?thenumber=${CALLERID(num)})})

That doesn't work because of the "!" and the "@", for obvious reasons. You can escape the "!", but the "@" is used in that command, so you can't just escape it. The answer is to break out the username and pass from the URL, and escape the characters. I'm not sure how to modify the line to do this, but here is the curl command line it needs to pass:

curl -u maint:\@password\! http://localhost:80/admin/modules/superfecta/bin/callerid.php?thenumber=${CALLERID(num)

Make sense?

01/29/10 19:27:40 changed by p_lindheimer

I understand, I would just like to know what else needs to be escaped beyond those two. Fixing this will break existing configs in places where people have escaped the characters manually. So if we are going to break them, I would like to only break them once and find out how to get a full list of illegal characters that need to be escaped there.

01/29/10 19:37:03 changed by krycek

I'm not a programmer by any means, but maybe not. The way it is done now is fine, and the characters would manually need to be escaped anyways. The only characters that wouldn't be able to be escaped (I would assume), would be ":" & "@", as they are characters that are expected in that command line. By changing the command line used to what I propose, the "@" character can now be escaped, and I would assume the ":" character, as long as it trails an initial ":" character, could be escaped as well. I wouldn't necessarily recommend automating the escape character sequence, but maybe just referencing it in the GUI so users are aware it is required to put a "\" in front of "special, non-alphanumeric character". Thoughts?

02/16/10 22:13:48 changed by p_lindheimer

  • milestone changed from 2.7 to 2.8.

I'm going to push this out for now. We don't have a conclusive list of what characters need to be escaped, in addition 'fixing' this will turn around and break existing installations unless we are very careful with the migrations to remove special characters that had been put in. We can look closer at this once we have additional data and in any event it borders a bit between a bug and a feature code.