OpenWrt Forum Archive

Topic: Is there a way to remove the Hide/Reveal password button

The content of this topic has been archived on 25 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hey Everyone,

I am designing a front-end to Asterisk for OpenWrt, and I would like for people to not be able to click to reveal VoIP provider passwords on my interface. I quickly discovered that using the .password = true flag, one can make a field a "password" field where dots mask the password.

However, I would like to go a step further and take away the Hide/Reveal password button which is available to the right of the password field and allows one to unmask the password.

Yes, you may say that the router should be protected by a good password, etc. However, I would like to prevent somebody from checking out a password if the user gets up and walks away from the browser, forgetting to logout or relying on the auto-logout mechanism. What's more, I don't really see the interface I am writing as a "reference" for forgotten passwords or anything, so I don't see the point to the functionality in this case.

Many thanks to anybody who has a quick reply to this!

Iordan

The template needs to be changed to make this button optional. Keep in mind that this will provide no security though, a simple ctrl-u or firebug can easily show the masked value.

Hi Jow,

Thanks for the response. Is there no way to avoid populating the HTML source with the password, or would this entail that a Save&Apply would set the password to an empty field? Can you think, off the top of your mind, for any workaround that I can try coding into the templates?

Outside changing the templates, is there some way to put up a text box and a button, and upon clicking the button, whatever text was input into the said textbox would be grabbed and written to the configuration via a call to uci:set(), and uci:commit("section")? I can't think of how to grab text from a text-box which has been filled out but not "saved" into the UCI configuration, can you?

Thanks!!
Iordan

You can do it like this:

m = Map(...)

s = m:section(...)

some_secret_value = s:option(Value, ...)
some_secret_value.password = true -- to mask user input
some_secret_value.rmempty = false -- to prevent a delete of the whole option if nothing was entered

function some_secret_value.cfgvalue(self, section)
    return "" -- pretend that there is nothing in the config
end

function some_secret_value.write(self, section, value)
    -- check user value against value in config, trigger write if they differ
    local orig = m:get(section, self.option)
    if value and #value > 0 and orig ~= value then
        Value.write(self, section, value)
    end
end

The code above will always produce an empty password input, regardless of whether there is a config value behind or not.
If the user enters something it is compared against the value in the config, if it differs (config was empty or different) the user value is set.

Hey Jow,

Many thanks, I'll try your proposed implementation as soon as I get a chance. So basically, it looks like there are a couple of standard methods called "cfgvalue" and "write" which we are overloading here, right? The former gets called by the framework when the page is being loaded, and the latter gets called when the page is being "Save&Apply"-ed.

Are there any more methods that can be overridden like that to alter the behavior of the interface, or is this pretty much it?

The reason I want to have this kind of password sinking functionality is that an interface where somebody can simply click a button when I have my page turned and read in plain-text my Google Talk password doesn't pass my basic safety test smile.

Cheers,
Iordan

Hey, another question that I have is:

is a call to

m.uci:get(...)

any different from a call to

m:get(...)

?

Thanks!
Iordan

Yes it is.

m.uci:get() maps directly to the uci api get function while m:get() is a convenience shortcut.

m:get("section", "option")  ->  m.uci:get(m.config, "section", "option")

I see. What I meant was whether there is any difference in the end result, and since it's just a short-cut there would be no difference.

Thanks for all the help and explanations!

The discussion might have continued from here.