Create a widget or item for password input

I am trying to create a password input, either as a widget or as an item. This password will be passed into a rule that will make a web request to an external API that requires a login credential. So far, I have successfully set up an item called “api_password” which stores the password in raw text. I am able to retrieve this value in my script, and use it in my API call. Using this method, the API call works.

However, the value of the password shows up in the list of items in plain text, which is um … not the most secure way of storing a password. I would like for the user to be able to enter this password, but for it to NOT be shown in plain text, but I haven’t been able to find any way to hide the value of an item.

My plan B was to create a widget of type “password” (which I called “input_api_password”) and link its value to api_password. I was able to successfully do this. However, while the password widget text is replaced with *****, the value of the referenced item is still displayed in plain text. So same problem as above.

I found a similar topic, in which someone was trying to pass the value of a widget directly to a script:

But based on what I read in the above topic, it looks like I need the item as a go-between. This makes me wonder: what is the purpose of the “variable” in the widget configuration? Is there a way for me to access this variable directly from within a rule?

In any case, I am trying to make it so that the user can enter a password for the API, have OH store that password so that it can be retrieved by a rule and passed into a script, but for the value of the password to NOT be publicly visible in the OH U.I… Is this possible? If so, how would I go about achieving it? Thanks in advance.

I guess your rule is running directly after entering the password?
So why not add a

yourpasswordItem.postupdate(„nonsense“)

Within the rule ?

That topic is pretty old. If you’re on a newer OH version, you can now pass information from a widget directly to the context of a rule when that rule is activated. As part of the rule action you can add the actionRuleContext property and any key value pairs under that property will be added as variables to the rule context. You didn’t say what rule language you are using, and I know this works with many of the rules systems, but I cannot say for sure if it works with DSL If you have a input element that sets the password variable in the widget then a button to send that password to a rule would look like this:

- component: oh-button
  config:
    text: Submit
    action: rule
    actionRule: api_rule_UID
    actionRuleContext:
      widget_password: =vars.password

Then in your rule you can just use the variable widget_password.

Variables mostly handle the internal workings of the widgets allowing different parts of a widget or different widgets on a page to pass information back and forth.

Thanks for the tip, that really helped point me in the right direction. I was able to create a “login” widget using the actionRuleContext that takes a username and password input and passes them into my function.

I wasn’t able to do this without still needing an item in which to store the password. What I ended up doing is triggering a rule when the password is entered. That rule runs a javascript encryption function, which stores the encrypted pw in the item. My API call (in a separate rule) is then able to pull the encrypted pw from the item, run it through the decryption function, and send it to the API. So even though I wasn’t able to completely hide the PW from view, I was at least able to encrypt it so that it isn’t just being stored in plain text.

Hopefully this is secure enough for our purposes.

@JustinG
Variables mostly handle the internal workings of the widgets allowing different parts of a widget or different widgets on a page to pass information back and forth.

Ok, think I get it. So if there’s like multiple inputs or objects in a single widget, they can talk to each other using the variable, even though the variable isn’t persisted or available outside of the widget.