Summary: | ASTERISK-08611: manager authentication does not work | ||
Reporter: | Andrew Kohlsmith (akohlsmith) | Labels: | |
Date Opened: | 2007-01-19 09:12:57.000-0600 | Date Closed: | 2007-01-19 10:30:26.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/ManagerInterface |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) manager_authenticate_fix_8852.diff | |
Description: | the authenticate() function in the manager interface has flawed logic. it opens up manager.conf, and then executes a while((cat = ast_category_browse(cfg, cat)) { ... } loop. This loop will *always* exit with cat == NULL, as there is no logic in the loop which breaks out once the matching category (the username) is found. This is a problem, because the next block of code will open up users.conf if and only if cat == NULL (i.e. the user was not found in manager.conf). ****** ADDITIONAL INFORMATION ****** The attached patch changes the while() { ... } loop to a do { ... } while(); and introduces a flag (gotit) which causes the do { ... } while() to break out when the user has been found. | ||
Comments: | By: Andrew Kohlsmith (akohlsmith) 2007-01-19 09:14:33.000-0600 The problem is easy to spot if you add a little bit of logging in the while() loop, and then again right after the ast_cfg_destroy (cat is *always* NULL). By: Andrew Kohlsmith (akohlsmith) 2007-01-19 09:18:51.000-0600 actually it looks like 51247 broke this, as the authenticate() function before this actually broke out of the while() if a match was found. By: Russell Bryant (russell) 2007-01-19 10:30:26.000-0600 Oops! This should be fixed in revision 51296, though with a slightly different patch. Thanks! |