Repeated username/password requests after config update

[valuedguest]

After modifying config parameters (download speed limit) via the web-based UI, I started getting repeated username/password popups. Tried restarting SABnzbd and even rebooting to no avail.

Finally manually looked at the INI file.

The username and password lines for my Usenet server had been inexplicably added to the [misc] section of the INI file making SABnzbd *think* that I had password protected access to the web-based interface.

Something is wrong with the programming that updates the INI file after clicking [Update] in the web-based UI.

OR.. it's possible that there is something wrong with the programming that loads the field values into the web-based UI. I did not check to see that the username and password inputs were still 'empty' on the web-based form when I went in to change the download speed limit. So I suppose it's possible that SABnzbd improperly loaded these username/password values from the usenet server definition section of the INI and then saved those values.

[sander]

AFAIK this is caused by ... your webbrowser. It remembers the username/password for your newsserver for page "localhost" or "127.0.0.1", and then fills it out as the SAB login.

Annoying. I experience the same.

[safihre]

I will go and add autocomplete="off" to all forms that have any password things in them.
However, this will not stop FF/IE10+/Chrome of autofilling passwords, they just ignore this setting as soon as a user has chosen to save a password.. Nothing we can do :/
https://developer.mozilla.org/en-US/doc ... completion

[valuedguest]

I've resolved this in web-apps before where we have a form that is likely to be used on a public computer and don't want the browser to cache usernames and passwords. In a nutshell: add a hidden input with a long-ish random number (say 12 digits) or better yet - based on the current timestamp. Call that hidden input 'inputsuffix' or somesuch. Then append that 12 digit number to the names of the username and password inputs so that the input names are unique from one page visit to the next. On the page that accepts the form post, you then read the 'inputsuffix' value first and append that to the 'normal' names of the username and password fields. That way you're looking for the 'correct' input names. Example:

--html(ish)
input name='inputsuffix' value='103495827345'
input name='username103495827345' value='itsmetheuser'
input name='password103495827345' value='mypassword'

--php(ish)
//posting acceptor has to get the inputsuffix value first
inputsuffix = request('inputsuffix')
// append inputsuffix to get input names
username = request('username'.inputsuffix); // returns the value of 'username103495827345' form input
password = request('password'.inputsuffix); // returns the value of 'password103495827345' form input

Hope this helps.

[valuedguest]

One more thought.. since this app is not likely being run on a public computer, you could just name the web-ui username/password config setting inputs differently than the usenet server username/password config settings:

Example:
web-ui settings: uiusername, uipassword
usenet server settings: serverusername, serverpassword

That way the browser will only cache the username/password values for the matching inputs and your usenet server creds won't get 'copied' into web-ui cred inputs due to the naming collision.

[safihre]

The username and password fields of the (current) servers are already not named the same as for the global.
Also: since the config uses an Ajax submit, the browser doesn't ask to save username password. Only time this could happen was during the setup wizard, if the user there chose to save the username/password of the server it entered there.
So for now leaving it like this.

[safihre]

Actually in a recent update of the setup wizard the server password field was changed from password type, to text type. So probably the browser won't even ask anymore if you want to remember it!